Homework 5: System Design and Modeling

ECE411: Fall 2011

Team members: Chris Ball, Huy T. Huynh, Hung Nguyen, Jason Peterson

November 14th, 2011 Table of Contents

Contents

Introduction For this assignment we chose to represent the code function for the microcontroller as well as the PC GUI which will be used to interface with the footswitch controller and the oscilloscope. To represent the Atmega8 microcontroller functions we chose the UML Activity View method of representation. In the case of the PC GUI it was decided to use the Level 0 and Level Block Diagram method. State Diagrams of footswitch behavior was also included for general behavior as well as command queue.

Footswitch Control System: Level 0 and Level 1 Tektronix Oscilloscope Footswitch

Control System: Level 0 Module Tektronix Oscilloscope Footswitch Control System

Inputs User Interactions: Physical interactions from User to Footswitch

User Configuration: Action assignment to Scope control functions.

Oscilloscope Responses: Responses and Data returned from the Oscilloscope

Outputs SCPI Commands: Control commands sent to the Oscilloscope

Functionality Takes user interactions through footswitch buttons and converts them to commands to control the connected Oscilloscope.

Tektronix Oscilloscope Footswitch

Control System: Level 1 Module Footswitch

Inputs Power: 5V DC power from USB connection

Data: D+ and D- data lines from USB connection

User Interactions: Physical interactions from User to Footswitch

Outputs Data: D+ and D- data lines from USB connection

Functionality Detects User inputs to the footswitch buttons and converts them to commands that are sent to the GUI when queried

Module PC GUI

Inputs Data: D+ and D- data lines from USB connection

User Configuration: Action assignment to Scope control functions.

Oscilloscope Responses: Responses and Data returned from the Oscilloscope

Outputs Power: 5V DC power from USB connection

SCPI Commands: Control commands sent to the Oscilloscope Functionality Interacts with the Footswitch to detect user inputs and convert them to user configured oscilloscope commands, control the oscilloscope and save any appropriate data returned from the scope for the selected action.

Footswitch Level 0 Diagram Footswitch: Level 0

Module Footswitch

Inputs Power: 5V DC power from USB connection

User Interactions

Outputs User interactive: physical interactive from user

Data: D+ and D- data lines to USB Connection

Functionality Footswitch takes user interactions, converts them to commands and sent them over the USB bus. Activity view for ATMEGA8 code behavior

Important Notes

 Buttons 1 and 2 can be pushed simultaneously

 State button cannot be pushed simultaneously with either button 1 or 2.

 Using 1ms interrupts for polling as well as pulse width and pulse spacing counters.

 Using 4-bit GPIO data to encode six types of commands to send to PC  Command buffer is FIFO

Level 0 and level 1 block diagrams of PC GUI PC GUI: Level 0

Module PC GUI Inputs Data: D+ and D- data lines from USB connection Oscilloscope Responses: Responses and Data returned from the Oscilloscope User Configuration: Action assignment to Scope control functions. Outputs Power: 5V DC power from USB connection Data: D+ and D- data lines from USB connection SCPI Commands: Control commands sent to the Oscilloscope Functionality Interacts with the Footswitch to detect user inputs and convert them to user configured oscilloscope commands, control the oscilloscope and save any appropriate data returned from the scope for the selected action. PC GUI: Level 1

Module PHY (to footswitch) Inputs Power: 5V DC power from USB connection Data: D+ and D- data lines from USB connection Data: PHY interaction with various levels of .dll Outputs Data: D+ and D- data lines from USB connection Data: PHY interaction with various levels of .dll Functionality Handles physical layer connection of USB cables and data transfer to the controlling .dll software on the PC.

Module SimpleIO-UM.dll Inputs Data: API Command set instructions for the footswitch Data: Interaction with PHY to send commands from the API Outputs Data: Responses to API Command set instructions from the footswitch Data: Interaction with PHY to return commands from the footswitch Functionality Bridge between the GUI and the PHY connection to the USB footswitch

Module GUI Software Inputs Data: Responses to API Command set instructions from the footswitch Oscilloscope Responses: Responses and Data returned from the Oscilloscope User Configuration: Action assignment to Scope control functions. Outputs Data: API Command set instructions for the footswitch SCPI Commands: Control commands sent to the Oscilloscope Functionality Uses the API for the footswitch USB connection to poll the status of user interactions to the footswitch. When commands are detected, they are mapped to the user configured SCPI scope commands and sent to the scope. Data returned from the scope to know when the action is completed, and save any data locally that is appropriate for the action.

Module Visa32.dll Inputs SCPI Commands: Control commands sent to the Oscilloscope Data: : PHY interaction with various levels of .dll Outputs Oscilloscope Responses: Responses and Data returned from the Oscilloscope Data: : PHY interaction with various levels of .dll Functionality Takes SCPI commands and packages them correctly for the appropriate PHY connection to the Oscilloscope, may be GPIB, USB, RS232, Ethernet

Module PHY (to scope) Inputs Oscilloscope Responses: Responses and Data returned from the Oscilloscope Data: : PHY interaction with various levels of .dll Outputs SCPI Commands: Control commands sent to the Oscilloscope Data: : PHY interaction with various levels of .dll Functionality Handles physical transfer of data sent to and from the scope and communication back to the controlling levels of .dll

Footswitch State Diagram: Button Select Input signals description - USBCFG: Output from MCP2200 – 1 for completed initialization, 0 for not ready.

- BUT1: Button 1 status – 1 for high (button 1 is released), 0 for low (button 1 is pressed).

- BUT2: Button 2 status – 1 for high (button 2 is released), 0 for low (button 2 is pressed).

- COUNTER: internal counter value.

- PRESET_SHORT: preset interval for short press.

- PRESET_SPACE: preset interval for space between two double presses.

Output signals description - BUT1_STATUS: Button 1 status – waiting, measuring short, measuring space, short press, double press.

- BUT2_STATUS: Button 2 status – waiting, measuring short, measuring space, short press, double press.

- COUNTER: internal counter value.

- QUEUE: Command queue.

States description - INIT: ATmega8 started, waiting for ready signal from MCP2200.

Output: Button 1 status is Waiting, Button 2 status is Waiting, Counter = 0, no new command to queue.

- WAITING: waiting for button 1 or button 2 to be pressed.

Output: Button 1 status is Waiting, Button 2 status is Waiting, Counter = 0, no new command to queue.

- MEAS_SHORT_BUT1: measuring interval when button 1 is pressed.

Output: Button 1 status is measuring short, Button 2 status remains, Counter ++, no new command to queue.

- RESET_COUNTER_1: reset interval counter value.

Output: Button 1 status is measuring double, Button 2 status remains, Counter = 0, no new command to queue.

- MEAS_SPACE_BUT1: measuring released interval after button 1 is pressed. Output: Button 1 status is measuring double, Button 2 status remains, Counter ++, no new command to queue.

- BUT1_SHORT: button 1 is short pressed confirmed.

Output: Button 1 status is short pressed, Button 2 status remains, Counter = 0; Add new command “Button 1 short pressed” to queue.

- BUT1_DOUBLE: button 1 is double pressed confirmed, waiting for button 1 to be released.

Output: Button 1 status is double pressed, Button 2 status remains, Counter = 0; Add new command “Button 1 double pressed” to queue.

- MEAS_SHORT_BUT2: measuring interval when button 2 is pressed.

Output: Button 1 status remains, Button 2 status is measuring short, Counter ++, no new command to queue.

- RESET_COUNTER_2: reset interval counter value.

Output: Button 1 status remains, Button 2 status is measuring double, Counter = 0, no new command to queue.

- MEAS_SPACE_BUT2: measuring released interval after button 2 is pressed.

Output: Button 1 status remains, Button 2 status is measuring double, Counter ++, no new command to queue.

- BUT2_SHORT: button 2 is short pressed confirmed.

Output: Button 1 status remains, Button 2 status is short pressed, Counter = 0; Add new command “Button 2 short pressed” to queue.

- BUT2_DOUBLE: button 2 is double pressed confirmed, waiting for button 2 to be released.

Output: Button 1 status remains, Button 2 status is double pressed, Counter = 0; Add new command “Button 2 double pressed” to queue.

- BOTH_PRESSED: both button is pressed at the same time, send “both pressed” command to queue.

Output: Button 1 status is short pressed, Button 2 status is short pressed, Counter = 0; Add new command “both pressed” to queue. Footswitch State Diagram: Command Queue

Input signals description - USBCFG: Output from MCP2200 – 1 for completed initialization, 0 for not ready.

- ACK: GPIO7 output from MCP2200 – functions as Acknowledge signal from PC program. - #Queue: number of commands are storing in command queue.

Output signals description - GPIO3..6: output command encoded as binaries.

States description - INIT: ATmega8 started, waiting for ready signal from MCP2200.

Output: Output command “Waiting”.

- WAITING: waiting for commands to be added to queue.

- SEND_COMMAND: send command to output.

Output: Output 1 command stored in queue, also evict that command from queue.

- WAIT_ACK: waiting for acknowledge from PC program.

Conclusion UML modeling can be a very useful method of explaining the function or behavior of a system. Modeling can be used more effectively than words in many cases. This is in part because the combination of block diagrams/drawings can convey function and layout of a system quickly and easily whereas words alone can be tedious and still not give an accurate picture of the system being described. This is why block diagrams/state tables can be so effective when combined with Use Case charts and other means of communication.

A case in point, while laying out the behavior in modeling/diagram form several code bugs were discovered which were then remedied, both in the diagrams as well as the code they represented.

In other words modeling and behavior diagrams serve to visualize the performance of a system and troubleshoot errors.