How to use additional SPI ports on Teensy 3.5/3.6

Status
Not open for further replies.
G

GlennBabecki

Member
I understand how the basic SPI library functions behave, but I am wondering how one specifies a specific SPI port on devices like the Teensy 3.5 and 3.6 which have 3 SPI ports. I started to pick apart the SPI (and related) libraries to see how they work but it wasn't really clear if there is a mechanism to do this in the Arduino, Adafruit, or Teensyduino libraries.

I started to look at this in conjunction with the ILI9341 TFT display with the XPT2046 touch controller while thinking about incorporating another display and other SPI peripherals in a project. It almost seems serendipitous how the XPT2046 library makes use of the ILI9341 SPI settings for the common bus signals when the two devices are on the same bus. While I could put more SPI devices on one SPI bus, I started to wonder how to make use of the other SPI busses on processors with more than one SPI bus.

If my inquiry makes any sense I would deeply appreciate an explanation or pointers to references that explain how the libraries work with multiple SPI busses.

Thanks,
Glenn
 
For "normal" SPI usage, you would just replace "SPI" with "SPI1" or "SPI2". In most libraries, that means editing the library code to replace it everywhere in the code.

But some libraries like ILI9341_t3 aren't normal. ILI9341_t3 accesses the hardware registers directly, and it depends on the FIFO which isn't present in SPI1 and SPI2. Only the main SPI port has the FIFO, so there's no hope to use ILI9341_t3 on the other ports.
 
If you look at my version ili9341_t3n, I work with all of the SPI ports. You can ask for them in particular, by passing in one of my SPIN objects. I created the SPIN objects when we started testing of the T3.6 beta, to allow me to run code on different SPI busses.

My more recent versions of that library will try to automatically choose the correct SPIn/SPI object if you pass in all of the pin numbers for (MOSI, SCLK, MISO, CS...)
 
Paul,

Thanks for confirming my fear/understanding of what I was reading in the libraries. While I could certainly "locally fork off" a version of the library for my own use, I would rather stick to the standard libraries, especially with the SPI because it is used by numerous other libraries. I would have though the SPI library would have been designed to support user selections of the "port" when instantiating the SPI object. I guess the history with original, smaller Arduino processors sort of set the precedence on the library structure. Perhaps some food for though to whoever controls the SPI library.

I suspected the ILI9341 made use of the SPI port with the FIFO, but given that, is it possible to hang two displays off the same SPI lines and select the display via the SS or CS line? Of course I say that without having re-examined the ILI9341 library which may make that cavalier suggestion moot.

My desire for a second display is essentially to bypass having discrete LED indicators (with printed labels) and have the flexibility of labeling active function indication via the TFT display. In this secondary display would only be updated by user function selection so I don't have to worry about it competing for the main display SPI resources on a continuous basis.

Kurt,

Thanks for chiming in on my inquiry as well. I did see your posts on your SPIN object library and thought it a clever way of dancing around the existing SPI library organization. I might look at that much closer but will see if I can do a simple workaround, or worst case just resign myself to using discrete LEDs with fixed labels in the project.

Again, thanks to you both for the support.

Best Regards,
Glenn
 
Note: with current version of Teensyduino,

All of the SPI objects are of the same class SPIClass. This is also the same class name as some of the Arduino boards like the Due, M0...
So over time, hopefully we can get more libraries to allow them a way to either pass in which SPI object to use or that they can deduce it on their own given a set of pin numbers.

So almost all of the functionality I put into SPIN, we moved into SPI library, including most of my internal tables. What things we did not add to SPI that is in SPIN, is some more of the queue management. That is some of the helper functions that Paul originally put into ili9341_t3 library, I put into SPIN, which include:

Code: 
    void waitFifoNotFull(void);
    void waitFifoEmpty(void);
    void waitTransmitComplete(void) ;
    void waitTransmitComplete(uint32_t mcr);

Also added query function to get the size of the queue. That is SPI has queue of 4, whereas SPI1 and SPI2 are 1...
Likewise added a query to get a pointer to the hardware registers... Note SPI has this as well, but not public

So would not be hard to make version of main ili9341_t3 library that supports all 3 busses, using native SPI library... Maybe at some point I will update _t3n to not use spin... Would be easier with the Pull Request #41 which would merge in lots of _t3n into _t3...

I have updated a few other libraries to work with the different SPI ports... Not sure if any of them got pulled back into github or not.
I know I put in a way to use RadioHead on the RF95 radios, which I believe is in the current version (Teensyduino). This was sort of a hack, but works...

Again I am hoping over time (sort of like beginTransaction/endTransaction), we can get more and more libraries updated.
 
Thanks for the additional insight on the SPIN library history and organization. It should help navigating the ILI9341 and SPI libraries in the event I need to get into the other SPI ports on the current project; the "jury" is still debating "need" vs. "desire" there.
 
Status
Not open for further replies.
Back
Top