Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
This page describes the Advanced Remote sample application that comes as part of the RemoTI-1.4.0 installer. It runs on the Advanced Remote hardware which is part of the CC2533 RF4CE Development Kit. The Advanced Remote is an advanced programmable RF4CE remote with motion sensors (3-axis accelerometer and 3-axis gyroscope), enabling air mouse functionality with Movea's motion sensing SW. The kit comes with two different USB dongles. The big CC2531 USB dongle can easily be programmed and is the one we refer to on this page. The CC-Debugger is a USB debug probe for programming and debugging applications running on the Advanced Remote and the USB dongle. For more information on RF4CE development, please see the RemoTI Developer's Guide.
- 1 Quick Start
- 2 Sample Application
- 2.1 Features
- 2.1.1 Pairing/Binding
- 2.1.2 Key Matrix Scanning
- 2.1.3 Key Code to Command Mapping
- 2.1.4 Motion Sensing
- 2.1.5 Air Mouse Operation
- 2.1.6 Latency Test Mode
- 2.1.7 Enhanced Security
- 2.1.8 Remote Finder
- 2.2 Project
- 2.3 Porting from RemoTI-1.3.1
- 2.1 Features
The kit comes programmed with firmware from the previous release of RemoTI. To use the updated features of ZRC2.0 profile follow steps 1 and 2, if not skip to step 3.
- Update Advanced Remote firmware
Open the battery compartment and locate the 10-pin header mounted on the PCB. It's accessible through a hole in the plastic. Connect the 10-pin ribbon cable to the 10-pin header, and the other end to the CC-Debugger via the small adaptor. Either power the Advanced Remote with batteries or by connecting pins 2 and 9 on the small adaptor. Press the button on the CC-Debugger and check that the LED turns green, this indicates that the connection is good. Connect CC-Debugger to a PC and run Smart RF Flash Programmer (version 1). Locate the updated firmware, typically found here: "C:\Texas Instruments\RemoTI-CC253xDK-1.4.0\bin\AdvancedRemote-CC2533F96.hex".
- Update the CC2531 USB Dongle firmware. Connect the 10-pin ribbon cable to the 10-pin header, and the other end to the CC-Debugger via the small adaptor. Either power the dongle via USB or by connecting pins 2 and 9 on the small adaptor. Press the button on the CC-Debugger and check that the LED turns green, this indicates that the connection is good. Connect CC-Debugger to a PC and run Smart RF Flash Programmer (version 1). Locate the updated firmware, typically found here: "C:\Texas Instruments\RemoTI-CC253xDK-1.4.0\bin\ZRC-Dongle.hex".
- Plug the CC2531 USB Dongle in a device that supports USB HID (e.g. PC or MAC).
- Place batteries in the Advanced Remote
- Press the red button on the Advanced Remote
- Within 30 seconds press button 'S1' on the dongle.
- The Advanced Remote will sound a beep when paired.
- You can now use the buttons on the remote to adjust the volume
- Press and hold the middle button to control the mouse pointer.
This section describes the sample application for the Advanced Remote in details
- Compliance with ZigBee ZRC2.0 profile
- Enhanced Security
- Polling (Find my remote)
- Air-Mouse mapped to HID actions
- Advanced Buzzer feedback
- Automatic key remapping (data sent based on recipients profiles)
- 3 x 16 key matrix scanning
- Up to 10 pairing entries
- Latency and FCC test modes
The advanced remote controller sample application triggers validation based binding simply by calling
RTI_BindReq() upon receiving a ‘RED’ binding key press event. RTI and GDP, in turn, perform discovery,pairing and profile configuration in sequence. This will create a temporary pairing with the best pairing candidate, and then GDP validation based binding will require a button press on the target or entry of a pin code on the remote controller to validate the pairing. Once validated, the binding is considered complete.
When GDP performs discovery, it specifies the ZRC 1.x and 2.x profiles and searches for any device type. This behavior is defined in configParamTable located in rti.h, and is read at the time of generating a discovery request in the GDP profile
GDP filters the discovered node descriptor by looking at the device type of the node descriptor. The device type list of a node descriptor is compared against the supported target device type list set by a RTI configuration parameter
RTI_CP_ITEM_NODE_SUPPORTED_TGT_TYPES. Supported target types can be set up to six entries. In order to change this behavior, modify the
gdpDoCheckNodeDeviceCapabilities() function. In order to simply increase the maximum number of supported target types, change
RTI_MAX_NUM_SUPPORTED_TGT_TYPES constant in rti.h file and rebuild RTI module, rti.c file.
Once discovery completes with an acceptable node descriptor, the
rcnNlmePairReq_t structure is built and the
RCN_NlmePairReq() function is called to move on with the network layer pairing procedure. See the
gdpPo_SendPairRequest() function for details.
When binding successfully completes, the application sets the destination target (
rsaDestIndex, used for destination of any commands till next change) with the newly bound entry in the
RTI_ BindCnf() callback function. This RTI callback function is triggered from the GDP profile when validation is successful.
Once the pairing table is full, the advanced remote sample application won’t be able to pair with a new device any longer. Pressing the stop key for five seconds causes the application to restart with the NIB containing the pairing table reset to its default values. In order to change such usage of a the stop key, modify the
RSA_KeyCback() function. Refer to the RemoTI API guide for the effect of state attribute clearing.
The advanced remote controller sample application can cancel an on-going pairing procedure by pressing the ‘RED’ key again. Note that cancellation of on-going pairing by the user is not recommended as the pairing progress is unknown to the user.
Key Matrix Scanning
Key matrix scanning is implemented in the
hal_key.c file. This implementation is specific to the Advanced Remote hardware, hence it is located in a target specific folder, "\Components\hal\target\CC2533ARC".
In the beginning of the
hal_key.c module, certain constants are defined with arbitrary choice. Following is a list of configurable constant values.
|Constant Name||Default Value||Description|
||25||Key de-bounce timer duration in milliseconds. Default value is set to 25 milliseconds. The value should be adjusted to fit the hardware.|
||100|| Polling timer value used in non-interrupt driven key scanning scheme. The polling timer value for interrupt driven key scanning scheme is hard coded to 50 milliseconds to conform to ZRC profile specification.
To change the hard-coded timer value, change the third argument of
Note that there are other constants defined in the
hal_key.c module. However, other configuration constants such as using port 1 for column and port 0 for row cannot be modified without potentially changing other parts of the code or at least testing and verifying the change.
Key Code to Command Mapping
The key scanner returns a code which can be used as an index in a look up table. The code is a combination of row and column, where the 4 least significant bits is the column and the next 2 bits is the row. This code is passed to the callback function in the application
RSA_KeyCback( uint8 key, uint8 state ). After processing the state of the key, which tracks repeated keys, the key code is passed to the processing function
rsaProcessKeyEvent( rsaKeyIds[currentKeyPressed], keyState ). During this call a lookup is performed in the table
rsaKeyIds. The lookup in
rsaKeyIds provides a new index to another lookup table. This table,
rsaKeyMap, maps a key with an action, a CERC command and an HID command. Having two tables allows reuse of code for different hardware with very different key layout.
There are basically two types of actions; transmit action
RSA_ACT_XMIT and special function action
RSA_ACT_*. Transmit actions are passed to the function
rsaProcessXmitKey() whereas the
RSA_ACT_* actions are mapped to different special functions.
|Row/Column Code --> Key ID Look Up Table||Key ID --> Command and Action Look Up Table|
Special Function Actions
|Macro Value||Macro Name||Function|
Depending of the current state different actions are actually taken based on the key. If bound/paired and ready to transmit then the currently paired node is checked. If the node supports ZRC2.0 then a ZRC2.0 formatted command is sent. If it also supports HID capabilities and the key has a valid HID command then an HID keyboard report is composed. If not then a normal CERC action is sent. If the node only supports ZRC1.1 or lower then a standard ZRC1.1 command is sent.
The advanced remote hardware has the ability to function as an air mouse. In this mode, the advanced remote generates mouse movement information based on readings obtained from the motion sensing hardware. The mouse movement information is transmitted to a ZRC2.0 node, that is HID enabled, via vendor specific ZRC2.0 Actions. The commands for the vendor specific actions are standard HID formatted mouse reports. The motion sensing hardware consists of an IMU-3000 gyroscope and a KXTI9 accelerometer. The purpose of the gyroscope is to provide movement information in the X axis (i.e. side to side), and the Z axis (up and down). The accelerometer provides roll compensation, which means the X and Z axis information provided by the gyroscope will be compensated by the tilt angle of the remote to produce the same movement information as if the remote was held horizontally. The raw motion sensor samples are processed by a 3rd party motion processing library (produced by Movea), which generates the mouse movement information which is sent to the recipient HID mouse reports.
The motion sensing algorithm can be calibrated by pressing the blue button. The remote needs to stay still while calibrating. Since the bottom of the remote is curved it is recommended to place the remote upside down while calibrating. Calibration can take up to 30 seconds. Wait for the buzzer to beep a confirmation signal before resuming normal operation.
Air Mouse Operation
Air mouse is activated by pressing the middle button. While this button is being held down the remote will transmit mouse pointer coordinate increments/decrements at a rate of about 100Hz. If the middle button is double-clicked, i.e. pressed twice fast two times in a row, then the remote will continue to transmit mouse coordinates increments/decrements even when the button is not being held down. To exit this mode simply double-click again. The buttons to the left and right of the middle button acts as left and right mouse click respectively. See the ZRC Dongle Developer's Guide for details about how the mouse data is formatted and used on the Recipient side.
If the mouse pointer moves too quickly, or too slow, you can actually change the sensitivity on the remote itself. It can be viewed as a resolution control of the X and Y coordinate increments/decrements. Press FAV to decrease resolution and TV to increase resolution.
Latency Test Mode
See this page for details.
The advanced remote supports and can demonstrate Enhanced Security as defined in the GDP2.0 specification. Since Enhanced Security is an optional GDP profile feature, please see the RF4CE Developer's Guide for details on how the stack is configured to enable this feature. Enhanced Security involves a Key Exchange procedure which may be invoked at anytime after the binding is completed. Thus the advanced remote sets up
rsaGdpCapabilities with the
GDP_CAP_SUPPORT_ENHANCED_SECURITY_MASK and assigns the AV key to the action of initiating the Key Exchange procedure. At any time after the remote is bound with a recipient that supports Enhanced Security, the user may press the AV key on the remote which invokes
RTI_KeyExchangeReq() and observe the Key exchange procedure take place, after which the remote and recipient should operate using the new network key. For details on the Key Exchange procedure, please see the GDP2.0 specification.
The advanced remote supports a remote finder feature where, if the remote control is physically lost such as under the couch or in the toy box, the user can initiate an action on the target to cause the remote to identify itself via a buzzer ring. This feature is made possible through the poll based transmission scheme and client notification command of the GDP2.0 profile.
The feature can easily be demonstrated using the Target Emulator and Advanced Remote. To do so, open the Target Emulator and bind the Advanced Remote to it. After binding is complete, the GDP Poll Negotiation Procedure should execute automatically after which the Advanced Remote should start polling the Target. The interval at which the Advanced Remote will poll is specified by the Target Emulator and is defaulted to 3 seconds. The poll interval can be changed by selecting Options->Polling Time Interval. Once the Advance Remote is polling the target, you can exercise the remote finder feature by selecting Options->Find My Remote. Choose the Identify Time, which is how long the remote will identify itself, and the form of identification you want the remote to perform, which in this case the Advanced Remote only supports buzzing. Press the Find My Remote button, and upon next poll, the Advanced Remote should receive the Client Notification command to Identify itself by buzzing for the specified time. The processing of this notification occurs in
The remote finder feature is made possible by configuring the Target Emulator as a Poll Server and the Advanced Remote as Poll Client. For more details on the GDP Polling scheme and Client Notifications including the Identify command, please see the GDP2.0 Profile. It should be noted the remote finder can be a very powerful feature, but polling scheme could have adverse effects on the remote control battery life. Careful consideration should be given to a specific remote control's application to find the best balance between polling frequency and battery life.
The RemoTI Advanced Remote sample application project is located in the folder C:\Texas Instruments\RemoTI-CC253xDK-1.4.0\Projects\RemoTI\AdvancedRemote\CC253xRC. When you open the workspace file (rsa_cc2533.eww) you can select different project configurations.
|CC2533F96||Configuration useful for debugging|
|CC2533F96-HEX||Configuration generates a .hex file that can be used with Smart RF Flash Programmer|
OSAL task synchronization
TI's OSAL is a very thin software framework where tasks can be defined with their own entry point and messages and events are exchanged between tasks.
The advanced remote sample application does not use its own OSAL NV item but the application can be modified to use its own NV items through the Simple Non-Volatile Memory API if necessary.
The CC2533 has its own IEEE address built into the chip (information page IEEE address). This is the IEEE you get when reading back the primary IEEE address using Smart RF Flash Programmer. The Network Layer uses this address unless an address other than 0xFFFFFFFFFFFFFFFF has been set by upper layers. Upon reset the rti.c module will check a specific location in flash for an IEEE address. This location is always in the last page of the flash, which is a read-only page when the chip is not running in debug mode. It is the last 8 bytes just before the lock bits, and also what you get when reading/writing the secondary IEEE address using Smart RF Flash Programmer.
The upper layer can overwrite the IEEE address other than via the secondary IEEE address. It is writable via
RTI_WriteItemEx(RTI_PROFILE_RTI, 0x84, 8, pIEEEaddress).
RTI_WriteItemEx(RTI_PROFILE_RTI, 0x84, ...) is routed down to the Network Layer and updates the IEEE address correctly. Note that the order of when it is updated matters. To explain better please consider the following initialization sequence
|1.||RCN_Init()||-||Reads IEEE from NV. If it doesn't exist, which is the case on first boot, or if it matches 0xFFFFFFFFFFFFFFFF, then the primary IEEE address is used. The updated address is written to NV.|
|2.||RTI_Init()||-|| Calls |
|Address information valid for F96 flash size configuration||Debug||Page 127||Lock Bits, one per page|| Page
|LSB||IEEE||MSB||Read-only program code|
|Read-only program code continue|
Flash Page Map and Memory Map
The flash is divided into sections for application code, non-volatile memory, and a special page for commissioned IEEE address and lock bits.
Stack and Heap
The 8051 micro-controller uses a variety of data memory access methods, among them, most distinctively, one for internal data memory with 8 bit address space (IDATA) and for external data memory with 16 bit address space (XDATA).
See this page for details.
The Advanced Remote sample application uses the following resources:
- Peripheral IO pin P1_0 for the buzzer
- Peripheral IO pins P0_0, P0_1, P0_2, P0_3, P0_4, and P1_4 for the key matrix.
- Peripheral IO pins P0_5, P0_6, P0_7, P1_2, and P1_3 for the motion sensor hardware
- DMA channel 0 for non-volatile memory access
- DMA channel 1 and 2 for AES encryption/decryption
- Timer2 (MAC timer) and sleep timer.
- Timer 4 for buzzer operation
C source files and library files are explained in table below in the order that appears in the IAR workspace window. Note that there are more files than those listed in the table, such as C header files that define constants and function prototypes and also note that workspace project itself does not list all header files referenced by the C files.
|rcn_config.c||Network layer configuration file. The file contains global variables with initial values which are used as configuration parameters by RemoTI network layer.|
|rsa_main.c||C main routine implementation which calls all necessary initialization and then calls OSAL|
|rsa_osal.c||OSAL task definition and initialization|
|rsa_point.c||Advanced Remote application code implemented on top of RemoTI application framework|
|hal_assert.c||HAL assertion library|
|hal_drivers.c||Entry point for congregation of HAL drivers, such as initialization for all HAL drivers, HAL task, as an OSAL task, entry point (event handler) and polling entry point.|
|hal_rpc.h||Remote procedure call enumerations|
|hal_accel.c||KXTI9 Accelerometer device driver|
|hal_aes.c||AES device driver|
|hal_batmon.c||CC2533 Battery Monitor driver|
|hal_board_cfg.h||RemoTI advanced remote hardware specific configuration parameters and macros used by HAL. Application also frequently uses board definition literal (HAL_BOARD_CC2533ARC_RTM) and HAL feature flags (HAL_KEY, HAL_LED, etc).|
|hal_buzzer.c||Buzzer device driver|
|hal_ccm.c||CCM implementation using AES device driver|
|hal_dma.c||DMA device driver|
|hal_flash.c||CC2533 flash device driver|
|hal_gpiodbg.c||Driver for spare GPIO pins|
|hal_gyro.c||IMU-3000 Gyro device driver|
|hal_key.c||Key matrix driver|
|hal_motion.c||Motion Sensor subsystem (Gyro + Accelerometer control) driver.|
|hal_sleep.c||Sleep mode (PM1, PM2, PM3) control implementation|
|hal_startup.c||Low level initialization code|
|hal_vddmon.c||Vdd monitoring service|
|AIR_MOTION_LIB_3G3A-Banked.r51||Motion library from Movea|
|OSAL.c||OSAL implementation for messaging and main event handling loop|
|OSAL_Clock.c||OSAL clock tick implementation|
|OSAL_Math.s51||Optimized assembly function for division calculation|
|OSAL_Memory.c||OSAL heap implementation|
|OSAL_PwrMgr.c||OSAL power management scheme implementation|
|osal_snv.c||OSAL Simplified Non-Volatile memory manager. This has better code size optimization than OSAL_Nv.c module.|
|OSAL_Timers.c||OSAL timer implementation|
|gdp.c||Implements GDP profile|
|gdp_binding_originator.c||Implements the binding related part of the GDP profile|
|gdp_common.c||Implements the part of GDP that is common between Originator and Recipient|
|gdp_configuration_originator.c||Originator node implementation of the configuration state of the GDP 2.0 binding procedure|
|gdp_discovery_originator.c||Originator node implementation of the discovery state of the GDP 2.0 binding procedure|
|gdp_enhanced_security.c||Implementation of the Enhanced Security feature|
|gdp_identification_client.c||Definitions for a GDP Identification Client|
|gdp_originator_task.c||GDP Originator task definitions|
|gdp_pairing_originator.c||Originator node implementation of the pairing state of the GDP 2.0 binding procedure|
|gdp_poll_client.c||Definitions for a GDP Polling Client|
|gdp_validation_originator.c||Originator node implementation of the validation state of the GDP 2.0 binding procedure|
|zrc.c||Definitions for a ZRC2.0 Profile|
|zrc_action_mapping_client.c||Definitions for an Action Mapping client|
|zrc_binding_originator.c||Handles the binding procedure for a ZRC 2.0 Originator node|
|zrc_configuration_originator.c||Originator node implementation of the ZRC configuration state of the GDP 2.0 binding procedure|
|zrc_home_automation_client.c||Home Automation Client implementation|
|rti.c||Implements an interface for the application.|
|rti.h||Provides defines for the application interface|
|rti_testmode.c||RemoTI test mode API function implementation|
The Advanced Remote sample application software uses services of HAL, OSAL and RemoTI application framework. The RemoTI application framework abstracts RemoTI network layer and profile layer (GDP+ZRC). The RemoTI application framework and the profile layer is provided as source code and is itself part of application from RF4CE network layer perspective. HAL, OSAL and the RemoTI stack interact with one another as illustrated in the figure below.
Porting from RemoTI-1.3.1
Please see separate page for information about how to port from RemoTI-1.3.1 to RemoTI 1.4.0. Another very useful approach is to use a visual comparison tool.