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

Thread: SPI Master/SLAVE Communication

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

    SPI Master/SLAVE Communication

    Hello, I'm trying to communicate my master teensy 4.1 board with several teensy 4.1 slave boards, but I couldn't find any library that can help me to make a teensy work as a slave.
    I tried I2C protocol and it worked but I need higher speed than the one I have with I2C.
    Can you help me with this problem

  2. #2
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    715
    Why not try Serialx. T4.1 has 8 serial ports to connect to up to 8 T4.1s.

  3. #3
    Junior Member
    Join Date
    Dec 2021
    Posts
    8
    Because the other Teensy pins are used for other purposes
    Also because SPI communication is much faster than I2C and UART

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,232
    UART Serial may be more competitive with SPI than you're assuming.

    On Teensy 4.1, the maximum baud rate is 1/4th of the UART's base clock, which defaults to 24 MHz. But the hardware can be programmed for an 80 MHz base clock, so at least in terms of raw hardware support in the chip, UART baud rates can reach into the SPI range. Even though not as high as the 30 MHz SPI maximum (or maybe 50-60 MHz if you don't care about NXP's official specs), each UART port has dedicated bandwidth. The total available bandwidth can actually be higher with serial, unless your design artificially limits communication to happen only on 1 port at a time, as you would be forced to do with SPI.

    Serial gives you 2 important advantages over SPI.

    #1: Wiring is point-to-point and high speed RS422 transceiver chips exist to make it very reliable over longer distance. With SPI, you must connect all devices to the same 3 wire bus, plus chip select signals. When you scale up to several devices and you wish to run at high speed, signal quality becomes much harder, especially if the devices are separated by any substantial distance. The asynchronous nature of serial means you can easily add buffer chips, but with synchronous SPI any buffer chips eat away at your timing margin, which is already tight if you're running near the maximum speed.

    #2: Serial provides hardware flow control with RTS/CTS signals, and the existing software gives substantial buffers for transmit and receive. Perhaps you will write all of your code so efficiently that you won't need flow control or much buffering. But that is a difficult software timing challenge, especially if your code may be expanded or maintained in the future. RTS/CTS flow control makes the software side much easier and far more robust to future design changes which alter the overall timing of receiving data. One minor gotcha is you'll need to use the XBAR pins for many CTS signals, which are inverted from normal CTS, so you'll need to add hardware inverters to make it work. Still, I would highly recommend using RTS/CTS flow control, unless you know your communication will always be so very simple that your software complexity will remain very low.

  5. #5
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Santa Fe, NM
    Posts
    764
    A search brought up this library: https://forum.pjrc.com/threads/66389-SPISlave_T4

    Note that I haven't used it, I would ask questions regarding library use in that thread. Agree with others that I would try Serial first and verify that it doesn't meet your requirements before jumping into SPI - Serial is just so darn easy to setup and use.

Posting Permissions

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