Using the spi_serial library

The spi_serial library is intended to control the CC1110 if it has a subg_rfspy firmware variant or equivalent. The library wraps the SPI communication protocol into a format that looks like a serial interface from the host perspective.

Actual meaning of the data you send to and receive from the CC1110 depends on what firmware it has on it. If you're using the default subg_rfspy, then check the readme at https://github.com/EnhancedRadioDevices/subg_rfspy for details about what to send to control the radio and how to interpret the data you get back.

spi_serial Functions

Create a new spi_serial object like so:

import spi_serial as ss
cc1110_coms = ss.SpiSerial()
cc1110_coms.reset() # not necessary, but does put the chip into a known state

Now you can use that object to communicate with the CC1110 simply.

Reading Data From the Chip

To get any data from the CC1110, use the read function.

data = cc1110_coms.read() # get all data from the CC1110
data = cc1110_coms.read(num_bytes) # get just num_bytes bytes from the CC1110

If there's no data available, this function will return an empty list.

Peek and Pop

You can also peek at the first byte without removing it from the data queue using peek().

datum = cc1110_coms.peek()

And you can pop just one byte using pop().

datum = cc1110_coms.pop() # equivalent to .read(1), and if called after peek() will return the same data

Checking on Data Status

You can see how much data can be read using the inWaiting function().

data_available = cc1110_coms.inWaiting()

Writing data

You can send data to the CC1110 using the write() function.

cc1110_coms.write("data to write")

Under the Hood

The CC1110 on the Explorer board communicates with the Intel Edison using a SPI bus. The SPI bus is mediated by the Edison, and the CC1110 must wait to actually send data until the Edison requests a data transaction.

To deal with this, the CC1110 has a queue (circular buffer) of data that is awaiting a SPI transaction.

When the Edison wants to perform a SPI transaction, it will first send a 0x99 character over SPI to alert the CC1110. It will then send the length of the data that will be sent from the Edison. Then it sends the data.

On the CC1110 side, it awaits a 0x99 reception, the sends the amount of data is has to send. Finally, it sends data until it has no data left.

Because the Edison controls the SPI communications, it is possible for it to request less than or more than the amount of data that the CC1110 has to send. The host must not request less than the CC1110 data has. If the host has less data to send then the CC1110 data has to send, then the host must issue enough transactions to fully read the CC1110 buffer. If the host has more data to send than the CC1110 does, then the CC1110 will send garbage after the good data. It is the responsibility of the Edison and host app to ensure that SPI transaction happen often enough that data isn't dropped from the queue on the CC11110. It is also the responsibility of the Edison and host app to ensure that good data is properly separated from garbage bytes.

Example transaction

The host app would like to send a command 0x01,0x02,0x03 to the CC1110.

The CC1110 currently has data 0x44,0x55,0x66,0x77 to send to the host.

First data transmission:

Edison TX   |   CC1110 TX   |  Explanation
0x99        |   don't care  |  Start of SPI transaction
0x03        |      0x04     |  data length
0x01        |      0x44     |  data
0x02        |      0x55     |  data
0x03        |      0x66     |  data
don't care  |      0x77     |  data, Note that the host must issue max(host_data_len, cc1110_data_len) SPI transactions