SPI operation
Full duplex operation
Digi XBee® 3 802.15.4 RF Module User Guide
85
Full duplex operation
When using SPI on the XBee 3 802.15.4 RF Module the device uses API operation without escaped
characters to packetize data. The device ignores the configuration of
AP
because SPI does not
operate in any other mode. SPI is a full duplex protocol, even when data is only available in one
direction. This means that whenever a device receives data, it also transmits, and that data is
normally invalid. Likewise, whenever a device transmits data, invalid data is probably received. To
determine whether or not received data is invalid, the firmware places the data in API packets.
SPI allows for valid data from the slave to begin before, at the same time, or after valid data begins
from the master. When the master sends data to the slave and the slave has valid data to send in the
middle of receiving data from the master, a full duplex operation occurs, where data is valid in both
directions for a period of time. Not only must the master and the slave both be able to keep up with
the full duplex operation, but both sides must honor the protocol.
The following figure illustrates the SPI interface while valid data is being sent in both directions.
Low power operation
Sleep modes generally work the same on SPI as they do on UART. However, due to the addition of SPI
mode, there is an option of another sleep pin, as described below.
By default, Digi configures DIO8 (SLEEP_REQUEST) as a peripheral and during pin sleep it wakes the
device and puts it to sleep. This applies to both the UART and SPI serial interfaces.
If SLEEP_REQUEST is not configured as a peripheral and SPI_SSEL is configured as a peripheral, then
pin sleep is controlled by SPI_SSEL rather than by SLEEP_REQUEST. Asserting SPI_SSEL by driving it
low either wakes the device or keeps it awake. Negating SPI_SSEL by driving it high puts the device to
sleep.
Using SPI_SSEL to control sleep and to indicate that the SPI master has selected a particular slave
device has the advantage of requiring one less physical pin connection to implement pin sleep on SPI.
It has the disadvantage of putting the device to sleep whenever the SPI master negates SPI_SSEL
(meaning time is lost waiting for the device to wake), even if that was not the intent.
If the user has full control of SPI_SSEL so that it can control pin sleep, whether or not data needs to be
transmitted, then sharing the pin may be a good option in order to make the SLEEP_REQUEST pin
available for another purpose. Without control of SPI_SSEL while using it for sleep request, the device
may go to sleep at inopportune times.
If the device is one of multiple slaves on the SPI, then the device sleeps while the SPI master talks to
the other slave, but this is acceptable in most cases.
If you do not configure either pin as a peripheral, then the device stays awake, being unable to sleep in
SM
1 mode.
