Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 11 of 11

Thread: Multiple SPI interface on Teensy 3.6 ?

  1. #1
    Junior Member
    Join Date
    Dec 2019
    Posts
    8

    Multiple SPI interface on Teensy 3.6 ?

    Hello,

    First, i'm a beginner, so please keep that in mind.

    i'm running a device that use 2 I2C sensors + 1 SPI sensor. This configuration runs flawless.


    But the I2C devices can also be used in SPI (faster) so i'm trying to make everyone running on SPI.


    Sadly, 2 devices use MODE3, when the other one run in Mode0.


    I'm able to run the stuff starting my loop in mode3, then switching to mode 0 ect... but i have some bad interaction. In some case, eradically, some data of the mode0 sequence are read while running the beginning of the mode3 sequence. This create some crazy/erratic value.


    I don't want to slow down my loop so i wonder :


    Is it possible to run an SPI interface in mode 3 and an SPI interface in mode 0 at the same time on the Teensy ? this way i don't need to stop and start SPI in various mode each loop ? when i look at the output, i can see that there's CS1, SCK1, MOSI1... + the one i use CS0, MOSI0, MISO0...

    Thanks for your help

  2. #2
    I haven't tried it, but the PJRC documentation for SPI suggests using transactional configuration:

    https://www.pjrc.com/teensy/td_libs_SPI.html

    I'm sure it's also possible to use one SPI bus for each Mode, but seems unnecessary.

  3. #3
    Junior Member
    Join Date
    Dec 2019
    Posts
    8
    Thanks for your answer

    Transactional configuration is what i'm using right now... seems the best way to manage this multiple SPI settings. The Teensy documentation has been really helpfull but nothing about running 2 différent SPI bus at the same time in //, even if on of them is software.

    In the documentation, MOSI1, MISO1 are describe as alternate pin, in case the default one are used, but it's not a second SPI bus... just alternative pins.

  4. #4
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,837

    Cool

    Quote Originally Posted by Guigui56 View Post
    Thanks for your answer

    Transactional configuration is what i'm using right now... seems the best way to manage this multiple SPI settings. The Teensy documentation has been really helpfull but nothing about running 2 différent SPI bus at the same time in //, even if on of them is software.

    In the documentation, MOSI1, MISO1 are describe as alternate pin, in case the default one are used, but it's not a second SPI bus... just alternative pins.
    No, I believe they are separate SPI buses. The main pins for 3.5/3.6 are:
    • Spi bus 0: MOSI0: 11 (alternate pins 7 or 28), MISO0: 12 (alternate pins 8 or 39), SCLK0: 13 (alternate pins 14 or 27), Favored CS pins: 9, 10, 15, 20, and 21 (*);
    • Spi bus 1: MOSI1: 0 (alternate pin 21), MISO1 (alternate pin 5): 1, SCLK1: 32 (alternate pin 20), Favored CS pin: 31
    • Spi bus 2 (underneath the Teensy): MOSI2: 44, MISO2: 45, SCLK2: 46, Favored CS pin: 43


    To access the second SPI bus use SPI1, to access the third SPI use SPI2. As usual with the Arduino libraries, the library may not have support for multiple SPI buses.

    * There are additional favored SPI ports for SPI0, but you can only use one of the two pins for SPI usage:

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,519
    Quote Originally Posted by Guigui56 View Post
    In the documentation, MOSI1, MISO1 are describe as alternate pin, in case the default one are used, but it's not a second SPI bus... just alternative pins.
    Could you be more specific about exactly which documentation?

    MOSI0,MISO0,SCK0 (pins 11,12,13) are a separate and fully independent bus from MOSI1,MISO1,SCK1 (pins 0,1,32).

  6. #6
    Junior Member
    Join Date
    Dec 2019
    Posts
    8
    for the documentation, this sentence let me think it : "The pin must be the actual alternate pin supported by the hardware, see the table above;" documentation http://www.pjrc.com/teensy/td_libs_SPI.html

    English (or American) isn't my native language, so i may mistake in some understanding. Thanks Paul for your patience and support on the Forum. I've learned all from all the various examples and topics, always interesting to come here.

    MichaelMeissner thanks a lot, let's see what i'm able to do with this

  7. #7
    Junior Member
    Join Date
    Dec 2019
    Posts
    8
    Looks like it works

  8. #8
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    3,837
    Great, glad it worked.

    BTW, the part about favored pins is only for the drivers that try to get the most out the SPI performance, typically some of the display drivers and I think the ethernet driver. For the best speed, if you are using a display that has the optimization in it, you need to be using SPI0. That is because you need two 'favored' pins for the CS and D/C pins, and only SPI0 has more than one favored pin.

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,519
    Quote Originally Posted by MichaelMeissner View Post
    typically some of the display drivers and I think the ethernet driver.
    The Ethernet library does not use the special SPI CS feature. Any digital pin can be used for CS with Ethernet.

    Long ago I did briefly attempt this with Ethernet, but it made almost no performance improvement. Instead I rewrote the Ethernet library (which became Arduino's official version 2.0.0) with many other ways to improve performance, like caching the socket registers to eliminate a tremendous amount of redundant SPI communication.

    Most SPI chips and their supporting software work like Ethernet, where using the special CS pin control by hardware make little or no difference to overall performance. You usually end up with pretty much the same performance just using digitialWriteFast() to control the CS pin.

    But TFT display with a D/C signal are the exception. Specially optimized libraries using those CS pins do achieve pretty amazing performance.

  10. #10
    Just to clarify, will calling SPI.setSCK(14) automatically set pin 14 to be *SCK0* and calling SPI.setSCK(20) automatically set pin 20 to be *SCK1*? In other words, is it not necessary (or even possible) to specify which SPI bus because that happens automatically depending on which pin number you pass?

  11. #11
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,431
    Don't forget when changing the SPI mode to do a dummy read before asserting the line to communicate, this will put the clock to a known high or low state for next transfer and probably wouldnt have corrupts data between mixing modes

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •