Multiple SPI bus

Status
Not open for further replies.

rebel2234

Member
Hello,

This is my first post and I just received my first teensy (3.1) a few days ago and I would like to say, "I LOVE IT". I am a beginner at arduino and have been doing alot of reading but I cannot seem to find an answer in the forums or from the "University of Google" librarys, so I'll ask here.

1.Can I have multiple SPI buses on the same teensy at the same time?
2.If the first question is true how would I get the Radiohead library (http://www.airspayce.com/mikem/arduino/RadioHead/) to use 1st bus and the ILI9341_t3 library https://github.com/PaulStoffregen/ILI9341_t3 to use the 2nd bus each using its own SPI driver?

I have tried putting a RFM69HW and a ILI9341 on the same SPI bus and get strange things happening when they share the same bus. They work independent of each other just fine (different sketches). I think the SPI differences/anomalies are causing me trouble and I don't have the skills to write my own librarys.
 
i found this bit on the spi page. "Alternate SPI pins

Sometimes, the SPI pins are already in use for other tasks when an SPI device is added to a project. If that task is simply a digital pin, or an analog input, it is usually better to move that to another pin so that the hardware SPI can be used. Sometimes though, the conflicting pin cannot be moved. The Audio Adapter, for example, uses some of the SPI pins to talk to the Audio DAC over I2S. For this case, Teensy 3.0 and 3.1 provide an alternate set of SPI pins.

The main SPI pins are enabled by default. SPI pins can be moved to their alternate position with SPI.setMOSI(pin), SPI.setMISO(pin), and SPI.setSCK(pin). You can move all of them, or just the ones that conflict, as you prefer. The pin must be the actual alternate pin supported by the hardware, see the table above; you can't just assign any random pin.

You should be aware that libraries sometimes have to move SPI pins. (The Audio Library is an example). If you add an SPI device yto your project and it does not work, check whether the library has moved the pins and if so, use the same pins the library does.

If all else fails, the SPI protocol can be emulated ("bit-banged") in software. This has the advantage that any convenient pins can be used, and the disadvantage that it is much, much slower and prevents your sketch from doing useful work meanwhile."
 
There has been a lot of discussion about transactional SPI. You might want to look up some of the threads with it. This page describes the new features that went into 1.20: http://www.pjrc.com/teensy/td_libs_SPI.html. Note, I have not used SPI, I just was pointing you to discussions that I've seen.

Also, the new Teensy-LC which is being rolled out (i.e. you can pre-order it, and Paul is working on the libraries) has 2 SPI buses: http://www.pjrc.com/teensy/teensyLC.html
 
i found this bit on the spi page. "Alternate SPI pins

Sometimes, the SPI pins are already in use for other tasks when an SPI device is added to a project. If that task is simply a digital pin, or an analog input, it is usually better to move that to another pin so that the hardware SPI can be used. Sometimes though, the conflicting pin cannot be moved. The Audio Adapter, for example, uses some of the SPI pins to talk to the Audio DAC over I2S. For this case, Teensy 3.0 and 3.1 provide an alternate set of SPI pins.

The main SPI pins are enabled by default. SPI pins can be moved to their alternate position with SPI.setMOSI(pin), SPI.setMISO(pin), and SPI.setSCK(pin). You can move all of them, or just the ones that conflict, as you prefer. The pin must be the actual alternate pin supported by the hardware, see the table above; you can't just assign any random pin.

You should be aware that libraries sometimes have to move SPI pins. (The Audio Library is an example). If you add an SPI device yto your project and it does not work, check whether the library has moved the pins and if so, use the same pins the library does.

If all else fails, the SPI protocol can be emulated ("bit-banged") in software. This has the advantage that any convenient pins can be used, and the disadvantage that it is much, much slower and prevents your sketch from doing useful work meanwhile."

I don't want to simply "move" the pins I would like to use 2 SPI interfaces at the same time. EG RFM69 attached to SPI(1) and ILI9342 attached to SPI(2). The reason for this is these two devices on the same SPI bus do not play well together. When I activate the RFM69 radio to send/recieve some data the radio sets the interrupt pin high and will not release control back to mcu.
 
Using SPI Transactions as is in the latest Arduino and Teensyduino, allows one SPI to serve 2+ SPI slaves.
But with a real time device like wired/wireless communications - one has to be mindful of if the top level comms protocol will correct for missed messages if the other SPI devices hogs the SPI port too long.
That is, the latency in servicing the comms device goes up due to sharing. For non-real time things, this is usually a non-issue. I suppose SPI based lights and sounds are latency-senstitive too, in terms of discernible glitches.

2+ SPIs are the nice solution. Many M4s have 2, 3, 4 or more SPIs these days; not all are made by Freescale (aka NXP).
 
my thinking was alternate between moving the spi busses. use one bus, do your business, then switch the pins and use the other device, done. move the bus back to the other one. did you need synchronous data transfers?
 
i found this bit on the spi page. "Alternate SPI pins

Sometimes, the SPI pins are already in use for other tasks when an SPI device is added to a project. If that task is simply a digital pin, or an analog input, it is usually better to move that to another pin so that the hardware SPI can be used. Sometimes though, the conflicting pin cannot be moved. The Audio Adapter, for example, uses some of the SPI pins to talk to the Audio DAC over I2S. For this case, Teensy 3.0 and 3.1 provide an alternate set of SPI pins.

The main SPI pins are enabled by default. SPI pins can be moved to their alternate position with SPI.setMOSI(pin), SPI.setMISO(pin), and SPI.setSCK(pin). You can move all of them, or just the ones that conflict, as you prefer. The pin must be the actual alternate pin supported by the hardware, see the table above; you can't just assign any random pin.

You should be aware that libraries sometimes have to move SPI pins. (The Audio Library is an example). If you add an SPI device yto your project and it does not work, check whether the library has moved the pins and if so, use the same pins the library does.

If all else fails, the SPI protocol can be emulated ("bit-banged") in software. This has the advantage that any convenient pins can be used, and the disadvantage that it is much, much slower and prevents your sketch from doing useful work meanwhile."

my thinking was alternate between moving the spi busses. use one bus, do your business, then switch the pins and use the other device, done. move the bus back to the other one. did you need synchronous data transfers?

Brilliant! I will give this a try wasn't thinking of it that way.
 
I must not be seeing the concept, above.

Please clarify how the above differs from the usual method for 2+ SPI slave devices on one SPI controller:
MOSI, MISO go to every slave device.
slave select, a GPIO pin, one per device to choose which slave device to use for a data exchange. Then use a different slave select.
 
my understanding is that one of the devices was behaving out of the spi spec. but without the devices i'm just guessing.
 
Thank you everybody for the help. I created a function to switch hardware spi ports (as mentioned by aortiz557) and used it to help me determine the problem. The problem, if anybody is interested, is when I use the ILI9341_t3 library. I'm assuming that the "enhancements" (buffer, dma) are causing havoc with the Radiohead library.

Pretty easy to reproduce the problem. Use ILI9341_t3 library with either RH current version (1.39) or Paul's transaction based RH libray https://github.com/PaulStoffregen/RadioHead and an rfm69 hooked up on the same spi bus as a ILI9341 http://www.ebay.com/itm/3-3V-240x32...993?pt=LH_DefaultDomain_0&hash=item486c890399. Anytime there is any interaction on the spi bus with the radio and this combination of library's, the clock pin (13-LED) will just stay lit, and the radio activate's the interrupt line and will not release control back to mcu.

Would love to use the ILI9341_t3 library with my project as it is very fast but seems that the standard adafruit GFX/ILI9341 gets along with my radio and TFT so will use those lib's instead.

Again thanks for the help, great forum!
 
Status
Not open for further replies.
Back
Top