I'm working on a project where I read data from a bunch of sensors and save it to an SD card at 1000Hz. That parts working great, but I need to be able to transmit the data that I'm saving to the SD card to a second teensy 4.1 that can handle wireless communications, rpm calculations, etc, etc. Is there some way I could tell the first teensy to just send a duplicate of the packet over a data line to the other teensy? I've never made two teensys talk to each other before, so I could use a decent bit of help/explanation here. Thanks in advance!
Teensy to Teensy Communication
- Thread starter nAnd
- Start date
defragster
Senior Member+
Simple two wire - if nearby - would be GND and sending Teensy UART Tx connected to Rx on a UART with same baud rate settings.
2Mbaud should be reliable and give most of 200KB/sec or 200 bytes for each 1KHz sample? 2Mbaud should be reliable and might run at 4 or 5 max if data per sample required it. Tx could send as data ready and Rx would need enough buffer to handle any delay in processing it. Second UART wire for return data could be added for feedback from second Teensy.
2Mbaud should be reliable and give most of 200KB/sec or 200 bytes for each 1KHz sample? 2Mbaud should be reliable and might run at 4 or 5 max if data per sample required it. Tx could send as data ready and Rx would need enough buffer to handle any delay in processing it. Second UART wire for return data could be added for feedback from second Teensy.
Last edited:
It depends on the required data rate and distance.
As @defragster indicated, serial / UART is simple and will work up to 2 MHz Baud giving 200kB/s theoretical max data rate.
Realistically the maximum rate is a little lower, UARTs don't like running at 100% for long periods, especially when you're pushing the speed limits. Slight differences in clock rates cause things to get out of sync if there aren't occasional idle periods. But assuming you're sending a few measurements at a time and aren't at the maximum rate then that's not going to be an issue. The other potential issue would be if there is a large separation between the devices, at those speeds signal integrity could be an issue.
CAN (or CAN-FD if you need > ~0.75Mbit/s of usable data rate) is a second option. This requires external parts but if you add an external CAN driver chip you can get longer distances that serial with better noise immunity. This also allows multi-drop/broadcast type connections if you need the option to add more devices later. Using CAN-FD you could get up to almost 5 Mbits/s data rates.
USB host to USB device is an option. This is going to give you even more data rate but adds a little complexity to the firmware. I'm not sure how out of the box this is, it may just work I don't know. Signal integrity would be critical but USB cables are easy to get so shouldn't be an issue.
And the complete overkill option would be ethernet, give each device a static IP and either open a TCP connection or use a UDP broadcast to transmit the measurements. This gives you a lot more range and data rate while allowing lots of flexibility in terms of future expansion. But it's also going to be the most complex in terms of firmware.
TL : DR - Assuming short distances and <190 bytes per measurement serial/UART is 2 wires (3 for bi-directional data) and is simple to use.
For longer distances, higher data rates or more than 2 devices there are other options, it becomes a capabilities/complexity trade off.
As @defragster indicated, serial / UART is simple and will work up to 2 MHz Baud giving 200kB/s theoretical max data rate.
Realistically the maximum rate is a little lower, UARTs don't like running at 100% for long periods, especially when you're pushing the speed limits. Slight differences in clock rates cause things to get out of sync if there aren't occasional idle periods. But assuming you're sending a few measurements at a time and aren't at the maximum rate then that's not going to be an issue. The other potential issue would be if there is a large separation between the devices, at those speeds signal integrity could be an issue.
CAN (or CAN-FD if you need > ~0.75Mbit/s of usable data rate) is a second option. This requires external parts but if you add an external CAN driver chip you can get longer distances that serial with better noise immunity. This also allows multi-drop/broadcast type connections if you need the option to add more devices later. Using CAN-FD you could get up to almost 5 Mbits/s data rates.
USB host to USB device is an option. This is going to give you even more data rate but adds a little complexity to the firmware. I'm not sure how out of the box this is, it may just work I don't know. Signal integrity would be critical but USB cables are easy to get so shouldn't be an issue.
And the complete overkill option would be ethernet, give each device a static IP and either open a TCP connection or use a UDP broadcast to transmit the measurements. This gives you a lot more range and data rate while allowing lots of flexibility in terms of future expansion. But it's also going to be the most complex in terms of firmware.
TL : DR - Assuming short distances and <190 bytes per measurement serial/UART is 2 wires (3 for bi-directional data) and is simple to use.
For longer distances, higher data rates or more than 2 devices there are other options, it becomes a capabilities/complexity trade off.