Best communication interface for multiple Teensy LCs and 3.Xs

Status
Not open for further replies.

George1

Active member
Hi,


I will be designing a new instrument that will be made up of different modules and each module will have Teensy LC or Teensy 3.2. The main module will either have Teensy 3.2 or Teensy 3.6. Different modules will need to share some basic data between each other but will not require very high bandwidth (in practice data rate transfer should be below 5Kbytes per second).

I need some suggestion on what might be the best communication protocol to connect multiple Teensies on a common communication bus.

I am considering:
1. CAN (designed for multiple MCUs and there is a Teensy library)
2. I2C (set the main Teensy as a master and other Teensies as slaves and assign addresses, I need to do more research on this to figure out if the idea is viable)

Thanks for any suggestions,
George
 
What are the distances between the Teensies? Will they be on a single board or discrete devices?

I2C is designed for on-board communications, and is quite sensitive to EM noise when travelling over wires.

For longer distances or intra-device communication you will be best off with a serial bus like CAN or RS-485. This does require a transceiver at each separate device, but scales well for longer distances. I personally would favour RS-485 because it is much simpler to implement and the transceivers cost less.
 
Last edited:
Note, the LC does not support CAN. So if you go with CAN, you would need at least 3.2. I've not used CAN, so I don't know any more detail.

How close are your Teensys going to be? I2c in general is meant for boards being nearby (probably 1 meter or less). I've seen this i2c extender at tindie.com, but the guy only had 6 buyers, so I'm not sure how well it works:

An alternative might be multi-drop serial, where everybody is on the same serial line, and the host sends out messages with an ID, and each slave, looks for the ID, and responds to that ID. Since things are synchronous you shouldn't have overlap problems. If the Teensys are not close together, you may want to use RS-485:

If you have 6 or less slaves, you could make the Teensy 3.6 the master and use each serial UART to talk to an individual slave.
 
If your communication pattern fits well into the base CAN format of having packets with message ID + up to 8-byte payload, I would go with CAN. Any device on the bus can initiate communication and you get hardware error checking and automatic re-transmission for free.

If you have a small network, you can get away without real CAN transceivers:
https://forum.pjrc.com/threads/43684-CAN-bus-Teensy-Teensy-communication-without-transceiver

Be careful ordering CAN transceivers from eBay, several people have reported problems.
 
For longer distances or intra-device communication you will be best off with a serial bus like CAN or RS-485. This does require a transceiver at each separate device, but scales well for longer distances. I personally would favour RS-485 because it is simpler to implement
IMO, it's the other way around. Half-duplex multi-node RS-485 is a lot more cumbersome than CAN, particularly once you incorporate robust error handling. The basic CAN communication is very simple, only some of the higher level protocols that have been built on top of CAN are complex.
 
IMO, it's the other way around. Half-duplex multi-node RS-485 is a lot more cumbersome than CAN, particularly once you incorporate robust error handling. The basic CAN communication is very simple, only some of the higher level protocols that have been built on top of CAN are complex.
Why I prefer RS-485 is because it uses the UART, so you can just use simple Serial statements to juggle your data around. You don't have to worry about making your data fit within the 8-byte data frame or dividing and reassembling data frames. Sending data to another Teensy over RS-485 is just as easy as outputting something to the serial console. A checksum byte can easily be added to increase transmission reliability.

In its basic form it also requires only a very simple scheduling routine, e.g. one master Teensy that queries the other slave Teensies in a round robin fashion. If you want more complex features, there are several Modbus libraries that work with Teensy that incorporate CRC and error handling.

For situations where this master-slave topology isn't suitable, e.g. if each Teensy should be able to initiate communication, I would probably use CAN too. It will depend on OPs specific use case.
 
Last edited:
Thanks a lot for all the input. Different instrument modules are going to be up to 2 meters (6 ft) apart from the main module. I agree that with Epyon that RS-485 would offer most flexibility and I will look into suitable modules that go from RS-232 to RS-485. Thanks for the tip that Teensy LC doesn't have CAN and that additional hardware is also needed for using that. I also like MichaelMeissner idea of doing multi drop serial or even using Teensy 3.6 and designating one serial port to each module.

If I decide to use RS-232 do you think I will need to use a level shifter (MAX3232) or can I just send 0-3.3V signal straight out of teensy between different modules up to 2 meters. There should be much interference from other devices since it is all mostly low current.



Thanks a lot for all the input once again,
George
 
2 meters is pretty far for I2C. It might work, but not recommended. RS-485 is great for long distance. Managing half duplex does require some code, but at least you can use Serial1.transmitEnable(pin) to take care of the tricky part. Usually the code is pretty simple if you implement a master-slave protocol. If you want a peer-to-peer network, RS-485 gets complicated. CAN is definitely best if you can't designate one device to always be the master and all slaves only transmit upon receiving a message sent to their address.
 
Thanks a lot for all the input. Different instrument modules are going to be up to 2 meters (6 ft) apart from the main module. I agree that with Epyon that RS-485 would offer most flexibility and I will look into suitable modules that go from RS-232 to RS-485. Thanks for the tip that Teensy LC doesn't have CAN and that additional hardware is also needed for using that. I also like MichaelMeissner idea of doing multi drop serial or even using Teensy 3.6 and designating one serial port to each module.

If I decide to use RS-232 do you think I will need to use a level shifter (MAX3232) or can I just send 0-3.3V signal straight out of teensy between different modules up to 2 meters. There should be much interference from other devices since it is all mostly low current.
Not sure why you are referring to RS-232? RS-232 has quite complex signal levels and does not support multi-drop. RS-485 is easy and multi-drop, allowing multiple devices on the same bus (RS-232 only allows two devices).

Just sending TTL UART might work on low speeds and with not much interference around, but from a reliability point of view I wouldn't recommend it.
 
Would you recommend using TTL UART for high speed (2Mb/s +) if all devices are located on same PCB.
For example one teensy3.6 or 3.2 TX pin connected to multiple teensylc RX pins.

What is the limit to the number of RX teensylc's I could use?

Thanks.
 
It would certainly be the most straightforward in both coding and electrical design. There are some catches to using higher baud rates though, see this page (scroll down to usable baud rates).

There isn't any real limit to the amount of receivers, it will be limited by how many receivers you can fit on a limited PCB. That is implying that only one Teensy will be master (sending), and all the rest slaves (receiving).
 
Unless you design your code *very* carefully, especially on the slower Teensy LC boards, running at such a high baud rate usually requires RTS/CTS flow control. The small receive buffer can fill up very rapidly at those speeds, which means you risk losing incoming bytes (without flow control) if your program isn't always able *always* avoid delays before it reads the incoming data.

Normally hardware flow control is only done between 2 devices. I suppose you could build digital logic circuitry to combine the RTS outputs from all the receivers to a single CTS signal for the transmitter, so that it doesn't send data until all the receiving devices are able to receive.
 
if your talking same PCB, you can try out a new library in development called SPI_MSTransfer, not sure if it’s capable of LC models though (for slave code) would have to be tested, but currently 3.2/3.5 and 3.6 can run slave while you can use any other teensy for master, and you wont be limited to 2MBit uart speeds, your only limitation would be FBUS, but most people using the library are using 30MHz SPI and the best part is, you wouldnt need to handle data between them in a serialized fashion, both sides have callbacks and both can send arrays to each other at incredible speeds
 
Epyon: Thanks. I see 2Mbit is pushing it for lc. I hadn't looked at this.
PaulStoffregen:I'm thinking small amounts of data but I want it delivered instantly. I've did this last time with no flow control by ensuring my loop time is less than it takes to fill my buffer. I think combined RTS->CTS idea will be usefull in the future.
tonton81: This sounds promising. Thanks.
 
if your talking same PCB, you can try out a new library in development called SPI_MSTransfer, not sure if it’s capable of LC models though (for slave code) would have to be tested, but currently 3.2/3.5 and 3.6 can run slave while you can use any other teensy for master, and you wont be limited to 2MBit uart speeds, your only limitation would be FBUS, but most people using the library are using 30MHz SPI and the best part is, you wouldnt need to handle data between them in a serialized fashion, both sides have callbacks and both can send arrays to each other at incredible speeds

tonton81 - I already posted the LC cannot be Slave with its alternate register layout differing from the T_3.x hardcoding as done.
 
Sounds like I should add LC support, I should order some LCs for testing, but he did mention 3.X’s as well

EDIT, I just ordered 5 from robotshop, should get it probably my monday/tuesday
 
I did a quick test using 3.2 -> 3.2 and it was suitable for my needs however I haven't gone any further with it.
 
Status
Not open for further replies.
Back
Top