TN8000.18 Technical Note

Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
TN8000.18
Technical Note
XE8000 driving XE1200 transceivers
Standard API definitions
V4.0 – October 2009
Page 1 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
Table of Contents
1
1.1
1.2
1.3
1.4
2
2.1
3
3.1
3.2
3.3
3.4
3.5
3.6
4
4.1
4.2
4.3
4.4
4.5
4.6
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
6
6.1
6.2
6.3
6.4
7
7.1
7.2
7.3
Introduction ...................................................................................................................................................... 3
Goal of the document......................................................................................................................................... 3
SEMTECH API code .......................................................................................................................................... 3
Hardware Interfaces........................................................................................................................................... 3
Document conventions ...................................................................................................................................... 4
Data types ......................................................................................................................................................... 4
Data type definitions........................................................................................................................................... 4
Global variables ............................................................................................................................................... 4
Variables common to all XE120xDrivers............................................................................................................ 4
TM
BitJockey specific variables ............................................................................................................................ 5
BitBang specific variables (except SX1230, SX1211/10, SX1212/13, and SX1231 cf. below).......................... 5
SX1230 specificities ........................................................................................................................................... 5
SX1211/10, SX1212/13 and SX1231 specificities ............................................................................................. 5
Copy of transceiver read/write registers............................................................................................................. 5
Header files – contents.................................................................................................................................... 6
Global definitions................................................................................................................................................ 6
I/O ports definitions ............................................................................................................................................ 6
Transceiver 3 wire serial interface macros definitions ....................................................................................... 6
Transceiver operating modes and bit definitions ............................................................................................... 6
Timing values definitions.................................................................................................................................... 6
TM
BitJockey operating modes and bit definitions................................................................................................ 6
API usage tutorial............................................................................................................................................. 7
Getting familiar with XE8000 software environment .......................................................................................... 8
Setting up the project ......................................................................................................................................... 8
Initializing the microcontroller............................................................................................................................. 8
Initializing transceiver parameters..................................................................................................................... 9
Declaring the application global variables .......................................................................................................... 9
Implementing the main function ....................................................................................................................... 10
Implementing the master function.................................................................................................................... 11
Implementing the slave function ...................................................................................................................... 12
Testing the application ..................................................................................................................................... 12
API functions .................................................................................................................................................. 13
Configuration functions .................................................................................................................................... 13
Communication functions................................................................................................................................. 15
Transceiver specific functions.......................................................................................................................... 19
Utility functions ................................................................................................................................................. 21
Appendix......................................................................................................................................................... 24
API functions availability................................................................................................................................... 24
Hardware connections implemented for described drivers.............................................................................. 25
Glossary ........................................................................................................................................................... 35
V4.0 – October 2009
Page 2 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
1
INTRODUCTION
1.1
Goal of the document
The purpose 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 ease
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
subsequently modify or optimize the code to meet their design requirements.
A complete list of the API functions applicable to the Semtech XE1200 series transceivers family can be found in
Appendix 7.1.
Note: please refer to the Semtech website at http://www.semtech.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. These functions can be optimized by rewriting in assembler.
1.2.2 Integrated Development Environment (IDE) used 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” file i.e. 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 serial format, accomplished by rapidly toggling, in
software, a single output bit. It is used with the “Continuous” data mode of the RF chip.
TM
1.3.2 BitJockey
TM
The BitJockey 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 timeconsuming and code inefficient, since the processor has to handle each bit as it is received or as it is about to be
TM
transmitted. The BitJockey
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 used with the “Continuous”
data mode of the RF chip.
TM
For more information concerning the implementation of the BitJockey , please refer to the Semtech XE8806A and
XE8807A datasheet.
1.3.3 Buffered and Packet
A FIFO on the RF chip is used to store each data byte transmitted or received (only the payload bytes in the case 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 used in this operation mode). It is used with the “Buffered”
and “Packet” data modes of the RF chip.
For more information concerning the implementation of the Buffered and Packet modes, please refer to the deviced
datasheets.
V4.0 – October 2009
Page 3 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
1.4
Document conventions
•
•
•
•
•
•
2
A file name is represented 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 represented in upper case i.e. #define SLEEP 0
Global variables name start with capital characters.
i.e. static _U8 RFState = RF_STOP; // RF state machine
Local variables name start with lower case characters.
i.e. _U8 mode;
Pointers variable name start with a lower case “p” character
i.e. static _U8 *pRFFrame; // Pointer to the RF frame
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 used (ex: XE88LC06A.h).
The table below describes the basic types used within the API.
Standard type name
bool (unsigned char)
unsigned char
char
unsigned short
short
unsigned long
long
float
double
Defined type name
_U8
_U8
_S8
_U16
_S16
_U32
_S32
_F24
_F32
Comment
false/true - FALSE/TRUE – 0/1
8 bit quantity
8 bit signed quantity
16 bit quantity
16 bit signed quantity
32 bit quantity
32 bit signed quantity
24 bit float quantity
32 bit float quantity
Table 1 Types definition
3
GLOBAL VARIABLES
API global variables are declared in XE120xDriver.c, these 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 used outside the XE120xDriver.c.
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;
static
_U8 *pRFFrame;
static
_U8 RFFramePos;
static
_U8 RFFrameSize;
static _U16 ByteCounter = 0;
static
_U8 PreMode = RF_SLEEP
volatile _U8 EnableSyncByte = true;
static
static
static
static
V4.0 – October 2009
_U8 SyncByte;
_U8 PatternSize = 4;
_U8 StartByte[4];
_U16 RFFrameTimeOut =
//
//
//
//
//
//
RF state machine
Pointer to the RF frame
RF frame current position
RF frame size
RF frame byte counter
Previous chip operating mode
// Enables/disables the synchronization
byte reception/transmission
// RF synchronization byte counter
// Size of pattern detection
// Pattern detection values
RF_FRAME_TIMEOUT(1200); // Reception counter
value
(full
frame
timeout generation)
Page 4 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
TM
3.2
BitJockey
•
static
•
static
3.2.1
specific variables
_U8 RfifBaudrate = RFIF_BAUDRATE_1200; // BitJockeyTM baudrate
setting
_U8 RfifMode = RFIF_DISABLE;
// BitJockeyTM mode
XE1201A and XE1209
•
static
_U8 StartDetect = false;
•
static
_U8 StartByteStatus = 0;
•
static
_U8 StartByteCnt = 0;
3.3
// Indicates when a start detection
has been made
// Indicates which start byte has been
detected
// Start byte counter
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 use:
•
Variable RFFrameTimeOut does not exist as well as all other reception related variables or functions.
The SX1230 provides a DCLK for the uC to send 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 these 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, these devices provide a DCLK for the uC to send 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 these 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 used at initialisation. This variable should be modified to set the transceiver parameters to those 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, etc...)
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,
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.
V4.0 – October 2009
Page 5 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
4
HEADER FILES – CONTENTS
TM
The API header files are divided in to 5 sections in the BitBang hardware interface and 6 sections in the BitJockey
hardware interface.
4.1
Global definitions
This section defines the RF state machine states; functions return codes and RF frame definitions.
4.2
I/O ports definitions
The I/O ports used to interface between the transceiver and the microcontroller are defined to simplify code
readability and portability.
TM
The BitBang and BitJockey hardware interfaces introduce a difference between the corresponding headers files
because the two interfaces don’t use the same pins to communicate with the transceiver.
4.3
Transceiver 3 wire serial interface macros definitions
Macros are defined to simplify the API code implementation.
4.4
Transceiver operating modes and bit definitions
This section defines the transceiver register addresses and register contents. In addition, the different transceiver
operating modes are defined.
4.5
Timing values definitions
This section defines pre-calculated values in order to generate the different timings such as transceiver specific
timings, baud rates and timeouts.
TM
4.6
BitJockey operating modes and bit definitions
TM
TM
This section defines each BitJockey register single bit, it also defines the different BitJockey 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 increased. For more information please refer to the microcontroller datasheet.
V4.0 – October 2009
Page 6 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
5
API USAGE TUTORIAL
This section details a simple application using the transceiver API functions based upon a simple “Ping-Pong” halfduplex communication protocol. MASTER/SLAVE architecture has been chosen to implement this application.
The application consists of a MASTER controller that transmits a RF frame containing a “PING” string and a SLAVE
unit that receives the “PING” string and responds answers by transmitting a RF frame containing a “PONG” string.
To indicate that there is activity, the SLAVE unit will toggle a bit on its associated microcontroller Port B pin when the
“PING” RF frame is received. In addition, the MASTER controller will also toggle a bit on the associated
microcontroller Port B pin when the “PONG” RF frame is received
If the MASTER doesn’t receive a response from the SLAVE unit after a pre-defined time period, then the MASTER
unit will re-transmit the “PING” RF frame.
In this tutorial we assume the following hardware configuration:
Transceiver: XE1203F
TM
Microcontroller: XE8806A -> The BitJockey hardware interface is enabled
The microcontroller activity pin is the Port B pin 0 on both systems.
PING
PONG
XM1203F
XM1203F
API Interface
API Interface
XE8000EV108
XE8000EV108
XE8000 MP
XE8000 MP
MASTER
SLAVE
Figure 1 Ping-Pong application principle
V4.0 – October 2009
Page 7 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
Details of the implementation for the basic API hardware interface between the XE1200-series transceivers and
XE8000-series microcontrollers can be found in appendix 7.2.
The basic hardware configuration consists of a Semtech ProStart II and an XM1203F transceiver module.
The ProStart II is composed with 1 XE8000MP (multi-purpose board) and 1 XE8000EV1XX (please refer to
http://www.semtech.com for more information on microcontrollers evaluation tools)
Information about the different XM1200-series module family can be found on the Semtech website at
http://www.semtech.com .
This combination of the ProStart II and the XM1200 module enables developers to quickly and easily configure their
system.
5.1
Getting familiar with XE8000 software environment
As starting point for this tutorial please refer to the technical note TN8000.16 “coding with RIDE quick start” which
can be found under. http://www.semtech.com
5.2
Setting up the project
•
•
•
•
Download the source code corresponding to the API technical note from http://www.semtech.com.
Uncompress the zip file to ex: “c:\”.
Copy the XE1203Driver.c and XE1203Driver.h files that you will find in “c:\Api120x\1203\BitJockey\”
directory to the RIDE project “src” directory.
Add the XE1203Driver.c file to the RIDE project.
Notes
1. If the BitBang hardware interface is to be implemented, use the XE120xDriver in the BitBang directory. If the
TM
TM
BitJockey interface is to be implemented, use the XE120xDriver in the BitJockey directory.
TM
2. The BitJockey Driver can only be used with the XE8806A or XE8807A microcontroller. The BitBang Driver can
be used with all the Semtech microcontrollers.
In Globals.h, insert the following line in the section “Application specific Include files”:
#include "XE1203Driver.h"
The “Application specific Include files” section should then look like:
/*******************************************************************
** Application specific Include files
**
*******************************************************************/
#include "Initialisation.h"
#include "DFLLDriver.h"
#include "XE1203Driver.h"
5.3
Initializing the microcontroller
The API driver timings are based on CPU frequency of 2.4576MHz. This implies that the microcontroller RC
oscillator frequency should be initialized with this value.
In Initialisation.c modify the InitMicro function by uncommenting the following line:
• //InitRCOscillator(1228800); // Initialises the RC oscillator
and change the parameter value to 2457600 the line should look like:
InitRCOscillator(2457600); // Initialises the RC oscillator
Comment out the following line:
InitUART(19200, 1, 0, 0, 2); // Initialises the UART communications
Afterwards the line should look like:
• //InitUART(19200, 1, 0, 0, 2); // Initialises the UART communications
V4.0 – October 2009
Page 8 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
5.4
Initializing transceiver parameters
In XE1203Driver.c change RegistersCfg values according to the application requirements and to the XE1203F
Data Sheet. The RegistersCfg variable is used by InitRFChip function to initialize the transceiver. When
syntax is not obvious, please refer to the header file.
Example:
To change the XE1203F baud rate from 4800 to 38400 baud, whilst other register values remain at their default
settings, the RegistersCfg variable should be modified as follows:
Original variable:
_U16 RegistersCfg[] = { // 1203 configuration registers values
DEF_CONFIG | RF_CONFIG_MODE1,
DEF_RTPARAM1 | RF_RT1_BIT_SYNC_ON | RF_RT1_BARKER_OFF | RF_RT1_RSSI_OFF
| RF_RT1_RSSIR_LOW | RF_RT1_FEI_ON | RF_RT1_BW_600
| RF_RT1_OSC_INT | RF_RT1_CLKOUT_OFF,
.
.
.
DEF_FSPARAM2 | RF_FS2_CHANGE_OSR_OFF | RF_FS2_BAUDRATE_4800,
.
.
.
};
Modified variable:
_U16 RegistersCfg[] = { // 1203 configuration registers values
DEF_CONFIG | RF_CONFIG_MODE1,
DEF_RTPARAM1 | RF_RT1_BIT_SYNC_ON | RF_RT1_BARKER_OFF | RF_RT1_RSSI_OFF
| RF_RT1_RSSIR_LOW | RF_RT1_FEI_ON | RF_RT1_BW_600
| RF_RT1_OSC_INT | RF_RT1_CLKOUT_OFF,
.
.
.
DEF_FSPARAM2 | RF_FS2_CHANGE_OSR_OFF | RF_FS2_BAUDRATE_38400,
.
.
};
5.5
Declaring the application global variables
The application can now be implemented. Firstly, the application global variables need to be declared:
In main.c file start by declaring a variable that will contain the RF buffer. Then declare a variable that will contain the
buffer size to be sent or the received buffer size, a variable that will indicate whether the application is a MASTER or
SLAVE and a variable that indicates if a new packet needs to be sent by the MASTER controller.
In the main.c file “Global variables declaration” section add the following lines:
/*******************************************************************
** Global variables declaration
**
*******************************************************************/
_U8 RFbuffer[RF_BUFFER_SIZE];
// RF buffer
volatile _U8 RFbufferSize;
// RF buffer size
volatile _U8 EnableMaster = true;
// Master/Slave selection
volatile _U8 SendNextPacket = true; // Indicates when to send the next frame
The RF_BUFFER_SIZE is defined in the XE1203Driver.h. By default this value is set to 64 bytes. However, this
buffer value can be changed according to the application and microcontroller RAM memory availability.
V4.0 – October 2009
Page 9 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
5.6
Implementing the main function
In the project main function (located in main.c) we need to call the API function InitRFChip
Once the transceiver is initialized the function enters an infinite loop where the application is tested to determine
whether it is a MASTER or SLAVE, and then call the corresponding function that will implement the MASTER or
SLAVE function.
The main function should be similar to that described below:
int main (void){
InitMicro();
_Monitor_Init();
_Monitor_SoftBreak;
InitRFChip();
// Main Loop
while(1){
if(EnableMaster){
OnMaster();
}
else{
OnSlave();
}
}
return 0;
}
V4.0 – October 2009
Page 10 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
5.7
Implementing the master function
This procedure implements the MASTER controller function. The main goal of this function is to transmit a “PING”
and to test whether there is a “PONG” response. If a “PONG” response is received, then the procedure is restarted.
In the case that there is no correct response after a pre-defined time-out period, the Master re-transmits a “PING”.
The Master function should be similar to that described below:
void OnMaster(void){
_U8 ReturnCode = -1;
// Test if a PING needs to be sent
if(SendNextPacket){
// Copy the PING string to the buffer used to send the frame
strcpy(RFbuffer, "PING");
// Sends the frame to the RF chip
SendRfFrame(RFbuffer, strlen(RFbuffer), &ReturnCode);
// Indicates that we want to wait for an answer
SendNextPacket = false;
}
else{
// Receives the frame from the RF chip
ReceiveRfFrame(RFbuffer, (_U8*)&RFbufferSize, &ReturnCode);
// Tests if there is a TimeOut or if we have received a frame
if(ReturnCode == OK){
// Sets the last byte of received buffer to 0. Needed by strcmp
function
RFbuffer[RFbufferSize] = '\0';
// Tests if the received buffer size is greater than 0
if(RFbufferSize > 0){
// Tests if the received buffer value is PONG
if(strcmp(RFbuffer, "PONG") == 0){
// Indicates on a LED that the received frame is a PONG
toggle_bit(RegPBOut, 0x01);
}
}
// Indicates that we can send the next PING frame
SendNextPacket = true;
}
else if(ReturnCode == RX_TIMEOUT){
// Indicates that we can send the next PING frame
SendNextPacket = true;
}
}
}
V4.0 – October 2009
Page 11 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
5.8
Implementing the slave function
This procedure implements the SLAVE unit function. The main goal of this function is to wait until a “PING” is
received and then to transmit a “PONG” as a response.
An example of the Slave function is documented below:
void OnSlave(void){
_U8 ReturnCode = -1;
// Receives the frame from the RF chip
ReceiveRfFrame(RFbuffer, (_U8*)&RFbufferSize, &ReturnCode);
// Tests if we have received a frame
if (ReturnCode == OK){
// Tests if the received buffer size is greater than 0
if (RFbufferSize > 0){
// Sets the last byte of received buffer to 0. Needed by strcmp
function
RFbuffer[RFbufferSize] = '\0';
// Tests if the received buffer value is PING
if(strcmp(RFbuffer, "PING") == 0){
// Indicates on a LED that the received frame is a PING
toggle_bit(RegPBOut, 0x01);
// Copy the PONG string to the buffer used to send the frame
strcpy(RFbuffer, "PONG");
// Sends the frame to the RF chip
SendRfFrame(RFbuffer, strlen(RFbuffer), &ReturnCode);
}
}
}
}
5.9
Testing the application
The application is now finished.
The project can now be compiled and no errors should be generated.
To test the application:
1. Download the code to the MASTER controller system (refer to the “Getting started XE” document in the
RIDE documentation).
2. Change the EnableMaster variable from true to false in the main.c file.
3. Compile the project.
4. Download the code to the SLAVE unit system.
If the application has been successfully implemented and the two systems are within RF communication range, the
LED corresponding to the microcontroller Port B pin 0 should toggle on the two systems, verifying RF
communications and subsequent “Ping-Pong” activity.
If the MASTER or SLAVE system is powered-down, then the LED on the powered-up system stops toggling.
V4.0 – October 2009
Page 12 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6
API FUNCTIONS
The API functions are grouped in to four categories.
1. Configuration functions: Functions required for transceiver configuration.
2. Communication functions: Functions which permit the transmission and reception of RF data.
3. Transceiver specific functions: Functions specific to the different transceivers in the XE1200-series family
and to their specific features.
4. Utility functions: Functions which perform miscellaneous operations, such as counters, events initialization,
byte inversion, and delay generation, etc…
6.1
Configuration functions
6.1.1 InitRFChip
Description
This function sends the values contained in RegistersCfg variable to the transceiver. It also initializes the
StartByte and baud rates variables.
Note: The read-only registers are not included in the RegistersCfg variable.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers I/O
Used
BitBang
void InitRFChip (void)
WriteRegister; InvertByte
Dedicated configuration pins
TM
BitJockey
Buffered&Packet
* Transceiver dependant defined in XE120xDriver.h
6.1.2 SetRFMode
Description
This function defines the transceiver operating mode.
Please refer to the corresponding XE120xDriver.h file for details of the possible operating modes.
Function table
TM
Function
Inputs
Outputs
Functions called
Used Resources
Registers I/O
Used
BitBang
BitJockey
Void SetRFMode(_U8 mode)
mode Defined in XE120xDriver.h
set_bit, clear_bit, Wait
SetModeRFIF, set_bit,
clear_bit, Wait
Counters A&B
Dedicated configuration pins
Buffered&Packet
set_bit, clear_bit, Wait
* Transceiver dependant defined in XE120xDriver.h
V4.0 – October 2009
Page 13 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.1.3 SetModeRFIF
Description
TM
This function initializes all the BitJockey registers in order to set a predefined mode (see the XE8806A and
XE8807A datasheet for the available modes).
Function table
BitBang
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
TM
BitJockey
void SetModeRFIF (_U8 mode)
mode Defined in XE120xDriver.h
RegRfifCmd1, RegRfifCmd2,
RegRfifCmd3, RegIrqEnHig
Buffered&Packet
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
6.1.4 WriteRegister
Description
This function writes to the XE120x registers via dedicated programming pins, following the protocol given in the
transceiver datasheet.
Note: The clocking of the operation is based on the CPU frequency of the user program.
Function table
TM
Function
Inputs
Outputs
Functions called
Used Resources
Registers I/O
Used
BitBang
BitJockey
Buffered&Packet
void WriteRegister(_U8 address, _U16 value)
address
Address of the register defined in the transceiver datasheet
value
Value of the register
Serial macros, set_bit, clear_bit
SPI macros, SpiInOut
Dedicated configuration pins*
* Transceiver dependant defined in XE120xDriver.h
6.1.5 ReadRegister
Description
This function reads from registers via dedicated programming pins, following the protocol given in the transceiver
datasheet.
Note: The clocking of the operation is based on the CPU frequency of the user program.
Function table
TM
Function
Inputs
Outputs
Functions called
Used Resources
Registers I/O
Used
BitBang
BitJockey
Buffered&Packet
_U16 value = ReadRegister (_U8 address)
address
Address of the register defined in the transceiver datasheet
value
Value of the register
Serial macros, set_bit, clear_bit
SPI macros, SpiInOut
Dedicated configuration pins*
* Transceiver dependant defined in XE120xDriver.h
V4.0 – October 2009
Page 14 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.2
Communication functions
6.2.1 SendRfFrame
Description
This function encapsulates given User Buffer in an RF frame and sends it to the transceiver.
The RF frame format is described below:
PRE
PRE
PRE
PRE
START
START
START
START
SIZE
9 Bytes (Max) / 6 Bytes (Min)
USER BUFFER
Max 128 Bytes
Max 137 Bytes
Depending upon the specific user application the number of START bytes can be varied between 1 up to 4.
Example 1: XE1201A (No hardware pattern detection)
In XE1201ADriver.c Global variable section modify the PatternSize variable.
Original variable:
static
_U8 PatternSize = 4;
// Size of pattern detection
Modified variable:
static
_U8 PatternSize = 2;
// Size of pattern detection
Example 2: XE1202 (Hardware pattern detection)
In the RegistersCfg variable modify the register where the Pattern size is defined as indicated in the transceiver
datasheet.
Original variable:
_U16 RegistersCfg[] = { // 1203 configuration registers values
DEF_CONFIG | RF_CONFIG_MODE1,
.
.
.
DEF_ADPARAM1 | RF_AD1_PATTERN_ON | RF_AD1_P_SIZE_32 | RF_AD1_P_TOL_0
| RF_AD1_CLK_FREQ_1_22_MHZ | RF_AD1_IQA_OFF,
.
.
.
};
Modified variable:
_U16 RegistersCfg[] = { // 1203 configuration registers values
DEF_CONFIG | RF_CONFIG_MODE1,
.
.
.
DEF_ADPARAM1 | RF_AD1_PATTERN_ON | RF_AD1_P_SIZE_16 | RF_AD1_P_TOL_0
| RF_AD1_CLK_FREQ_1_22_MHZ | RF_AD1_IQA_OFF,
.
.
.
};
V4.0 – October 2009
Page 15 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
Example 3: XE1203F (Hardware pattern detection)
In the RegistersCfg variable modify the register where the Pattern size is defined as indicated in the transceiver
datasheet.
Original variable:
_U16 RegistersCfg[] = { // 1203 configuration registers values
DEF_CONFIG | RF_CONFIG_MODE1,
.
.
.
DEF_ADPARAM1 | RF_AD1_P_SIZE_32 | RF_AD1_P_TOL_0 | RF_AD1_CLK_FREQ_1_22_MHZ
| RF_AD1_INVERT_OFF | RF_AD1_REG_BW_OFF,
.
.
.
};
Modified variable:
_U16 RegistersCfg[] = { // 1203 configuration registers values
DEF_CONFIG | RF_CONFIG_MODE1,
.
.
.
DEF_ADPARAM1 | RF_AD1_P_SIZE_16 | RF_AD1_P_TOL_0 | RF_AD1_CLK_FREQ_1_22_MHZ
| RF_AD1_INVERT_OFF | RF_AD1_REG_BW_OFF,
.
.
.
};
Return values:
1. Status: OK
2. Status: ERROR
3. Status: TX_TIMEOUT
4. Status: TX_RUNNING
Frame has been sent
The RF frame buffer size is not correct
Indicates that the function exits after waiting with no success to send a full RF frame
TM
Indicates that the transmission is not yet finished (BitJockey only)
Function table
TM
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
BitJockey
Buffered&Packet
void SendRfFrame (_U8 *buffer, _U8 size, _U8 *pReturnCode)
*buffer
Address of buffer to send
size
Size of the buffer to send
*pReturnCode Function status
TxEventsOn, TxEventsOff,
SetRFMode
WriteRegister, SendByte,
SetRFMode, SendByte
SetRFMode
Counters A & B
RegEvn, RegEvnEn
RegRfifTx, RegRfifTxSta
Clock from transceiver ->
PD0 – PD3
Dedicated data pins *
PA1
Dedicated configuration pins Dedicated configuration pins
Dedicated data pins *
*
*
Dedicated configuration pins
*
RegCntA, RegCntB,
RegCntCtrlCk,
RegCntConfig1, RegCntOn
* Transceiver dependant defined in XE120xDriver.h
V4.0 – October 2009
Page 16 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.2.2 ReceiveRfFrame
Description
This function receives an RF frame from the transceiver and returns the User Buffer and the User Buffer size.
The RF frame format is the same as the SendRfFrame.
Return values:
1. Status: OK
2. Status: ERROR
3. Status: RX_TIMEOUT
frame
4. Status: RX_RUNNING
RF frame reception done
The received RF frame buffer size is not correct
Indicates that the function exits after waiting with no success to receive a full RF
TM
Indicates that the reception is not yet finished (BitJockey
TM
Note: When using the BitJockey
only)
handling of a RF frame is done using the interrupts of the peripheral.
Function table
TM
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
BitJockey
Buffered&Packet
void ReceiveRfFrame (_U8 *buffer, _U8 *size, _U8 *pReturnCode)
*buffer
Address of received buffer
*size
Received buffer size
*pReturnCode Function status
RxEventsOn, RxEventsOff,
SetRFMode, EnableTimeOut WriteRegister, SetRFMode,
SetRFMode, ReceiveByte,
EnableTimeOut
set_bit, clear_bit
Counters A & B
RegEvn, RegEvnEn
Clock from transceiver ->
PD0 – PD3
Dedicated data pins *
PA1
Dedicated configuration pins Dedicated configuration pins
Dedicated data pins *
*
*
Dedicated configuration pins
*
RegCntA, RegCntB,
RegCntCtrlCk,
RegCntConfig1, RegCntOn
* Transceiver dependant defined in XE120xDriver.h
V4.0 – October 2009
Page 17 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.2.3
SendByte
Description
This function sends a byte through the dedicated transceiver communication pins. The function sends the byte LSB
first.
In BitBang mode, except for SX1211/10, SX1212/13 and SX1230 which provide a compulsory Tx clock, the baud
rate is generated by the A and B counters and their associated event. See TxEventsOn & TxEventsOff functions for
a full description of these tasks.
All the timings are referenced to the RC clock-frequency of the microcontroller. The baud rate is automatically set
when the InitRFChip function is called.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
void SendByte (_U8 b)
b
Byte to be send
set_bit, clear_bit
Counters A & B
RegEvn, RegEvnEn
Dedicated data pins *
RegCntA, RegCntB,
RegCntCtrlCk,
RegCntConfig1, RegCntOn
TM
BitJockey
N.A
N.A
N.A
N.A
N.A
N.A
N.A
N.A
Buffered&Packet
void SendByte (_U8 b)
b
Byte to be send
SPI macros
Dedicated data pins *
-
* Transceiver dependant defined in XE120xDriver.h
6.2.4 ReceiveByte
Description
This function reads a byte on the dedicated transceiver communication pins. The function receives the byte LSB
first.
In BitBang mode, RF frame timeout is generated when the A and B counters generate their event. Clock
synchronization is achieved using the event occurring on the falling edge of PA1 pin. See RxEventsOn &
RxEventsOff functions.
All the timings are referenced to the RC clock-frequency of the microcontroller. The baud rate is automatically set
when the InitRFChip function is called.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
_U8 byte = ReceiveByte ( )
byte
Data received
set_bit, clear_bit
Counters A & B
RegEvn, RegEvnEn
Clock from transceiver ->
PA1
Dedicated data pins *
RegCntA, RegCntB,
RegCntCtrlCk,
RegCntConfig1, RegCntOn
TM
BitJockey
N.A
N.A
N.A
N.A
N.A
N.A
N.A
Buffered&Packet
_U8 byte = ReceiveByte ( )
byte
Data received
SPI macros
Dedicated data pins *
N.A
-
* Transceiver dependant defined in XE120xDriver.h
V4.0 – October 2009
Page 18 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.3
Transceiver specific functions
6.3.1 AutoFreqControl
Description
This function enables an automatic frequency correction to align the transceiver LO frequency with the received
transmitted carrier.
Depending on the transceiver, this can be achieved by either hardware or software.
Function table (software implementation)
TM
BitBang
BitJockey
Buffered&Packet
Function
void AutoFreqControl ( _U8 *pReturnCode)
Inputs
Outputs
*pReturnCode Function status (see section 4 for definitions)
Functions called
WriteRegister, ReadRegister, ReadLO, WriteLO, InitFei, ReadFei, set_bit, clear_bit
Used Resources
Counters A & B
Registers Sys
RegEvnEn, RegEvn
Used
I/O
Dedicated configuration pins*
Cnt
RegCntOn, RegCntA, RegCntB
* Transceiver dependant defined in XE120xDriver.h
6.3.2 ReadLO
Description
Reads the LO frequency value from the transceiver.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers I/O
Used
BitBang
_U16 data = ReadLO ( )
data
LO register value
ReadRegister
Dedicated configuration pins*
TM
Buffered&Packet
TM
Buffered&Packet
BitJockey
* Transceiver dependant defined in XE120xDriver.h
6.3.3 WriteLO
Description
Writes the LO frequency value to the transceiver.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers I/O
Used
BitBang
BitJockey
void WriteLO ( _U8 value)
value Value to write in the LO register
WriteRegister
Dedicated configuration pins *
* Transceiver dependant defined in XE120xDriver.h
V4.0 – October 2009
Page 19 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.3.4 InitFei
Description
This function initializes the XE120X to enable the FEI reading.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
void InitFei (void)
ReadRegister, set_bit, clear_bit, Wait
Counters A & B
RegEvnEn, RegEvn
Dedicated configuration pins *
RegCntOn, RegCntA, RegCntB
TM
BitJockey
Buffered&Packet
* Transceiver dependant defined in XE120xDriver.h
6.3.5 ReadFei
Description
This function reads the FeiOut register(s) and returns the value as a 16-bit value.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
_S16 value = ReadFei (void)
value Value of the FEI
ReadRegister, set_bit, clear_bit, Wait
Counters A & B
RegEvnEn, RegEvn
Dedicated configuration pins*
RegCntOn, RegCntA, RegCntB
TM
Buffered&Packet
TM
Buffered&Packet
BitJockey
* Transceiver dependant defined in XE120xDriver.h
6.3.6 InitRssi
Description
This function initializes the XE120X to enable the RSSI reading.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
void InitRssi (void)
set_bit, clear_bit, Wait
Counters A & B
RegEvnEn, RegEvn
Dedicated configuration pins*
RegCntOn, RegCntA, RegCntB
BitJockey
* Transceiver dependant defined in XE120xDriver.h
V4.0 – October 2009
Page 20 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.3.7 ReadRssi
Description
This function reads the Rssi value from XE120x and formats it to a 16-bit value.
Function table
TM
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
BitJockey
_U16 value = ReadRssi (void)
value
Value of the RSSI register
ReadRegister , toggle_bit, Wait
Counters A & B
RegEvnEn, RegEvn
Dedicated configuration pins
RegCntOn, RegCntA, RegCntB
Buffered&Packet
* Transceiver dependant defined in XE120xDriver.h
6.4
Utility functions
6.4.1 Wait
Description
Loads the counter A & B and waits a pre-defined time period.
All the timings are referenced to the RC-clock frequency. The method used to set the correct frequency is defined in
the XE120xDriver.h file.
Function table
TM
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
BitJockey
void Wait (_U8 cntVal)
cntVal
Value of the counter
Counters A & B
RegEvn, RegEvnEn
RegCntA, RegCntB, RegCntCtrlCk, RegCntConfig1, RegCntOn
Buffered&Packet
6.4.2 EnableTimeOut
Description
This function enables or disables the RF frame time-out generation.
Function table
BitBang
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
V4.0 – October 2009
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
TM
BitJockey
Buffered&Packet
void EnableTimeOut(_U8 enable)
enable
1 -> enable / 0 -> disables
Counters A & B
RegIrqEnHig
RegCntA, RegCntB, RegCntCtrlCk, RegCntConfig1, RegCntOn
Page 21 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.4.3 TxEventsOn
Description
This function initializes the microcontroller counters and events that enable the data transmission.
Note: This function disables all interrupts.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
void TxEventsOn (void)
Counters A & B
RegEvn, RegEvnEn
RegCntA, RegCntB,
RegCntCtrlCk,
RegCntConfig1, RegCntOn
TM
BitJockey
Buffered&Packet
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
6.4.4 TxEventsOff
Description
Disables all the counters and events used during the data transmission.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
BitBang
void TxEventsOff (void)
Counters A & B
RegEvn, RegEvnEn
RegCntA, RegCntB,
RegCntCtrlCk,
RegCntConfig1, RegCntOn
TM
BitJockey
Buffered&Packet
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
6.4.5 RxEventsOn
Description
This function initializes the microcontroller counters and events that enable the data reception.
Note: This function disables all interrupts.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
V4.0 – October 2009
BitBang
void RxEventsOn (void)
Counters A & B
RegEvn, RegEvnEn
RegCntA, RegCntB,
RegCntCtrlCk,
RegCntConfig1, RegCntOn
TM
BitJockey
Buffered&Packet
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
Page 22 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
6.4.6 RxEventsOff
Description
Disables all the counters and events used during reception.
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers Sys
Used
I/O
Cnt
TM
BitBang
void RxEventsOff (void)
Counters A & B
RegEvn, RegEvnEn
RegCntA, RegCntB,
RegCntCtrlCk,
RegCntConfig1, RegCntOn
BitJockey
Buffered&Packet
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
N.A.
6.4.7 InvertByte
Description
This function performs a byte inversion. This is defined as follows:
The byte MSB bit will become the LSB bit and the byte LSB bit will become the MSB bit.
MSB
LSB
7
6
5
4
3
2
1
0
Input
0
1
2
3
4
5
6
7
Output
Function table
Function
Inputs
Outputs
Functions called
Used Resources
Registers I/O
Used
V4.0 – October 2009
BitBang
_U8 byte = InvertByte(_U8 b)
b
Byte to be inverted
byte
Inverted byte
-
TM
BitJockey
Page 23 of 35
Buffered&Packet
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7
APPENDIX
7.1
API functions availability
This section gives the availability of the functions for each transceiver.
Transceiver
specific
Utility
●//♦
●//♦
-//●//♦
●//♦
●//♦
●//♦
●/-/♦
●/-/♦
●//♦
●//♦
●//♦
●//♦
●//♦
●//♦
●//♦
●//♦
-//♦
●/-/●/-/●/-/●/-/●//♦
●/
●/
-/
●/
●/
●/
●/
●/●/-/-/-/-/-/-/-/●/
-/
●/●/●/●/-/-
●/●/-/●/●/●/-/●/-/-/-/-/-/-/-/-/●/-/●/●/-/-/●/-
SX1231
Comm
●/
●/
-/
●/
●/
●/
●/
●/●/●/
●/
●/
●/
●/
●/
●/
●/
-/
●/●/●/●/●/
SX1211/10
SX1212/13
Configurat
ion
InitRFChip
SetRFMode
SetModeRFIF
WriteRegister
ReadRegister
SendRfFrame
ReceiveRfFrame
SendByte
ReceiveByte
AutoFreqControl
ReadLO
WriteLO
InitFei
ReadFei
InitRssi
ReadRssi
Wait
EnableTimeOut
TxEventsOn
TxEventsOff
RxEventsOn
RxEventsOff
InvertByte
SX1230
Function name
XE1209
Transceiver
XE1205
XE8801A-02-05A-06A-07A functions
XE1203F/02A
7.1.1
●/♦
●/♦
-/●/♦
●/♦
●/♦
●/♦
●/♦
●/♦
-/-/-/-/-/-/●/♦
●/♦
-/♦
●/●/●/●/●/♦
●/♦
●/♦
-/●/♦
●/♦
●/♦
●/♦
●/♦
●/♦
●/♦
○/◊
○/◊
-/●/♦
-/●/♦
●/♦
-/♦
●/●/●/●/●/♦
Initializes the transceiver with registers default values.
Sets a predefined mode for the transceiver
TM
Sets the BitJockey to one of the predefined modes.
Writes a value in the transceiver internal register
Reads a value in the transceiver internal register
Sends a frame through RF link
Receives a frame through RF link
Sends a byte through the dedicated comm. pins
Receives a byte through the dedicated comm. pins
Does an automatic frequency correction
Reads the local oscillator frequency registers
Write the local oscillator frequency registers
Initialize the transceiver for FEI operations
Reads the FEI value
Initializes the transceiver for RSSI operations
Reads the RSSI value
Waits a given time
Enables/Disables RF frame time out
Initializes counter and events for transmission.
Disables all the resources used during transmission.
Initializes counter and events for reception.
Disables all the resources used during reception.
Inverts a byte. MSB -> LSB, LSB -> MSB
Table 2 Functions availability
Legend used in the availability table
Symbol
○
●
◊
♦
-
Meaning
Not available yet but possible to implement for the given transceiver with BitBang interface
Available with BitBang interface
TM
Not available yet but possible to implement for the given transceiver with BitJockey interface
TM
Available with BitJockey interface
Not available yet but possible to implement for the given transceiver with Buffered/Packet interface
Available with Buffered/Packet interface
Unavailable/not-required
V4.0 – October 2009
Page 24 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2
Hardware connections implemented for described drivers.
7.2.1
Connections between XM1201A and XE8801A/02/05A/06A/07A BitBang
XE8801A/
02/05A/06A/07A
7.2.2
XM1201A
PA1
PA2
CLKD
RXD
PC0
PC1
PC2
PC3
PC4
PC5
TXD
SD
SC
DE
EN
RXTX
TM
Connections between XM1201A and XE8806A/07A BitJockey
XE8806A/07A
TM
BITJOCKEY
V4.0 – October 2009
XM1201A
PB0
RXTX
PD0
PD1
PD2
PD3
PD4
PD5
PD6
PD7
RXD
CLKD
TXD
EN
DE
SC
SD
Page 25 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.3
Connections between XM1202 and XE8801A/02/05A/06A/07A BitBang
XE8801A/
02/05A/06A/07A
XM1202
PA1
PA2
PA3
PB1
PB2
PB3
PC0
PC1
PC2
PC3
PC4
PC5
PC6
7.2.4
DCLK
DATAOUT
PATTERN
MODE0
MODE1
MODE2
DATAIN
TX
RX
EN
SCK
SI
SO
TM
Connections between XM1202 and XE8806A/07A BitJockey
XE8806A/07A
TM
BITJOCKEY
V4.0 – October 2009
PB0
PB1
PB2
PB4
PB5
XM1202
MODE0
MODE1
MODE2
TX
RX
PD0
PD1
PD2
PD3
PD4
PD5
PD6
PD7
DATAOUT
DCLK
PATTERN
DATAIN
EN
SCK
SI
SO
Page 26 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.5
Connections between XM1203F and XE8801A/02/05A/06A/07A BitBang
XE8801A/
02/05A/06A/07A
7.2.6
XM1203F
PA1
PA2
PA3
DCLK
DATA
PATTERN
PC0
PC1
PC2
PC3
PC4
PC5
PC6
DATAIN
TX
RX
EN
SCK
SI
SO
TM
Connections between XM1203F and XE8806A/07A BitJockey
XE8806A/07A
TM
BITJOCKEY
V4.0 – October 2009
(XE1283 compatible)
XM1203F
PB4
PB5
TX
RX
PD0
PD1
PD2
PD3
PD4
PD5
PD6
PD7
DATA
DCLK
PATTERN
DATAIN
EN
SCK
SI
SO
Page 27 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.7
Connections between XM1205 and XE8801A/02/05A/06A/07A BitBang
XE8801A/
02/05A/06A/07A
XM1205
PA1
PA2
PA3
IRQ_1 / DCLK
DATA / DATAOUT
IRQ_0 / PATTERN
PC0
PC1
PC2
PC3
PC4
PC5
PC6
NSS_DATA / DATAIN
SW1 / TX
SW0 / RX
NSS_CONFIG
SCK
MOSI
MISO
Note for all XM1205 connections: SW0 and SW1 pins are not used in the current implementations. If connected, the
respective IO they are tied to must be configured accordingly.
7.2.8
TM
Connections between XM1205 and XE8806A/07A BitJockey
XE8806A/07A
TM
BITJOCKEY
7.2.9
XM1205
PB4
PB5
SW1 / TX
SW0 / RX
PD0
PD1
PD2
PD3
PD4
PD5
PD6
PD7
DATA / DATAOUT
IRQ_1 / DCLK
IRQ_0 / PATTERN
NSS_DATA / DATAIN
NSS_CONFIG
SCK
MOSI
MISO
Connections between XM1205 and XE8801A/02/05A/06A/07A Buffered
XE8801A/
02/05A/06A/07A
V4.0 – October 2009
XM1205
PA1
PA2
IRQ_1
IRQ_0
PD0
PD1
PD2
PD3
PD4
PD5
PD6
NSS_DATA
NSS_CONFIG
SCK
MOSI
MISO
SW1
SW0
Page 28 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.10 Connections between XM1209 and XE8801A/02/05A/06A/07A BitBang
XE8801A/
02/05A/06A/07A
XM1209
PA1
CLKD
PC0
PC1
PC2
PC3
PC4
DATA
SD
SC
DE
RE
TM
7.2.11 Connections between XM1209 and XE8806A/07A BitJockey
XE8806A/07A
TM
BITJOCKEY
V4.0 – October 2009
XM1209
PD0
PD1
PD2
PD3
PD4
PD5
PD6
PD7
DATA
CLKD
DATA
RE
DE
SC
SD
Page 29 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.12 Connections between SX1223 and XE8801A/02/05A/06A/07A BitBang
XE8801A/
02/05A/06A/07A
SX1223
PA1
PA2
DCLK
LD
PC0
DATAIN
PC3
PC4
PC5
PC6
EN
SCK
SI
SO
Note: DCLK and LD pins are not used in the current implementation. Connection is optional.
TM
7.2.13 Connections between SX1223 and XE8806A/07A BitJockey
XE8806A/07A
TM
BITJOCKEY
SX1223
PA2
LD
PD0
PD1
PD2
PD3
PD4
PD5
PD6
PD7
DATAIN
EN
SCK
SI
SO
TM
Note1: DCLK pin is not required when utilizing BitJockey , thus it is not connected.
Note2: LD pin is not used in the current implementation. Connection is optional.
TM
Note3: PD0, PD1, PD2 are not used (Tx only) but are reserved by the BitJockey peripheral
V4.0 – October 2009
Page 30 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.14 Connections between SX1211/10 and XE8801A/02/05A/06A/07A BitBang (Continuous)
XE8801A/
02/05A/06A/07A
SX1211/10
PA1
IRQ_1 (DCLK)
PA3
PA4
IRQ_0 (SYNC)
PLL_LOCK
PD0
DATA
PD3
PD4
PD5
PD6
NSS_CONFIG
SCK
MOSI
MISO
Note: PLL_LOCK signal is not used in the current implementation. Connection is optional.
7.2.15 Connections between SX1211/10 and XE8801A/02/05A/06A/07A Buffered & Packet
XE8801A/
02/05A/06A/07A
SX1211/10
PA1
PA2
PA3
IRQ_1
IRQ_0
PLL_LOCK
PD0
PD1
PD2
PD3
PD4
NSS_DATA
NSS_CONFIG
SCK
MOSI
MISO
Note: IRQ_0 and PLL_LOCK signals are not used in the current implementation. Connection is optional.
V4.0 – October 2009
Page 31 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.16 Connections between SX1212/13 and XE8801A/02/05A/06A/07A BitBang (Continuous)
XE8801A/
02/05A/06A/07A
SX1212/13
PA1
IRQ_1 (DCLK)
PA3
PA4
IRQ_0 (SYNC)
PLL_LOCK
PD0
DATA
PD3
PD4
PD5
PD6
NSS_CONFIG
SCK
MOSI
MISO
Note: PLL_LOCK signal is not used in the current implementation. Connection is optional.
7.2.17 Connections between SX1212/13 and XE8801A/02/05A/06A/07A Buffered & Packet
XE8801A/
02/05A/06A/07A
SX1212/13
PA1
PA2
PA3
IRQ_1
IRQ_0
PLL_LOCK
PD0
PD1
PD2
PD3
PD4
NSS_DATA
NSS_CONFIG
SCK
MOSI
MISO
Note: IRQ_0 and PLL_LOCK signals are not used in the current implementation. Connection is optional.
V4.0 – October 2009
Page 32 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.18 API connections between SX1230 and XE8801A/02/05A/06A/07A BitBang (MCU mode)
XE8801A/02/05A/
06A/07A
SX1230
MODE
PA3
PB0 (EOL)
PA1
PD0
DCLK
DATA
PD3
PD4
PD5
PD6
NSS
SCK
MOSI
MISO
Note: PB0 (EOL) signal is not used in the current implementation. Connection is optional.
V4.0 – October 2009
Page 33 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.2.19 Connections between SX1231 and XE8801A/02/05A/06A/07A BitBang (Continuous)
SX1231
XE8801A/
02/05A/06A/07A
PA1
DIO1 (DCLK)
PA3
DIO0 (SYNC)
DIO3-5
PD0
DIO2 (DATA)
PD3
PD4
PD5
PD6
NSS
SCK
MOSI
MISO
Note: DIO3-5 signals are not used in the current implementation. Connection is optional.
7.2.20 Connections between SX1231 and XE8801A/02/05A/06A/07A Packet
XE8801A/
02/05A/06A/07A
SX1231
PA1
PA2
DIO1
DIO0
DIO2-5
PD1
PD2
PD3
PD4
NSS
SCK
MOSI
MISO
Note: DIO1-5 signals are not used in the current implementation. Connection is optional.
V4.0 – October 2009
Page 34 of 35
www.semtech.com
Technical Note TN8000.18
Standard API Definitions
ADVANCED COMMUNICATIONS & SENSING
7.3
Glossary
AFC Automatic Frequency Control
API
Application Program Interface
FEI
Frequency Error Indicator
LO
Local Oscillator
RSSI Received Signal Strength Indicator
© Semtech 2009
All rights reserved. Reproduction in whole or in part is prohibited without the prior written consent of the copyright owner.
The information presented in this document does not form part of any quotation or contract, is believed to be accurate and
reliable and may be changed without notice. No liability will be accepted by the publisher for any consequence of its use.
Publication thereof does not convey nor imply any license under patent or other industrial or intellectual property rights.
Semtech. assumes no responsibility or liability whatsoever for any failure or unexpected operation resulting from misuse,
neglect improper installation, repair or improper handling or unusual physical or electrical stress including, but not limited
to, exposure to parameters beyond the specified maximum ratings or operation outside the specified range.
SEMTECH PRODUCTS ARE NOT DESIGNED, INTENDED, AUTHORIZED OR WARRANTED TO BE SUITABLE FOR
USE IN LIFE-SUPPORT APPLICATIONS, DEVICES OR SYSTEMS OR OTHER CRITICAL APPLICATIONS. INCLUSION
OF SEMTECH PRODUCTS IN SUCH APPLICATIONS IS UNDERSTOOD TO BE UNDERTAKEN SOLELY AT THE
CUSTOMER’S OWN RISK. Should a customer purchase or use Semtech products for any such unauthorized application,
the customer shall indemnify and hold Semtech and its officers, employees, subsidiaries, affiliates, and distributors
harmless against all claims, costs damages and attorney fees which could arise.
Contact Information
Semtech Corporation
Advanced Communication and Sensing Products Division
200 Flynn Road, Camarillo, CA 93012
Phone (805) 498-2111 Fax: (805) 498-3804
V4.0 – October 2009
Page 35 of 35
www.semtech.com