70
CY4636 WirelessUSB™ LP Keyboard Mouse Reference Design Kit User Guide, Doc. # 001-70355 Rev. *A
Code Examples
5.2.3.2
Application Code
The group of modules that make up the application code are responsible for implementing the
mouse functionality and behavior. Following is a high level description of each module responsibility
and associated algorithms.
Mouse Module.
The mouse module is the controlling code for the application. It has many respon-
sibilities in implementing various features and functions offered by the mouse. The data formats and
reporting algorithms along with power management are explained in this section.
A few types are defined to support the operation of the mouse. One of these is the packet format
used when sending data to the bridge. This type is defined as TX_PACKET and is structured to sup-
port the different data packet formats as explained in the section Wireless Protocol Data Payload.
The present definition combines z-wheel data with button data into one byte in order to conserve bat-
tery power by shortening the on-time of the radio. This format would need to change in order to sup-
port a mouse with more than three buttons and a z-wheel, perhaps sending four bytes instead of
three.
The function main() is the entry point for the mouse application. This function is called from the
boot.asm
file. The mouse first initializes all of the application modules and then initializes the proto-
col module. There is an order dependency for some of these, so care must be taken in modifying the
mouse_init() function. For example, other modules depend upon the timer facility running to perform
initialization. The spi module must be initialized before the optical and protocol modules can be ini-
tialized. Once each module has been initialized, then the application checks for entry to the 'LP' draw
test mode or the manufacturing test mode. If neither of the test modes is indicated, then normal
mouse operation begins.
The mouse module handles a variety of events at the main thread level. Most interrupt routines post
notification that an event occurred by using the macros provided by the mouse interface. The mouse
then processes these events at thread context rather than interrupt context.
The mouse application is implemented using a state machine to manage the various power modes
that it executes at any given time.
The mouse initially enters a disconnected state. When there is any mouse activity, it enters the
active state.
In the active state the timer is turned on so that more accurate timing and mouse events can be col-
lected, formatted and reported to the bridge. The mouse remains in this state as long as there is
mouse activity to report to the bridge or a period of time without any mouse activity has expired, after
which it returns to the idle state. If the mouse is unable to deliver a packet while in this state, it transi-
tions to the disconnected state.
In idle state the optical sensor is allowed to transition through its various rest modes to conserve
power. In this state, the mouse application is waiting for input from the optical sensor, z-wheel or but-
tons.
The timer is turned off to conserve power and the notion of time is maintained using the sleep timer.
This state is maintained indefinitely until the batteries drop below 1.8 volts at which point the mouse
enters the off state.
The off state is where the radio and optical sensor are prevented from turning on. This state is
reached when the battery voltage drops below 1.8 volts. It is designed to keep the battery drain to an
absolute minimum to prevent battery leakage as a result of completely draining the batteries.
The battery level is reported by the mouse application when it detects a change from the discon-
nected state to the connected state. The battery level is measured when exiting the idle state. If
there is a change in the battery level, then it will be reported in the active state.
