TN8000.18
Technical Note
XE8000 driving XE1200 transceivers
Standard API definitions
Table of Contents
1Introduction (3)
1.1Goal of the document (3)
1.2SEMTECH API code (3)
1.3Hardware Interfaces (3)
1.4Document conventions (4)
2Data types (4)红楼梦章节读后感
2.1Data type definitions (4)
3Global variables (4)
3.1Variables common to all XE120xDrivers (4)
3.2BitJockey TM specific variables (5)
3.3BitBang specific variables (except SX1230, SX1211/10, SX1212/13, and SX1231 cf. below) (5)
3.4SX1230 specificities (5)
3.5SX1211/10, SX1212/13 and SX1231 specificities (5)
3.6Copy of transceiver read/write registers (5)
4Header files – contents (6)
4.1Global definitions (6)
4.2I/O ports definitions (6)
4.3Transceiver 3 wire rial interface macros definitions (6)
4.4Transceiver operating modes and bit definitions (6)
4.5Timing values definitions (6)
4.6BitJockey TM operating modes and bit definitions (6)
5API usage tutorial (7)
5.1Getting familiar with XE8000 software environment (8)
略逊一筹
5.2Setting up the project (8)
5.3Initializing the microcontroller (8)
5.4Initializing transceiver parameters (9)
5.5Declaring the application global variables (9)
5.6Implementing the main function (10)
5.7Implementing the master function (11)
5.8Implementing the slave function (12)
5.9Testing the application (12)
6API functions (13)
6.1Configuration functions (13)
6.2Communication functions (15)
6.3Transceiver specific functions (19)
6.4Utility functions (21)
7Appendix (24)
7.1API functions availability (24)
7.2Hardware connections implemented for described drivers (25)
7.3Glossary (35)
1 INTRODUCTION
1.1 Goal of the document
The purpo of the Application Program Interface (API) is to provide basic software drivers for Semtech transceivers to XE8000 developers. This API allows a quick evaluation of the XE1200 transceivers and aims to ea the start of a development, using standard calls to low level functions.
All functions are open source but not fully optimized, however developers can replace them, if necessary, with optimized object code from third party vendors through wrapper functions.
The API allows developers to evaluate performance and electrical characteristics of the transceiver and to subquently modify or optimize the code to meet their design requirements.
A complete list of the API functions applicable to the Semtech XE1200 ries transceivers family can be found in Appendix 7.1.
Note: plea refer to the Semtech website h.com to obtain the latest documentation available. Semtech welcomes feedback from developers to help ensure that customer’s requirements are met.
1.2 SEMTECH API code
1.2.1 API programming language
The API functions are written in C code. The functions can be optimized by rewriting in asmbler.
1.2.2 Integrated Development Environment (IDE) ud to implement and test the API
The code described in this API has been written under RIDE-Pro.
1.2.3 Files names
There are always two files per transceiver, a “C” file and an “H” XE120xDriver.c and XE120xDriver.h, the C file contains the API functions implementation and the H file contains the API functions prototypes, #define directives and macros.
1.3 Hardware Interfaces
The API has been implemented for the following hardware interfaces (depending on RF chip):
1.3.1 BitBang
The BitBang technique consists of the transmission of data in a rial format, accomplished by rapidly toggling, in software, a single output bit. It is ud with the “Continuous” data mode of the RF chip.
1.3.2 BitJockey TM
The BitJockey TM is a PCM Bit Stream Encoder/Decoder or RF Receiver/Transmitter Interface. In a normal microcontroller, the bits and low level coding of the RF protocol are handled by software. This is both time-consuming and code inefficient, since the processor has to handle each bit as it is received or as it is about to be transmitted. The BitJockey TM simplifies the handling of this low level data for wireless data systems, using techniques similar to that of a UART interface for wired transmission systems. It is also ud with the “Continuous” data mode of the RF chip.
乳酸菌饮料For more information concerning the implementation of the BitJockey TM, plea refer to the Semtech XE8806A and XE8807A datasheet.
1.3.3 Buffered and Packet
A FIFO on the RF chip is ud to store each data byte transmitted or received (only the payload byte
s in the ca of Packet mode). This data is written to/read from the FIFO via the SPI bus. It reduces processor overhead and reduces connections (the DATA input/output pin is not ud in this operation mode). It is ud with the “Buffered” and “Packet” data modes of the RF chip.
For more information concerning the implementation of the Buffered and Packet modes, plea refer to the deviced datasheets.
1.4 Document conventions
• A file name is reprented with italic characters. i.e. XE1202Driver.h
•Part of code or code example is written in courier font. i.e. #define SLEEP 0
•Defined values are always reprented in upper ca i.e. #define SLEEP 0
•Global variables name start with capital characters.
< static _U8 RFState = RF_STOP; // RF state machine
•Local variables name start with lower ca characters.
< _U8 m ode;
•Pointers variable name start with a lower ca “p” character
< static _U8 *pRFFrame; // Pointer to the RF frame
2 DATA TYPES
2.1 Data type definitions
All the data types described in this chapter are defined in types.h. This file is automatically included by the standard header file of the microcontroller being ud (ex: XE88LC06A.h).
The table below describes the basic types ud within the API.
Standard type name Defined type name Comment
bool (unsigned char) _U8 fal/true - FALSE/TRUE – 0/1
unsigned char _U8 8 bit quantity
char _S8 8 bit signed quantity
unsigned short _U16 16 bit quantity
short _S16 16 bit signed quantity
unsigned long _U32 32 bit quantity
long _S32 32 bit signed quantity
float _F24 24 bit float quantity
多言何益double _F32 32 bit float quantity
Table 1 Types definition
3 GLOBAL VARIABLES
API global variables are declared in XE120xDriver.c, the variables are necessary to store RF frame states, XE120x chip operating mode, etc… They may vary depending on the transceiver.
The variables declared as volatile can be ud outside
Some variables are initialized at declaration. Unless specified, the variables initialization values shouldn’t be modified.
3.1 Variables common to all XE120xDrivers
static _U8 RFState = RF_STOP; // RF state machine
小学美术画
static _U8 *pRFFrame; // Pointer to the RF frame
static _U8 RFFramePos; // RF frame current position
static _U8 RFFrameSize; // RF frame size
static _U16 ByteCounter = 0; // RF frame byte counter
static _U8 PreMode = RF_SLEEP // Previous chip operating mode
volatile _U8 EnableSyncByte = true; // Enables/disables the synchronization byte reception/transmission static _U8 SyncByte; // RF synchronization byte counter
static _U8 PatternSize = 4; // Size of pattern detection
static _U8 StartByte[4]; // Pattern detection values
static _U16 RFFrameTimeOut = RF_FRAME_TIMEOUT(1200); // Reception counter value (full frame timeout generation)
3.2 BitJockey TM specific variables
•static _U8 RfifBaudrate = RFIF_BAUDRATE_1200; // BitJockeyTM baudrate tting
•static _U8 RfifMode = RFIF_DISABLE; // BitJockeyTM mode
3.2.1 XE1201A and XE1209
•static _U8 StartDetect = fal; // Indicates when a start detection has been made
•static _U8 StartByteStatus = 0; // Indicates which start byte has been detected
•static _U8 StartByteCnt = 0; // Start byte counter
3.3 BitBang specific variables (except SX1230, SX1211/10, SX1212/13, and SX1231 cf. below)
•static _U16 RFBaudrate = TX_BAUDRATE_GEN_1200; // Transmission counter value (baudrate generation) 3.4 SX1230 specificities
Contrary to the other XE1200, the SX1230 is a transmitter only and following points must be listed for proper u:
•Variable RFFrameTimeOut does not exist as well as all other reception related variables or functions.
The SX1230 provides a DCLK for the uC to nd data synchronously, hence the RFBaudrate is not needed.
•Transmitted pattern should be defined accordingly by variables SyncSize and SyncValue
3.5 SX1211/10, SX1212/13 and SX1231 specificities
In the devices, the equivalent notion of “Pattern”/”Start” is replaced by “Sync” or “Sync Word” while the previously called “Sync” notion (Synchronization bytes) does not exist anymore.
In continuous mode, the devices provide a DCLK for the uC to nd data synchronously, hence the RFBaudrate is not needed in BitBang implementation.
In packet mode we do not refer to the “Frame” (ie whole packet including preamble and sync) but to the “Payload” since the two fields are automatically generated by the RF chip.
3.6 Copy of transceiver read/write registers
The RegistersCfg variable is an array which contains a copy of the internal registers of the XE1200 transceiver and is ud at initialisation. This variable should be modified to t the transceiver parameters to tho required for a particular application. Each array element corresponds to a transceiver register. Note that read only registers, are not reported and that some modifications (RF parameters aside) may affect the behavior of the Send and Receive functions. (Ex : disabling bit synchronizer, disabling pattern recognition, modifying IRQ mapping, )
Example:
怎样骑自行车•_U16 RegistersCfg[] = { // XE1201A configuration registers values DEF_REG_A | RF_A_CTRL_MODE_PIN | RF_A_CLOCK_ENABLE_ON | RF_A_CHIP_ENABLE_OFF
| RF_A_TRANSMITTER_MODE | RF_A_BIT_SYNC_ON | RF_A_BAUDRATE_4800,
DEF_REG_B,promi
DEF_REG_C | RF_C_POWER_P_5 | RF_C_INVERT_OFF | RF_C_TRANS_AMP_ON
| RF_C_TRANS_DATA_BIT_0 | RF_C_FDEV_125
};
Note that the fields ending with “_VALUE” can be directly replaced by the decimal value desired.
4 HEADER FILES – CONTENTS
The API header files are divided in to 5 ctions in the BitBang hardware interface and 6 ctions in the BitJockey TM hardware interface.
4.1 Global definitions
This ction defines the RF state machine states; functions return codes and RF frame definitions.
4.2 I/O ports definitions
The I/O ports ud to interface between the transceiver and the microcontroller are defined to simplify code readability and portability.
The BitBang and BitJockey TM hardware interfaces introduce a difference between the corresponding headers files becau the two interfaces don’t u the same pins to communicate with the transceiver.
4.3 Transceiver 3 wire rial interface macros definitions
Macros are defined to simplify the API code implementation.
4.4 Transceiver operating modes and bit definitions
This ction defines the transceiver register address and register contents. In addition, the different transceiver operating modes are defined.
4.5 Timing values definitions
This ction defines pre-calculated values in order to generate the different timings such as transceiver specific timings, baud rates and timeouts.
4.6 BitJockey TM operating modes and bit definitions
This ction defines each BitJockey TM register single bit, it also defines the different BitJockey TM operating modes. Notes:
1. All the timing values in the XE120xDriver.h are calculated using a RC oscillator running at
2.4576 MHz.
2.The speed of the microcontrollers is not highly dependent upon supply voltage. However, by limiting the
潜移默化的近义词
temperature range, the speed can be incread. For more information plea refer to the microcontroller datasheet.
