Tux Controller Mark II Design Review

Eric Clark Mika Latimer

Group 25

TA: Brady Salz

ECE 445

February 26, 2015

Table of Contents 1 Introduction 3

1.1 Statement of Purpose 3 1.2 Objectives 3 1.2.1 Goals & Benefits 3 1.2.2 Functions & Features 3

2 Design 4 2.1 Block Diagram 4

2.1.1 Microcontroller 4 2.1.2 USB 5 2.1.3 Reset/Mode Input 5 2.1.4 LED Display 5 2.1.5 Buttons 5 2.1.6 Joystick 5 2.1.7 IR Receiver 5 2.1.8 Accelerometer 5

2.2 Controller Layout 6 2.3 Schematics 7 2.4 USB Messages 10

2.4.1 Commands and Responses 10 2.4.2 Events 10

3 Requirements and Verification 12 3.1 Modular Functionality 12 3.2 System Functionality 15 3.3 Tolerance Analysis 15

4 Safety Statement 16 5 Ethics Statement 16 6 Cost and Schedule 17

6.1 Cost Analysis 17 6.1.1 Labor 17 6.1.2 Parts 17 6.1.3 Grand Total 18

6.2 Schedule 18 Appendix A: MTCP Protocol Description 20

2

1 Introduction

1.1 Statement of Purpose ECE 391, the Computer Systems Engineering class uses a custom USB gamepad to teach students to write a simple device driver. The current device cannot be reproduced because the design files were lost. Our project is to design a new gamepad that is protocol compatible with the old gamepad and is also enhanced with new sensors to support future machine problems and extra credit projects.

1.2 Objectives

1.2.1 Goals & Benefits Fewer components than 2006 controller New sensors for future machine problems and student extra credit projects Support future ECE 391 serial protocol changes

1.2.2 Functions & Features Simple USB serial protocol for user applications and drivers Protocol compatible with 2006 controller Left, Right, Up, Down, Start, A, B, C push buttons Four digit 7­segment display with host PC control of each segment Reset button allows recovery from errors without unplugging USB IR receiver allows universal remotes as input to host PC Analog joystick enables new kinds of games 3­axis accelerometer for motion control games Mode jumper to enables features not found on 2006 controller Polling and edge triggered data transmission to host PC

3

2 Design

2.1 Block Diagram

Figure 1: Game Controller Block Diagram

2.1.1 Microcontroller The microcontroller, or MCU, is the central module of the gamepad. It relays the button state, accelerometer readings, received infrared codes, and joystick position over USB to software on the host PC. The MCU software must be configured by the host PC to relay input data automatically, or through explicit polling. The MCU software will accept commands to control each led segment in the display. The MCU must appear as a serial device on Windows or Linux host PCs. In mode 0, the serial data must conform

4

to the driver specification for ECE 391 machine problem 2. Additionally, in mode 0, all unrecognized serial data must halt normal MCU operation and display OOPS on the LED Display until the reset signal is raised. In mode 1, a separate command set will be defined to support the IR receiver, joystick and accelerometer inputs that are not supported in mode 0.

2.1.2 USB The USB port module provides the physical connection to the host PC. It will consist of a USB mini­b female connector. A differential pair of wires connects to the MCU. The connector also provides power to all modules in the circuit and common ground. At 5V it provides 100 mA upon mechanical connection and 500 mA after the MCU initializes the data channel to the host PC.

2.1.3 Reset/Mode Input The Reset/Mode Input module will provide two digital signals to the MCU. Reset signal will be triggered by a micro push­button and trigger the gamepad to leave the “OOPS” state. Mode input will be provided by a jumper. The signal enables host commands to access the Joystick, IR receiver, and accelerometer modules.

2.1.4 LED Display The display module consists of four 7­segment digits with decimal point. The display module will be driven by low current digital logic signals. Four signals will select the digit, and eight signals select the led segment.

2.1.5 Buttons The buttons module consists of eight buttons. They are: left, right, up, down, start, a, b, c. Each button is a single active low input to the MCU.

2.1.6 Joystick The joystick module will provide X and Y position analog signals to the MCU.

2.1.7 IR Receiver Receiver module will receive 38kHz carrier IR transmissions used by common television remote controls and demodulate it into a digital signal for the MCU.

2.1.8 Accelerometer Three axis accelerometer measures acceleration on three orthogonal axes and provides this to the MCU as three analog signals.

5

2.2 Controller Layout Existing software depicts the controller layout so we will conform to the general layout of the old device. In particular, the direction push buttons must be in a diamond shape on the left with Start in the middle and A, B, C on the right. The LED display must be on the upper right corner as shown in Figure 2.

Figure 2: Game Controller Layout

6

2.3 Schematics

Figure 3: Microcontroller and USB schematic

7

Figure 4: Button and LED Display Schematic

8

Figure 5: IR Receiver, Mode Jumper, Joystick and Accelerometer Schematic

9

2.4 USB Messages USB messages are transported as RS232 type serial data and encoded in a form similar to a PS/2 mouse packet. The protocol encoding is described in a C header file prepared by Mark Murphy in 2006 and attached as Appendix A. The hardware design of our device is capable of supporting the full command set but we will restrict the software implementation to the following commands, responses and events that are used in the ECE 391 machine problems.

2.4.1 Commands and Responses

Command Responses

MTCP_RESET_DEV Resets the controller MCU program and resets all run­time configuration to defaults.

No response. However, the MCU will generate MTCP_RESET after reinitialization.

MTCP_OFF Turns the MTC off.

No response. However, the MCU will generate MTCP_OFF_EVENT before it goes to sleep.

MTCP_POLL Gets the status of the buttons.

MTCP_POLL_OK

MTCP_POLL_LEDS Gets the status of the LED display.

MTCP_LEDS_POLL0 then MTCP_LEDS_POLL1

MTCP_BIOC_ON Enables button interrupt­on­change.

MTCP_ACK. MTCP_BIOC_EVT is generated when buttons are pressed or released.

MTCP_BIOC_OFF Disables button interrupt­on­change.

MTCP_ACK

MTCP_DBG_OFF Disables debug­lockup mode.

MTCP_ACK

MTCP_LED_SET Sets the LED display values if in user mode.

MTCP_ACK

MTCP_LED_USR Enables LED user mode.

2.4.2 Events

Event Description

MTCP_ERROR Response to unknown command when debug­lockup is off.

10

MTCP_ACK Response when a command is completed.

MTCP_POLL_OK First response byte of a poll of the buttons.

MTCP_RESET Generated when the device powers up, the reset button is pressed, or MTCP_RESET_DEV command is sent.

MTCP_OFF Generated when device turns itself off after receiving the MTCP_OFF command or after two hours of inactivity.

MTCP_BIOC_EVT Generated when a button is pressed or released if in Button Interrupt­on­change mode.

11

3 Requirements and Verification

3.1 Modular Functionality Note: In these requirements logic low is between 0V and 0.5V. Logic high is between 3V and 5V.

Requirement Verification Points

MCU a. Connects to host PC. b. LED_SET command

able to raise and lower LED Display signals.

c. Response to POLL command must have correct (high/low) signal state for each button.

MCU a. Connect USB signals to

host PC. Check if OS recognizes the MCU.

b. Connect USB to PC and attach logic analyzer to LED Display signals. Send LED_SET commands from test program and compare logic analyzer signals.

c. Short each button signal to either logic high or low. Issue POLL command from Host PC. MCU Response should indicate corresponding button presses.

15

d. Incorrect commands trigger error state in mode 0.

e. BIOC mode must enable automatic transmission of button state packet in mode 0.

f. Mode 1 must send joystick, accelerometer, and IR receiver value to host PC.

d. Pull mode signal high. Attach logic analyzer to led display signals. Issue invalid command. Display signals should correspond to OOPS.

e. Issue BIOC_ON from host PC and have host PC display serial data. Check that serial data is received on button press or release.

f. Attach bench power supply to joystick X pin. Monitor serial data on host PC. Pull mode pin low. Vary bench supply between 0 and 5 volts.

10

12

Check that voltage changes trigger serial data. Check Y pins similarly. Check accelerometer X, Y, Z pins with bench power supply between 0 and 3.3 volts. Connect IR Receiver module and check that TV remote signals transmit serial data to host PC.

USB a. Must supply +5V +/­

0.25V at 100 mA from host PC without MCU connected.

b. Must supply +5V +/­ 0.25V at 500 mA from host PC with MCU connected and initialized.

USB a. Add resistive circuit that

draws 100 mA using the bench power supply. Disconnect from bench supply. Place multimeter in parallel with USB power pins. Connect USB. Verify that the voltage is in range.

b. Add switched resistive circuit that draws 500 mA using the bench power supply. Place multimeter in parallel with USB power pins. Switch off resistive circuit. Disconnect bench supply and connect USB to host. After 5 seconds, switch on resistive circuit. Verify that the voltage is in range.

5

Reset/Mode Input a. Reset button open

circuit when released, closed circuit to ground when pressed.

b. Mode jumper is open circuit when removed, closed circuit to ground

Reset/Mode Input a. Attach multimeter to

reset signal and ground. Check continuity for open circuit. Press button and check for closed circuit.

b. Attach multimeter to

5

13

when installed. mode signal. Check continuity for open circuit. Press button and check for closed circuit.

LED Display a. Corresponding

segments illuminate when LED_D0 is high and each of LED_A to LED_DP signals are high.

LED Display a. Short transistor base

resistor to Vcc to connect cathode of left digit. Short segment resistor to Vcc. Check if illuminated. Repeat for all segments and all digits.

15

Buttons a. Button outputs open

circuit when released, closed circuit to ground when pressed.

Buttons a. Attach multimeter to

button signal and ground. Check continuity for open circuit. Press button and check for closed circuit. Repeat for all eight buttons.

15

Joystick a. X and Y voltage varies

when moved. X output must be 0.25V +/­ 0.25V at full left, and 4.75V +/­ 0.25V at full right. Y output must be 0.25V +/­ 0.25V at full down, and 4.75V +/­ 0.25V at full up.

b. X and Y return to center voltage when released. X and Y output must settle to 2.5V +/­ 1.0V.

Joystick a. Connect digital

multimeter to joystick circuit X output and ground. Check X output voltage at full left and full right, Check Y output voltage at full up and full down.

b. Connect digital multimeter to joystick X output and ground. Check that the output settles in range after joystick is released from a non­center position.

5

IR Receiver a. IR receiver sends serial

scan codes to output signal.

IR Receiver a. Connect logic analyzer

to IR receiver output. Press a button on a common TV remote.

5

14

Verify scan code against code table for remote.

Accelerometer a. Measures acceleration

on 3 axes 40­200 ms after board moves.

Accelerometer a. Mechanically connect

accelerometer chip to a push button switch. Connect switch to pull­up circuit and ground. Probe X,Y,Z and push button output with oscilloscope. Trigger oscilloscope on switch signal edge. Hold switch closed against lab bench so that the device does not move against it. Release switch and observe time between signal changes.

5

3.2 System Functionality

Requirement Verification Points

1. Compatibility a. LED Display must

match ECE 391 MP2.2 grading program.

b. Button state shown in grading program must match pressed buttons.

1. Compatibility a. Connect device to host.

Run grading program. Compare image on computer screen to LEDs.

b. Connect device to host. Run button test program. Compare button states shown to presses.

20

3.3 Tolerance Analysis We will perform tolerance analysis on our joystick component. In our research we found that inexpensive micro­joysticks present a large range of voltages as the center position. If the range of voltages considered to be the center position is too large, it will be too difficult for

15

students to use it in applications. Our MCU program will only send position updates to the host PC when the joystick moves. Two conditions must be met by the joystick. The joystick must center at 2.5V +/­ 1.0V on X and Y. The joystick must hold its X and Y output voltage +/­ 0.2V when it is held at the edge of its range of motion in any direction.

4 Safety Statement The Tux Controller Mark II board consists of digital logic operating at low voltage. The controller is a bare PCB without an enclosure, so there are two primary concerns:

1. Through­hole components with sharp edges on the back side of the board. We can avoid this by selecting as many surface mount components as possible. For the remaining components that are through­hole, pins must be trimmed short and sharp edges must be removed.

2. Users must avoid placing the board on a conductive surface. This may permanently damage the device. The USB port on the host PC will survive as long as it conforms to the USB standard for hosts. Host ports have automatic short circuit protection that disables the port.

5 Ethics Statement The project presents few ethical concerns, but we still consider the following points from the IEEE Code of Ethics to be important to the project.

3. to be honest and realistic in stating claims or estimates based on available data; 5. to improve the understanding of technology; its appropriate application, and potential

consequences; 6. to maintain and improve our technical competence and to undertake technological

tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;

7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;

These points are relevant because we intend to hand off our design to the ECE 391 class and the electronics services shop. We must fully disclose all knowledge of our design and implementation, so they can produce and maintain working copies of our prototype. In regards to point 5, our project will be used by students to further their technical education and understanding of technology.

16

6 Cost and Schedule

6.1 Cost Analysis

6.1.1 Labor

Name Hourly Rate Total Hours Total = Hourly Rate x 2.5 x Total Hours

Eric $60.00 180 $27,000

Mika $60.00 180 $27,000

Total 360 $54,000

6.1.2 Parts

Item Manufacturer Part # Quantity Cost

MCU Microchip PIC18F4450 1 $5.00

USB Mini­B Connector Multicomp MC32599 1 $2.00

Jumper, 2 Position 3M 929950­00 1 $1.00

0.025” Post Header 1 $1.00

Mini Push Button Sparkfun COM­00097 9 $4.00

7 Segment Display Sparkfun COM­11405 1 $2.00

Quad PNP Transistor Fairchild MMBT2222A 4 $2.00

IR Receiver Vishay TSOP38238 1 $2.00

Accelerometer Analog Devices ADXL335 1 $15.00

Mini Joystick Sparkfun COM­09426 1 $4.00

Crystal, 20 Mhz Sparkfun COM­00534 1 $1.00

Resistor, 330 Ω 8 $0.80

Resistor, 470 Ω 1 $0.10

Resistor, 510 Ω 4 $0.40

17

Resistor, 10 kΩ 1 $0.10

Capacitor, 20 pF 2 $0.20

Capacitor, 10 nF 1 $0.10

Capacitor, 100 nF 7 $0.70

Capacitor, 470 nF 1 $0.10

Capacitor, 2.2 μF 2 $0.20

PCB 1 $30.00

PIC Programmer, Debugger

1 $50.00

Total $121.70

6.1.3 Grand Total

Section Total

Labor $54,000.00

Parts $121.70

Grand Total $54121.70

6.2 Schedule

Week Task Responsibility

9­Feb Research components, prepare proposal Eric

Investigate Tux protocol Mika

16­Feb Prepare design review schematics Eric

Prepare design review flowcharts Mika

23­Feb Order parts and set up programming software Eric

Design “mode 1” serial packets and Linux test program Mika

2­Mar Run initial tests on accelerometer and joystick Eric

18

Assemble breadboard prototype, test modules Mika

9­Mar Design PCB layout Eric

Program microcontroller Mika

16­Mar Order PCB Eric

Perform system tests on breadboard prototype Mika

23­Mar Spring Break Eric

Mika

30­Mar Debug breadboard prototype Eric

Assemble PCB Mika

6­Apr Perform module tests on PCB Eric

Perform system tests on PCB Mika

13­Apr Debug PCB Eric

Prepare demonstration Mika

20­Apr Prepare presentation Eric

Finalize demonstration Mika

27­Apr Prepare design files and engineering notes for course staff and services shop

Eric

Prepare final paper Mika

4­May Lab checkout Eric

Finalize final paper Mika

19

Appendix A: MTCP Protocol Description ;/*

; mtcp.h - Mouse/TuxController Protocol

; Mark Murphy 2006

;

; This header file defines the interface between the PC and the

; Mouse/TuxController boards. The overall philosophy was to incorporate

; both the functionality of the PS/2 Mouse (which is used by the 'layout'

; circuit simulator) as well as extend the functionality provided by the

; parallel-port based 2-button boards used previously for MP2's like the

; 'mazegame'.

;

; Commands sent from the PC to the MTC are variable length. Most are simple

; single-byte commands, however some require additional bytes to be sent.

; For example, to set the LED display, as many as 6 bytes can be sent. See

; the descriptions of individual commands for details.

;

; Responses from the MTC to the PC come in a single, 3-byte format. The

; three byte packets have a structure which is meant to allow for as much

; compatibility as possible with the PS/2 Mouse motion packet (see below).

; A few restrictions and changes had to be made to ensure higher reliability

; in the presence of untrustworthy operating systems ....

;

; (Don't worry that there is a lot of words in these next few paragraphs,

; pictures follow... )

;

; The high order bit of the first byte of a 3-byte packet will always be

; '0', and the high order bit of the second and third bytes will always be

; '1'. If the packet is a PS/2 Mouse emulation packet, then bit 6 will be '0'

; and bit 3 will be '1'; otherwise bit 6 will be '1' and bit 3 will be '0'.

; This leaves 5 bits in which to encode opcodes for non PS/2 responses, and

; 2 7-bit fields for data.

;

; This limits the X,Y movement values for the PS/2 emulation to 8 bit 2's

; compliment integers (in the actual PS/2 spec, they are 9-bits). If you are

; familiar with the PS/2 spec, notice that this also fixes the Y,X overflow

; fields to 0.

;

;

; In a more visual form:

;

; PS/2 Emulation:

; +-7-+-6-+-5--+-4--+-3-+-2-+-1-+-0-+

; 0 | 0 | 0 | YS | XS | 1 | M | R | L |

; +---+---+----+----+---+---+---+---+

; 1 | 1 | X Movement |

; +---+---+----+----+---+---+---+---+

; 2 | 1 | Y Movement |

; +---+---+----+----+---+---+---+---+

20

;

; Where:

; YS - Sign (8th bit) of the Y-movement value

; XS - Sign (8th bit) of the X-movement value

; M - Status of Middle button (1 when button is down)

; R - Status of Left button (1 when button is down)

; L - Status of Right button (1 when button is down)

;

; TuxController Responses:

; +-7-+-6-+-5--+-4--+-3-+--2-+--1-+--0-+

; 0 | 0 | 1 | R4 | R3 | 0 | R2 | R1 | R0 |

; +---+---+----+----+---+----+----+----+

; 1 | 1 | DATA |

; +---+---+----+----+---+----+----+----+

; 2 | 1 | DATA |

; +---+---+----+----+---+----+----+----+

;

; Where R[4:0] is the command response code, and the DATA fields are

; specific to each particular response.

;

;*/

;/*

; (For reference)

; PS/2 Mouse movement packet format:

;

; 7 6 5 4 3 2 1 0

; -------------------------------------

; Byte 0 | YO | XO | YS | XS | 1 | M | R | L |

; -------------------------------------

; Byte 1 | X Movement |

; -------------------------------------

; Byte 2 | Y Movement |

; -------------------------------------

; YO - Y overflow. Fixed 0 for MTC mouse packets

; XO - X overflow. Fixed 0 for MTC mouse packets

; YS - Y Sign

; XS - X Sign

; M - Middle Button pressed (active high)

; R - Right Button pressed (active high)

; L - Left Button pressed (active high)

;*/

#define MOUSE_Y0 0x80

#define MOUSE_X0 0x40

#define MOUSE_YS 0x20

#define MOUSE_XS 0x10

#define MOUSE_MIDDLE 0x04

#define MOUSE_RIGHT 0x02

21

#define MOUSE_LEFT 0x01

;/*

; MTC to PC first bytes. Limited to 32 opcodes, however the

; MTCP_BUTTON_POLL takes up 4 opcodes

; */

#define MTCP_RESP(n) (((n)&7) | (((n)&0x18)<<1) | 0x40)

#define MTCP_IS_MOUSE(n) (0x08 == ((n)&0xC8))

#define MTCP_ACK MTCP_RESP(0x0)

#define MTCP_BIOC_EVENT MTCP_RESP(0x1)

#define MTCP_CLK_EVENT MTCP_RESP(0x2)

#define MTCP_OFF_EVENT MTCP_RESP(0x3)

#define MTCP_POLL_OK MTCP_RESP(0x4)

#define MCTP_CLK_POLLMTCP_RESP(0x5)

#define MTCP_RESET MTCP_RESP(0x6)

#define MTCP_LEDS_POLL0 MTCP_RESP(0x8)

#define __LEDS_POLL01 MTCP_RESP(0x9)

#define __LEDS_POLL02MTCP_RESP(0xa)

#define __LEDS_POLL012 MTCP_RESP(0xb)

#define MTCP_LEDS_POLL1 MTCP_RESP(0xC)

#define __LEDS_POLL11 MTCP_RESP(0xd)

#define __LEDS_POLL12MTCP_RESP(0xe)

#define __LEDS_POLL112 MTCP_RESP(0xf)

#define MTCP_ERROR MTCP_RESP(0x1F)

;/*

; PC to MTC Command Opcodes - don't change these without changing the order

; of the jump table in mainloop.asm. The defines limit the number to 32.

; */

#define MTCP_CMD_MASK 0x1F

#define MTCP_CMD_CHECK_MASK 0xE0

#define MTCP_CMD_CHECK 0xC0

#define MTCP_CMD(c) (MTCP_CMD_CHECK | (c))

#define MTCP_OFF MTCP_CMD(0x0)

#define MTCP_RESET_DEV MTCP_CMD(0x1)

#define MTCP_POLL MTCP_CMD(0x2)

#define MTCP_BIOC_ON MTCP_CMD(0x3)

#define MTCP_BIOC_OFF MTCP_CMD(0x4)

22

#define MTCP_DBG_OFF MTCP_CMD(0x5)

#define MTCP_LED_SET MTCP_CMD(0x6)

#define MTCP_LED_CLK MTCP_CMD(0x7)

#define MTCP_LED_USR MTCP_CMD(0x8)

#define MTCP_POLL_LEDS MTCP_CMD(0x13)

#define MTCP_CLK_RESET MTCP_CMD(0x9)

#define MTCP_CLK_SET MTCP_CMD(0xa)

#define MTCP_CLK_POLLMTCP_CMD(0xb)

#define MTCP_CLK_RUN MTCP_CMD(0xc)

#define MTCP_CLK_STOPMTCP_CMD(0xd)

#define MTCP_CLK_UP MTCP_CMD(0xe)

#define MTCP_CLK_DOWNMTCP_CMD(0xf)

#define MTCP_CLK_MAX MTCP_CMD(0x10)

#define MTCP_MOUSE_OFF MTCP_CMD(0x11)

#define MTCP_MOUSE_ONMTCP_CMD(0x12)

;/*

; ************************** Commands ********************************

;

; Opcode: MTCP_RESET_DEV

; Reset the device. The device doesn't immediately respond, but

; generates an MTCP_RESET event when it is finished initializing

; itself.

;

; Opcode: MTCP_OFF

; Turn the MTC off. The RESET button on the board will need to be

; pressed for it to resume operation. It will generate an

; MTCP_OFF_EVENT before going to sleep. This is only a valid command

; when debug mode is off (i.e. the PC has sent an MTCP_DBG_OFF

; command).

;

; Opcode: MTCP_POLL

; Poll Buttons - get the current status of the 8 buttons.

; The bitmask is active low - a bit is clear when the corresponding

; button is pressed. The bitmask is split into two bytes.

;

; Response packet:

; byte 0 - MTCP_POLL_OK

; byte 1 __7_____4___3___2___1_____0____

; | 1 X X X | C | B | A | START |

; -------------------------------

; byte 2 __7_____4_____3______2______1_____0___

; | 1 X X X | right | down | left | up |

; --------------------------------------

;

; Opcode: MTCP_BIOC_ON

23

; Enable Button interrupt-on-change. MTCP_ACK is returned.

;

; Opcode: MTCP_BIOC_OFF

; Disable Button interrupt-on-change. MTCP_ACK is returned.

;

; Opcode MTCP_DBG_OFF

; Disable Debug-lockup mode. This sets the error-handling behavior;

; when debug-lockup is on, the device displays 0xdEAd on the LEDs and

; ceases responding to commands. MTCP_ACK is returned

;

; Opcode MTCP_LED_SET

; Set the User-set LED display values. These will be displayed on the

; LED displays when the LED display is in USR mode (see the MTCP_LED_USR

; and MTCP_LED_CLK commands). The first byte of argument specifies

; which of the LED's to set, and also determines how many bytes will

; follow - one byte for each led to set.

;

;

; Mapping from 7-segment to bits

; The 7-segment display is:

; _A

; F| |B

; -G

; E| |C

; -D .dp

;

; The map from bits to segments is:

;

; __7___6___5___4____3___2___1___0__

; | A | E | F | dp | G | C | B | D |

; +---+---+---+----+---+---+---+---+

;

; Arguments: >= 1 bytes

; byte 0 - Bitmask of which LED's to set:

; __7___6___5___4____3______2______1______0___

; | X | X | X | X | LED3 | LED2 | LED1 | LED0 |

; ----+---+---+---+------+------+------+------+

;

; The number of bytes which should follow should be equal to the

; number of bits set in byte 0. The bytes should be sent in order of

; increasing LED number. (e.g LED0, LED2, LED3 for a bitmask of 0x0D)

;

; Response: 1 byte

; byte 0 - MTCP_ACK

;

; Opcode MTCP_LED_CLK

; Put the LED display into clock mode. In this mode, the value of the

; clock is displayed, rather than the value set with MTCP_LED_SET.

;

24

; Opcode MTCP_LED_USR

; Put the LED display into user-mode. In this mode, the value specified

; by the MTCP_LED_SET command is displayed.

;

; Opcode MTCP_CLK_RESET

; Reset the clock. The clock value is set to zero, the direction is

; set to down, and it is stopped.

;

; Opcode MTCP_CLK_SET

; Set the value of the clock. There are two argument bytes, the first

; is the number of minues, the second is the number of seconds. If

; either argument is out of the range which makes sense, then the

; result is undefined.

;

; Arguments: 2 bytes

; byte 0 - Number of minutes to set (up to a maximum of 99).

; byte 1 - number of seconds to set (up do a maximum of 59).

;

; Opcode MTCP_CLK_MAX

; Set the maximum value of the clock. When the clock's direction

; is set to up and it counts to this value, the MTC will generate

; an MTCP_CLK_EVENT event.

; Arguments: 2 bytes

; byte 0 - Number of minutes to set (up to a maximum of 99).

;

; Opcode MTCP_CLK_POLL

; Command:

; Read the state of the clock. The result specifies whether the

; clock is running, its direction, and the current value in

; minutes and seconds.

; Arguments: 0 bytes

; Response packet:

; byte 0 : MTCP_POLL_OK

; byte 1 :

; +-7-+-6-5-4-3-2-1-0-+

; | 1 | Minutes |

; +---+---------------+

; byte 2 :

; +-7-+----6----+-5-4-3-2-1-0--+

; | 1 | Running | Seconds |

; +---+---------+--------------+

;

; Opcode MTCP_CLK_RUN

; Start the clock. If it was already running, then it will still

; be running after this command.

;

; Opcode MTCP_CLK_STOP

; Stop the clock. If it was already stopped, then it will still be

; stopped after this command.

;

25

; Opcode MTCP_CLK_UP

; Set the clock's direction to up. When running, It will count up

; until reaching the value set by MTCP_CLK_MAX, then generate a

; CLK_EVENT

;

; Opcode MTCP_CLK_DOWN

; Set the clock"s direction to Down. When running, it will count down

; until reaching zero, then generate a CLK_EVENT.

;

;*/

;/*

; ********************* Responses *************************

;

; MTCP_ERROR

; Response when the MTC has debug-lockup disabled and receives an

; unrecognized request from the PC.

;

; MTCP_ACK

; Response when the MTC successfully completes a command.

;

; MTCP_POLL_OK

; First byte of a response to a poll of either the buttons or the

; clock.

;

; MTCP_RESET

; Generated when the devide re-initializes itself after a power-up,

; a RESET button press, or an MTCP_RESET_DEV command.

;

; Packet Format:

; Byte 0 - MTCP_RESET

; Byte 1 - reserved

; Byte 2 - reserved

;

; MTCP_OFF

; Generated when the device is turning itself off after either an

; MTCP_OFF command or its internal 2-hour timer has expired. This

; timer is reset anytime there is serial communication activity,

; either to or from the device.

;

; Packet Format:

; Byte 0 - MTCP_OFF_EVENT

; Byte 1 - reserved

; Byte 2 - reserved

;

; MTCP_BIOC_EVT

; Generated when the Button Interrupt-on-change mode is enabled and

; a button is either pressed or released.

;

; Packet format:

26

; Byte 0 - MTCP_BIOC_EVENT

; byte 1 +-7-----4-+-3-+-2-+-1-+---0---+

; | 1 X X X | C | B | A | START |

; +---------+---+---+---+-------+

; byte 2 +-7-----4-+---3---+--2---+--1---+-0--+

; | 1 X X X | right | down | left | up |

; +---------+-------+------+------+----+

; MTCP_CLK_EVENT

; The clock has reached zero (when counting down) or its maximum value

; (when counting up).

;

; Packet format:

; Byte 0 - MTCP_CLK_EVENT

; Byte 1 - reserved

; Byte 2 - reserved

;

; MTCP_LEDS_POLL

; Since there are 32 bits of data to return with this response, the

; data format is a bit screwy. It will be 2 3-byte packets of the

; form described above, with a slight modification: the opcode will

; be used to encode some of the data. There is a different opcode

; for the first and second packets (1 bit of difference) to allow for

; detection of a dropped packet.

; The data from LED's 0 and 1 will be in the first packet, and the

; data from LED's 2 and 3 will be in the second packet. The data will

; be of the same format as the LED_SET command, except that the segA

; bits will be packed into the opcode, as shown in the diagram below

;

; In picto-gram form:

; Packet 0 will be:

; +-7-+-6-+-5-+--4-+-3-+-2-+-1--+-0--+

; 0 | 0 | 1 | 0 | 1 | 0 | 0 | A1 | A0 |

; +---+---+---+----+---+---+----+----+

; 1 | 1 | E | F | dp | G | C | B | D | (data for LED0)

; +---+---+---+----+---+---+----+----+

; 2 | 1 | E | F | dp | G | C | B | D | (data for LED1)

; +---+---+---+----+---+---+----+----+

;

; Packet 1 will be:

; +-7-+-6-+-5-+--4-+-3-+-2-+-1--+-0--+

; 0 | 0 | 1 | 0 | 1 | 0 | 1 | A1 | A0 |

; +---+---+---+----+---+---+----+----+

; 1 | 1 | E | F | dp | G | C | B | D | (data for LED2)

; +---+---+---+----+---+---+----+----+

; 2 | 1 | E | F | dp | G | C | B | D | (data for LED3)

; +---+---+---+----+---+---+----+----+

;

;*/

27