Digi XBee3 XB3M1, Руководство пользователя

Страница: 139 / 252

SPI operation Full duplex operation
Digi XBee3 Cellular LTE-M/NB-IoT Global Smart Modem User Guide 139
Full duplex operation
The specification for SPI includes the four signals SPI_MISO, SPI_MOSI, SPI_CLK, and SPI_SSEL. Using
these four signals, the SPI master cannot know when the slave needs to send and the SPI slave
cannot transmit unless enabled by the master. For this reason, the SPI_ATTN signal is available in the
design. This allows the SPI slave to alert the SPI master that it has data to send. In turn, the SPI
master is expected to assert SPI_SSEL and start SPI_CLK, unless these signals are already asserted
and active respectively. This, in turn, allows the XBee Smart Modem SPI slave to send data to the
master.
SPI data is latched by the master and slave using the SPI_CLK signal. When data is being transferred
the MISO and MOSI signals change between each clock. If data is not available then these signals will
not change and will be either 0 or 1. This results in receiving either a repetitive 0 or 0xFF. The means
of determining whether or not received data is valid is by packetizing the data with API packets,
without escaping. Valid data to and from the XBee Smart Modem is delimited by 0x7E, a length, the
payload, and finally a checksum byte. Everything else in both directions should be ignored. The bytes
received between frames will be either 0xff or 0x00. This allows the SPI master to scan for a 0x7E
delimiter between frames.
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 is sending data to the slave and the slave has valid data to send in
the middle of receiving data from the master, it allows a true full duplex operation where data is valid
in both directions for a period of time. During this time, the master and slave must simultaneously
transmit valid data at the clock speed so that no invalid bytes appear within an API frame, causing the
whole frame to be discarded.
An example follows to more fully illustrate the SPI interface during the time valid data is being sent in
both directions. First, the master asserts SPI_SSEL and starts SPI_CLK to send a frame to the slave.
Initially, the slave does not have valid data to send the master. However, while it is still receiving data
from the master, it has its own data to send. Therefore, it asserts SPI_ATTN low. Seeing that SPI_
SSEL is already asserted and that SPI_CLK is active, it immediately begins sending valid data, even
while it is receiving valid data from the master. In this example, the master finishes its valid data
before the slave does. The master will have two indications of valid data: The SPI_ATTN line is
asserted and the API frame length is not yet expired. For both of these reasons, the master should
keep SPI_SSEL asserted and should keep SPI_CLK toggling in order to receive the end of the frame
from the slave, even though these signals were originally turned on by the master to send data.
During the time that the SPI master is sending invalid data to the SPI slave, it is important no 0x7E is
included in that invalid data because that would trigger the SPI slave to start receiving another valid
frame.
The following figure illustrates the SPI interface while valid data is being sent in both directions.