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.

RemoTI-1.4.0-AdvancedRemote

From Texas Instruments Wiki
Jump to: navigation, search


CC2533-RF4CE-Kit-Pairing.jpg

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.

Quick Start

CC2533-RF4CE-Kit-Pairing.jpg

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.

  1. 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".
  2. 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".
  3. Plug the CC2531 USB Dongle in a device that supports USB HID (e.g. PC or MAC).
  4. Place batteries in the Advanced Remote
  5. Press the red button on the Advanced Remote
  6. Within 30 seconds press button 'S1' on the dongle.
  7. The Advanced Remote will sound a beep when paired.
  8. You can now use the buttons on the remote to adjust the volume
  9. Press and hold the middle button to control the mouse pointer.






Sample Application

This section describes the sample application for the Advanced Remote in details

Features

  • 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


Pairing/Binding

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 gdpDo_StartDiscoveryProcedure() function.

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".

Scanning scheme

The key matrix is attached to peripheral IO pins in the CC2533 Advanced Remote reference platform, as shown here.

In the Advanced Remote reference platform, GPIOs are used to control the key switch matrix, which is implemented via a combination of GPIO pins and a shift register array. Initially, all row IO port pins are configured as pull-up input pins with falling edge interrupt setup, and all column port pins are configured to output low so that any key press triggers an interrupt with the IO port associated with row pins.

Once the interrupt is triggered, the de-bounce timer is triggered to ignore de-bouncing. On expiry of the de-bounce timer, key scanning is performed periodically till no key press is detected. Periodical key scanning is used so that a continuous key depress generates repeated key press events. The flow of key scanning state changes are shown in the figure on the right.

Key scanning itself is performed by shifting a ‘1’ through the shift register by setting P1_4 to a ‘1’, and then repeatedly writing a ‘1’ and then ‘0’ to P0_3 to clock the shift register, with P1_4 set to ‘0’ (so that a single ‘1’ value is clocked in). Each time the shift register is clocked, column pins KPb0, KPb1, and KPb2 are read. For instance, in Figure 2, when KP31 is pressed, the GPIO associated with KPb0 will read a ‘1’ when the shift register is clocked enough times for the ‘1’ to reach KPa13. At the end of key scanning, a configured callback function is called to pass the scanned key code.

Key scan state flows and scanning itself are implemented in hal_key.c module specific to the CC2533 Advanced Remote platform.

KeyScanningFlow.png CC2533 AdvancedRemote KeyScanningSchematic.png

Configuration

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
HAL_KEY_DEBOUNCE_VALUE 25 Key de-bounce timer duration in milliseconds. Default value is set to 25 milliseconds. The value should be adjusted to fit the hardware.
HAL_KEY_POLLING_VALUE 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 osal_start_timerEx(Hal_TaskID, HAL_KEY_EVENT, 50) call in HalKeyPoll() function.

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
Index Row/Col Code Macro Name Macro Value
0 0b00 00 0000 NONE
1 0b00 00 0001 NONE
2 0b00 00 0010 RSA_KEY_ID_MENU 0
3 0b00 00 0011 RSA_KEY_ID_NAV_LEFT 1
4 0b00 00 0100 RSA_KEY_ID_REWIND 2
5 0b00 00 0101 RSA_KEY_ID_MOUSE_LEFT 3
6 0b00 00 0110 RSA_KEY_ID_VOL_DOWN 4
7 0b00 00 0111 RSA_KEY_ID_VOL_UP 5
8 0b00 00 1000 RSA_KEY_ID_RECORD 6
9 0b00 00 1001 RSA_KEY_ID_1 7
10 0b00 00 1010 RSA_KEY_ID_AV 8
11 0b00 00 1011 NONE
12 0b00 00 1100 RSA_KEY_ID_RED 9
13 0b00 00 1101 RSA_KEY_ID_7 10
14 0b00 00 1110 RSA_KEY_ID_4 11
15 0b00 00 1111 NONE
16 0b00 01 0000 RSA_KEY_ID_FAV 12
17 0b00 01 0001 RSA_KEY_ID_VOD 13
18 0b00 01 0010 RSA_KEY_ID_NAV_DOWN 14
19 0b00 01 0011 RSA_KEY_ID_OK 15
20 0b00 01 0100 NONE
21 0b00 01 0101 RSA_KEY_ID_MOUSE_MIDDLE 16
22 0b00 01 0110 RSA_KEY_ID_NAV_UP 17
23 0b00 01 0111 RSA_KEY_ID_MUTE 18
24 0b00 01 1000 RSA_KEY_ID_PLAY 19
25 0b00 01 1001 RSA_KEY_ID_2 20
26 0b00 01 1010 RSA_KEY_ID_0 21
27 0b00 01 1011 RSA_KEY_ID_YELLOW 22
28 0b00 01 1100 RSA_KEY_ID_GREEN 23
29 0b00 01 1101 RSA_KEY_ID_8 24
30 0b00 01 1110 RSA_KEY_ID_5 25
31 0b00 01 1111 NONE
32 0b00 10 0000 RSA_KEY_ID_POWER 26
33 0b00 10 0001 RSA_KEY_ID_TV 27
34 0b00 10 0010 RSA_KEY_ID_BACK 28
35 0b00 10 0011 RSA_KEY_ID_NAV_RIGHT 29
36 0b00 10 0100 RSA_KEY_ID_FFWD 30
37 0b00 10 0101 RSA_KEY_ID_MOUSE_RIGHT 31
38 0b00 10 0110 RSA_KEY_ID_CH_DOWN 32
39 0b00 10 0111 RSA_KEY_ID_CH_UP 33
40 0b00 10 1000 RSA_KEY_ID_STOP 34
41 0b00 10 1001 RSA_KEY_ID_3 35
42 0b00 10 1010 RSA_KEY_ID_PAUSE 36
43 0b00 10 1011 RSA_KEY_ID_BLUE 37
44 0b00 10 1100 NONE
45 0b00 10 1101 RSA_KEY_ID_9 38
46 0b00 10 1110 RSA_KEY_ID_6 39
Index Action CERC Code HID Code Button Name
--
--
0 RSA_ACT_XMIT ROOT_MENU N/A MENU
1 RSA_ACT_XMIT LEFT KEYBOARD_LEFT_ARROW NAV LEFT
2 RSA_ACT_XMIT REWIND N/A REV
3 RSA_ACT_XMIT N/A MOUSE_BUTTON_LEFT MOUSE LEFT
4 RSA_ACT_XMIT VOLUME_DOWN N/A VOL-
5 RSA_ACT_XMIT VOLUME_UP N/A VOL+
6 RSA_ACT_XMIT RECORD N/A REC
7 RSA_ACT_XMIT NUM_1 KEYBOARD_1 1
8 RSA_ACT_KEY_EX N/A N/A AV
--
9 RSA_ACT_PAIR N/A N/A RED (K1)
10 RSA_ACT_XMIT NUM_7 KEYBOARD_7 7
11 RSA_ACT_XMIT NUM_4 KEYBOARD_4 4
--
12 RSA_ACT_MOUSE_RES_DECREASE N/A N/A FAV
13 RSA_ACT_XMIT VIDEO_ON_DEMAND N/A VOD
14 RSA_ACT_XMIT DOWN KEYBOARD_DOWN_ARROW NAV DOWN
15 RSA_ACT_XMIT SELECT KEYBOARD_RETURN OK
--
16 RSA_ACT_MOUSE_CTL N/A N/A MOUSE MIDDLE
17 RSA_ACT_XMIT UP KEYBOARD_UP_ARROW NAV UP
18 RSA_ACT_XMIT MUTE N/A MUTE
19 RSA_ACT_XMIT PLAY N/A PLAY
20 RSA_ACT_XMIT NUM_2 KEYBOARD_2 2
21 RSA_ACT_XMIT NUM_0 KEYBOARD_0 0
22 RSA_ACT_UNPAIR N/A N/A YELLOW (K3)
23 RSA_ACT_TEST_MODE N/A N/A GREEN (K2)
24 RSA_ACT_XMIT NUM_8 KEYBOARD_8 8
25 RSA_ACT_XMIT NUM_5 KEYBOARD_5 5
--
26 RSA_ACT_XMIT POWER_TOGGLE_FUNCTION N/A POWER
27 RSA_ACT_MOUSE_RES_INCREASE N/A N/A TV
28 RSA_ACT_XMIT BACKWARD N/A BACK
29 RSA_ACT_XMIT RIGHT KEYBOARD_RIGHT_ARROW NAV RIGHT
30 RSA_ACT_XMIT FAST_FORWARD N/A FFWD
31 RSA_ACT_XMIT N/A MOUSE_BUTTON_RIGHT MOUSE RIGHT
32 RSA_ACT_XMIT CHANNEL_DOWN N/A CH-
33 RSA_ACT_XMIT CHANNEL_UP N/A CH+
34 RSA_ACT_XMIT STOP N/A STOP
35 RSA_ACT_XMIT NUM_3 KEYBOARD_3 3
36 RSA_ACT_TOGGLE_POLL N/A N/A PAUSE
37 RSA_ACT_MOUSE_CAL N/A N/A BLUE (K4)
--
38 RSA_ACT_XMIT NUM_9 KEYBOARD_9 9
39 RSA_ACT_XMIT NUM_6 KEYBOARD_6 6

Special Function Actions

Macro Value Macro Name Function
0xB0 RSA_ACT_PAIR rsaPairKeyAction()
0xB1 RSA_ACT_UNPAIR rsaUnpairKeyAction()
0xB2
RSA_ACT_MOUSE_RES_INCREASE
rsaAirMouseResolutionIncrease()
0xB3 RSA_ACT_TEST_MODE rsaToggleTestModeKeyAction()
0xB4 RSA_ACT_MOUSE_CAL rsaAirMouseCalKeyAction()
0xB5 RSA_ACT_MOUSE_CTL rsaAirMouseCursorCtl()
0xB6
RSA_ACT_MOUSE_RES_DECREASE
rsaAirMouseResolutionDecrease()
0xB7 RSA_ACT_KEY_EX rsaKeyExchangeKeyAction()
0xB8 RSA_ACT_TOGGLE_POLL rsaTogglePollAction()


Transmit Actions

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.


Motion Sensing

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.

Calibration

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.

Sensitivity Control

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.

Enhanced Security

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.


Remote Finder

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 rsaProcessClientNotification().

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.

Project

Build configurations

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.

Configuration Description
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.

Non-volatile Memory

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.

IEEE Address

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 rtiProgramIeeeAddr(). This routine reads the secondary IEEE and compares it with 0xFFFFFFFFFFFFFFFF. If it does not match 0xFFFFFFFFFFFFFFFF then it routed to the Network Layer. This will also update the IEEE address in NV.


Address 0x17FFF 0x17FEF 0x17FE8 0x17FE0
Address information valid for F96 flash size configuration Debug Page 127 Lock Bits, one per page Page
0
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.

Peripheral Usage

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

Files

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.

File name Description
Application
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
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_i2c.c I2C 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
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
Profiles
GDP
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
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
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














































































Architecture

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.

Advanced Remote architecture

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.