2 simultaneous SPI communications on Teensy for a Full-Duplex System

Status
Not open for further replies.
S

sraj

Member
Simultaneous SPI comms for a Full-Duplex System using 2 Half-Duplex RF modules.

I have a Teensy3.2 but it has only one SPI port. Whereas Teensy 3.5 and Teensy 3.6 have 3 SPI ports. On the kickstarter page this is what is mentioned "3 SPI Ports (1 with FIFO)", can anyone please explain what exactly that means?

Lets say i want to use the 2.4GHz NRF24L01+ modules. If i use only one of them then i get a Half-Duplex system. Even if i use 2 of the modules but the hardware SPI is only one, then also i get a Half-Duplex system. But I wanted to make a Full-Duplex system.
I wanted to know if there is support for multiple simultaneous SPI communication on either Teensy 3.5 or Teensy 3.6. If not, then is it still practically possible to develop firmware that achieves simultaneous multiple SPI communications because there are 3 SPI ports available. If yes, then i would be willing to buy new Teensys and work on the development of this functionality.
 
Last edited:
All three SPI ports are independent and data shifts out as it shifts in on all three during use.

The FIFO enhanced one has added depth for holding RX/TX bytes.
 
Thanks for the explanation.
Do you know about any firmware support for simultaneous SPI comms ? Or is it yet to be implemented?
 
On SPI by design one byte comes and goes on each transfer - so Full Duplex per port is how it works. Each single port pushes a byte as it pulls a byte. There is one clock and two data lines one MISO and one MOSI. Give Wikipedia or other reference a quick check for protocol details and terminology.

And SPI is a hardware controlled transfer on the bit level - each port is wholly independent of the others.
 
I know that already, but with regards to the wireless module, they themselves are NOT full-duplex. When it is receiving data, it cannot transmit and vice-versa. This can be mitigated if we use 2 wireless modules where one is taking care of transmissions and the other is a receiver ALWAYS. But this begs the question that if both SPI buses cannot work simultaneously then effectively the system is still only receiving or transmitting RF packets i.e Half-Duplex from pov of Wireless comm, not SPI. I am interested in Full-Duplex wireless comm.
 
sraj said:
Do you know about any firmware support for simultaneous SPI comms ? Or is it yet to be implemented?
Click to expand...

Yes, there is support for simultaneous SPI usage, thanks mostly due to recent contributions from KurtE. :)

This stuff is pretty new and so far not documented much, so you're probably going to have to look at SPI.h and do some experimenting. But the basic idea is you set up a pair a buffers, for the data you wish to send on MOSI and the place you wish to receive whatever the chip sends on MISO. You also create an EventResponder object (another pretty new, not so well documented yet) to give you a notification when the operation completes. Then you call SPI.transfer(txBuffer, rxBuffer, count, eventresp) to start the transfer. To use both ports at the same time, you just do this on both of them. All 3 are supported, so you could start transfers on all of them, and then do other work before you get the completion notifications from those EventResponders.

Obviously this is quite a bit more complex than the ordinary SPI.transfer(byte) and SPI.transfer(buffer, count) which block until the transfer completes. Whether the extra complexity is "worth it" really depends on the specifics of your application. If you only send and receive a few bytes at a time and you can use fast SPI clock speeds, odds are strong the extra overhead will offset any gains from simultaneous transfer. It generally is most useful for large data transfers, or chips that require a rather slow SPI clock.

More than 1 SPI port can also be useful, even if not using the special non-blocking function. The 2 common cases are using the SPI from both interrupts and main program. SPI.beginTransaction() is means to give you protected access, assuming you've also properly configured with SPI.usingInterrupt(). But the downside is some or all interrupts get blocked, which might delay a library like Audio if it's accessing a serial flash chip or SD card (though the boards with more than 1 SPI also have dedicated SDIO for their SD cards, so no SPI sharing if using that SD slot). The other common case is dealing with badly designed SPI chips like RA8875 & CC3000 which do not properly tri-state their MISO pin. It's not Teensy's fault those chips don't "play nice" with other SPI chips, but having an extra SPI port for the badly behaved chip means you don't need to add a tri-state buffer.
 
sraj said:
if both SPI buses cannot work simultaneously then effectively the system is still only receiving or transmitting RF packets i.e Half-Duplex from pov of Wireless comm, not SPI. I am interested in Full-Duplex wireless comm.
Click to expand...

Maybe I'm reading too much into your question, but it kind of sounds like your mental model of the NRF24L01+ is that the RF transmission & reception happens synchronously with the SPI clock. Two of them can't possibly be communicating over the air at the same moment if you do not have two SPI clocks active, because the bits over the air correspond in real time to the SPI data.

But that's not how the NRF24L01+ actually works. The outgoing and incoming data flows through through FIFOs, 96 bytes in each direction. This is documented in the datasheet. Look at page 51 for this diagram and description.

fifo.png

The SPI communication accesses the data from the FIFOs. There is not a 1-to-1 real time correspondence of the SPI data and the actual radio transmission & reception.

Simultaneous SPI access still might be very valuable. But before you go down that path, I believe you should really review the datasheet carefully to understand how these modules with their FIFOs really work. These aren't simple "dumb" modules where the data pin turns on RF circuitry. Quite a lot happens within the chip. The SPI rate goes up to 8 MHz, but the actual over-air rate is only 1 or 2 Mbit/sec, and includes packet overhead. Maybe you've already carefully considered all these details?

but with regards to the wireless module, they themselves are NOT full-duplex. When it is receiving data, it cannot transmit and vice-versa. This can be mitigated if we use 2 wireless modules where one is taking care of transmissions and the other is a receiver ALWAYS.
Click to expand...

Another possible issue you might consider is whether another module's antenna receives properly within the near field RF of the transmitting antenna. It might. But these sorts of radios are almost certainly designed for far field reception.
 
Thanks a lot Paul for the invaluable information. I will look into all of these in details and decide my next step.
 
Status
Not open for further replies.
Back
Top