82
CY4636 WirelessUSB™ LP Keyboard Mouse Reference Design Kit User Guide, Doc. # 001-70355 Rev. *A
Code Examples
5.3.3.2
Application Code
The group of modules that make up the application code is responsible for implementing the key-
board functionality and behavior. Following is a high level description of each module responsibility
and associated algorithms.
Keyboard Module.
The keyboard module is the controlling code for the application. It has many
responsibilities in implementing various features and functions offered by the keyboard.
A few types are defined to support the operation of the keyboard. 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 function main() is the entry point for the keyboard application. This function is called from the
boot.asm file. The keyboard first initializes all of the application modules and then initializes the pro-
tocol module. There is an order dependency for some of these, so care must be taken in modifying
the keyboard_init() function. For example, other modules depend upon the timer facility running in
order to perform initialization. Once each module has been initialized, then the application checks for
entry to the manufacturing test mode. If the manufacturing test mode is not indicated, then normal
keyboard operation begins.
There are two states for the keyboard operation: the idle state and the active state. The keyboard ini-
tially enters idle state; when there is any keystroke, it enters the active state.
In active state the keyboard is scanned for both the keys and the Bind button. The keystrokes are
collected, formatted and reported to the bridge. After that, the keyboard goes into the idle state.
In idle state the MCU and radio go to sleep to save power, and the keyboard application remains
waiting for input from the keys or Bind button. The timer is turned off to conserve power. This state is
maintained indefinitely until a keystroke or a button press occurs.
The battery level is reported by the keyboard application when it detects a keystroke after it has
been in an idle state for 8 seconds.
In the active state the keyboard attempts to deliver a packet for the amount of time designated in
KEYBOARD_TX_TIMEOUT. The keyboard application is also responsible for detecting the Bind but-
ton press, and then calling the bind function in the protocol module.
The keyboard application sends keyboard reports as frequently as events arrive, but not any faster
than the time defined in the macro KEY_DOWN_DELAY_SAMPLE_PERIOD. Carefully set this time
so that the report rate does not exceed that which the USB bus is capable of handling. Keep in mind
that the report rate varies slightly due to drift of the internal oscillator used to keep track of time.
Mfgtest Module.
The RDK provides a compile-time option of adding a manufacturing test mode to
the keyboard. The manufacturing test code in this keyboard is compatible with the CY3631 Manufac-
turing Test Kit offered by Cypress Semiconductor.
If MFG_TEST_CODE is defined and ENTER_BY_PIN is not defined, holding down the system sleep
key and the Bind button while inserting the batteries into the keyboard will enter the manufacturing
test mode.
If MFG_TEST_CODE and ENTER_BY_PIN are both defined, connecting pins 4 and 5 on the ISP
header with a shunt and then inserting the batteries into the keyboard will enter the manufacturing
test mode. The only way to exit this mode is to cycle power.
Battery Module.
The battery monitor circuit is implemented using the Low Voltage Interrupt (LVI) on
the LP radio. Following is an explanation of the process to measure the battery voltage.