Filter
Top Products
42 CY4672 Reference Design Guide, Document # 001-16968 Revision **
Mouse
since the microcontroller sleep feature is used. Also, when polling is enabled, it is performed as a
background task during the millisecond delay.
This module also adjusts the tick advancement based upon the sleep resolution. Turning off the
timer provides for more power savings, yet a sense of time is still preserved for non-critical timing.
Note When using the ICE-Cube, define the macro PSOC_ICE so that busy waits are used instead of
the sleep instruction. Using the sleep instruction with the ICE-Cube generates errors due to synchro-
nization issues between the OCD part and the emulator.
3.3.4.10 ISR Module
This module provides an interface to initialize the interrupt.
3.3.5 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.
3.3.5.1 Mouse Module
The mouse module is the controlling code for the application. It has many responsibilities in imple-
menting various features and functions offered by the mouse. The data formats and reporting algo-
rithms along with power management are explained in this section.
A few format types are defined to support the operation of the mouse. One of these is the packet for-
mat used when sending data to the bridge. This type is defined as TX_PACKET and is structured to
support the different data packet formats as explained in the section Wireless Protocol Data Payload
on page 47. The present definition combines z-wheel data with button data into one byte in order to
conserve battery power by shortening the ‘on time’ of the radio. This format needs to change in order
to support 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; see Protocol Module on page 41. 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 in order to perform initialization. The spi module must be initialized before
the optical and protocol modules can be initialized; see SPI Module on page 40, Optical Module on
page 43 and Protocol Module on page 41. Once each module has been initialized, then the applica-
tion 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
[+] Feedback