6
Firmware Implementation
The fi rmware for this reference design is written in the
Sunplus assembly language. The following fi les are
required to compile the mouse fi rmware.
SPCP825A _A6010.asm
–main mouse fi rmware.
hiddesc3.asm
- 3 buttons mouse mode USB descriptor ROM
tables.
Hiddesc5.asm
– USB 3 Key Mode Descriptor Rom Tables
pro_6010.asm
– Routine to access ADNS-6000 sensor
register.
SPCP825A.inc
– The SPCP825A I/O registers defi nition.
adns6010_SROM.inc
– ADNS-6000 SROM fi rmware.
ADNS6010.inc
– ADNS-6010 Sensor registers include fi les.
delay.inc
– SPCP825A delay loop subroutine.
decode_setup.inc
– USB descriptor and request constants.
det_Z.inc
– SPCP825A Z-axis event handler.
DET_KEY.inc
– SPCP825A button event handler.
MODE_SEL.inc
– Detect Bus status for USB mode.
StartUp.asm
– This include fi le is for AVAGO TECHNOLOGIES
ADNS-6010 Mouse Sensor laser power calibration.
At power up, the fi rmware examines the host interface
and automatically determines the mouse USB host con-
nection. Then the host fi rmware confi gures itself to
operate on the detected interface.
USB Interface
All USB Human Interface Device (HID) class applications
follow the same USB start-up procedure. The procedure is
as follows
1. Device Plug-in
When a USB device is fi rst connected to the bus, it is
powered and running fi rmware, but communications on
the USB remain non-functional until the host has issued
a USB bus reset.
2. Bus Reset
The pull-up resistor on D– notifi es the hub that a low
speed (1.5 Mbps) device has just been connected. The
host recognizes the presence of a new USB device and
initiates a bus reset to that device.
3. Enumeration
The host initiates SETUP transactions that reveal general
and device specifi c information about the mouse. When
the description is received, the host assigns a new and
unique USB address to the mouse. The mouse begins
responding to communication with the newly assigned
address, while the host continues to ask for information
about the device description, confi guration descrip-
tion and HID report description. Using the informa-
tion returned from the mouse, the host now knows the
number of data endpoints supported by the mouse (2). At
this point, the process of enumeration is completed.
Notes
1: idVendor should be changed to the value as supplied by the USB-IF
2: idProduct should be assigned for specifi c product.
3: MaxPower value should be changed as per specifi c circuit’s current
draw.
4. Post Enumeration Operation
Once communication between the host and mouse is es-
tablished, the peripheral now has the task of sending and
receiving data on the control and data endpoints. In this
case, when the host confi gures endpoint 1, the mouse
starts to transmit button and motion data back to the
host when there is data to send. At any time the periph-
eral may be reset or reconfi gured by the host.
USB Requests – Endpoint 0
Endpoint 0 acts as the control endpoint for the host.
On power-up endpoint 0 is the default communication
channel for all USB devices. The host initiates Control-
Read and Control-Write (see Chapter 8 of the USB specifi -
cation) to determine the device type and how to confi gure
communications with the device. In this particular design,
only Control-Read transactions are required to enumerate
a mouse. For a list of valid requests see Chapter 9 of the
USBG specifi cation. In addition to the standard “Chapter
9” requests, a mouse must also support all valid HID class
requests for a mouse.
USB Requests – Endpoint 1
Endpoint 1 is the data transfer communications channel
for mouse button, wheel, and movement informa-
tion. Requests to this endpoint are not recognized until
the host confi gures endpoint 1. Once this endpoint is
enabled, then interrupt IN requests are sent from the host
to the mouse to gather mouse data. When the mouse is
left idle (i.e. no movement, no new button presses, no
wheel movement) the fi rmware will NAK requests to this
endpoint. Data is only reported when there is a status
change with the mouse.
Two HID report formats are used in this design. The
boot protocol, as defi ned by the HID specifi cation, is the
default report protocol that all USB enabled systems un-
derstands. The boot protocol has a three-byte format, and
so does not report wheel information. The HID report de-
scriptor defi nes the report protocol format. This format is
four bytes and is the same as the report format with the
exception of the fourth byte, which is the wheel infor-
mation. Appendix F of this document lists the USB Data
Reporting Format.
