Help with multiple SPI buses and SD card reading

Status
Not open for further replies.

128ITSH

Active member
Hello everyone.
I'm corrently designing a project which requiers data logging with an SD card and SPI RF transmittion at the same time.
For the RF transmittion I will be using two of these NRF24L01+ transrecivers which run on SPI interface.
transreciever.png
The recieving side is less important for this question because I have already figured it out but the transmitting side, which should also log data is confusing.
My problem is:
Both the RF modue and SD card use the SPI protocol, and both are using dedicated, different libraries.(RF24 and SD), and I'm afraid they can interfere each other while used on the same SPI bus. However, teensy LC have two SPI buses, and teensy 3.5/3.6 have an onboard SD card.

My question is, can I use the two sperate SPI buses on the teensyLC simultaneously? If yes, how can I set different pins for each library?
If this is not possible, can I use one external SPI bus for the RF module, on the teensy 3.6/3.5, while writing to the onboard SD using the internal SPI bus?

Thanks in advance!
 
You could use the 2 SPI busses of the Teensy LC separately at the same time. That's the lazy solution or the path of least resistance.

The academic way would be to study both libraries and to take their code as inspiration to write your own, handling both devices on one SPI bus, using different CS pins and/or transaction configurations.
 
Because this is a prototype and not the finished, optimized product, I will go on the easy way :)
How can I achive this?
 
Sorry using iPad waiting for car service...

This is a complicated question. Yes you can use both spi busses on LC or all 3 on 3.5 or 3.6 and SD at same time,
But the hard part is getting all the software to do this.

Few issues like:

A) most libraries are hard coded to SPI so either you need to make a version that uses SPI1 or SPI2, or better yet allows you to pass in which one.

B) you need to connect your devices to the right pins. Which can be either the default or alternate.

C) Code has to be set up such that multiple busses can be active at the same time. Things like most calls like SPI.transfer work in lock step, that is when you call them, they don’t return until they complete their transfer, so only one bus active.

However there are ways,like newer SPI.transfer(buff, retbuf, count, eventHandler), is setup to do this asynchronous, using DMA. Likewise dma spi library also can do this. But not many libraries are setup to do this!
 
After more searching I found your SPIN library, which seems to be able to access different SPI ports.
Do you think I can rewrite the libraries to use SPIN instead of SPI? Or there is already such implementation for SD card read/wrie, or NFL24L01+ communication?
 
Yes my SPIN library can do it! However for most cases now you can use the SPI library itself.

Background: I developed the SPIN library originally to help with testing of the Teensy 3.6 when it first went into beta. Needed some way to test the other SPI ports and did not like the idea of having to edit libraries every time to do things like: change SPI to SPI1...

Problem was that the three SPI classes were all unique classes, so you could not pass in a pointer to some base class for them... So I created the SPIN objects which were simply call forwarders to do the work...

Since then we re-implemented SPI, such that all of the objects are created from one class: SPIClass The great thing about updating libraries to use multiple SPI objects by passing in a reference or pointer to SPI object, you might have a higher level of success of having the library owner incorporate these changes as we are using the same class names as Arduino for DUE and M0 SPI classes. So adding support for multiple SPI busses on Teensy also allows multiple SPI objects on other platforms... With the normal caveat that you are not doing something specific with the actual hardware.

So you can now do most of the same capabilities passing in SPIClass objects as you could with SPIN objects. Note: there were a few capabilities I put into SPIN that allowed me to use the SPI hardware registers more easily for when we wish to bypass the normal SPI.transfer(...) calls and instead work with the registers and FIFO queues... But more libraries that work with SPI library do not use this.

Earlier on, I played around with the Radiohead library and added some support for SPI1 and SPI2. There is more details about it in the posting: https://forum.pjrc.com/threads/41610-RFM69-on-SPI1?p=130885&viewfull=1#post130885

I am pretty sure that the Radiohead library that ships with current Teensyduino has this support. So you might take a look at it.

As for SD. On Teensy 3.5 and 3.6, these don't use SPI. The hardware has SDCard support which is used instead.
 
Even though I think I could manage to change some stuff in the RH_NRF24.cpp file and its related classes, and get it to work on the specific SPI port I need, I will give up for now because this issue gives me a headache. I know it might be easy but I will prefer to make stuff easier.
So for this project I will use a smaller, cheaper MCU with the sparkfun OpenLog data logger which runs on an UART serial interface so I can use the SPI bus for the NRF24.
Anyways, thanks for the help. I am planning to buy the teensy 3.6 for future project and this info will help me if I will encounter this problem again.
 
Status
Not open for further replies.
Back
Top