Cypress CY4672 manual Application Code, ISR Module, Mouse Module

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.10ISR Module

This module provides an interface to initialize the interrupt.

3.3.5Application 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.1Mouse 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

42 CY4672 Reference Design Guide, Document # 001-16968 Revision **

[+] Feedback