Which serial type to choose for inter-Teensy communication

[Bing]

Hi,

I'm starting a project where I will have two Teensy LC talking to each other. It will probably be one-directional, by I would like to keep both ways open. I will need to transmit messages of about 12 bytes. Ideally I would like to have it all transmitted in 1/10 of a millisecond (100us), but up to 1ms could be ok,
I'm looking at I2C, UART and SPI. What is my best choice? I'm able to write my own drivers if needed, but libraries are always nice. The length of the message means that an alternative with a buffer would be best, right?

/Erik

 

[Cosford]

For your two-device system, SPI will work fine, but doesn't really feature any real benefits, it'll just cost you 4 pins to implement.
UART provides maximum flexibility and simplicity in it's operation, but will cost you a hardware serial port that can't be used for anything else. It's worth looking here at the speed you need. For serial, 8-N-1, you need 10 bits to transmit each byte. At 12 bytes, that's 120 bits per packet. In order to transmit that via serial in 0.001 seconds (1ms), you'll need to be transmitting at 120 / 0.001 = 120,000bps.
Given that it sounds like your communication protocol is fixed (the messages), I would personally swing towards using I2C as it would provide expandability and I like the way the Wire (i2c) library tidies everything up. Having said that, it depends on your application as i2c will need pullup resistors and can only be used over short distance. The standard I2C frequency of 400KHz is more than enough for those data rates.

All in all, UART is probably the most straightforward option, assuming you've got a serial port free on each teensy that you're not using, but either UART or I2C are viable. SPI would work, but is overcomplicated for your needs.

 

[Constantin]

Unless there are other circumstances you haven't described, I'd stick to UART for now. There are methods/libraries like EasyTransfer that allow communication via I2C or UART, but I'd argue that UART is a lot easier to trouble-shoot and set up initially than either SPI or I2C. Plus, your messages are so short that they should fit in the buffer, allowing fire-and-forget operation, even if longer communication distances require RS485 transceivers in the mix.

Forum members have communicated with UART over short distances at 1MBit+/s. The only downside to using a Teensy LC is that you cannot use CTS signalling (RTS is supported on every digital pin). The 3.x series allow CTS/RTS, with forum members achieving 6Mbit/s throughput.

 

[Bing]

Thank you so much for your answers! Exactly the kind of guidance I need. I'll probably go with the UART for now. But since I have I/O to spare I'll probably reserve two I2C-pins as well in both ends.
I'll have to read up on that CTS/RTS signalling though. Haven't done much serial communication yet.
Just a couple of questions:
I'm I right to assume that I can achieve much higher baud rates since I have two devices with the same clock speed? So that any error in baud rate will appear on both devices? (https://www.pjrc.com/teensy/td_uart.html only lists speed up to 115kbps)
My two PCB's probably wont be more than 10-15 cm apart. Could I use standard PCB interconnection cables even if I go as hi as 0.5-1 Mbps?

 

[Constantin]

I'd try it out. As mentioned above, your max needed speed is around 115kbps, so setting them to 1Mbit/s not only provides a cushion, it should work over such a short distance also.

See easytransfer as a nice library to help with all this.

 

[defragster]

I'd try it out. As mentioned above, your max needed speed is around 115kbps, so setting them to 1Mbit/s not only provides a cushion, it should work over such a short distance also.

This was for LC - I did some quick tests and it topped out being reliable somewhere over 230Kbps for me with an LC talking to a T_3.2 - but 230KBps seemed good. Then I took the T_3.2 to 4 and 6 Mbps no problem and stopped testing with the LC. I'd suggest getting it working at that speed first.