One Teensy to communicate to Ten Teensy's

Status
Not open for further replies.
S

Steve01

Active member
Is it possible to have one (master) Teensy communicate to many Teensy's?

I know that the Basic Stamp can emulate a serial port (software) on each pin, so you have 16 serial ports available. I would like to use a Teensy instead.
Using the USB port on the master Teensy makes it perfect but I need to get the data to the other Teensy's.

Also, is it possible to communicate with the other Teensy's and not have to use a Max233 chip?

The project idea is:
Master Teensy listens on USB port for incoming request. Request gets sent to the proper listening Teensy. Listening Teensy is running the OCTOWS2811 lib and is controlling LEDs.

I am using the OCTOWS2811 adapter and I can see that the UART pins 0/1 are available.

Thanks again,
Steve

P.S. I wanted to say that this forum is by far the best one I have used, the people are very helpful and knowledgeable. Thank you to everyone that shares.
 
Well, if the communication between the Teensy's is fairly low bandwidth and the Teensy's are near each other, you could use i2c (pins A4/A5 with 4.7k pull-up resistors). The pins A4/A5 are available on the octows2811 carrier board (pins 18/19). The Teensy's other than the master would need to act as i2c slaves. The Wire begin function takes an optional address argument, which if used, gives the slave i2c address (1..127, with some reserved values). http://www.pjrc.com/teensy/td_libs_Wire.html. Unfortunately the video sync (pin 12) is used, so you wouldn't be able to use SPI.

There is an improved i2c library for Teensy 3.x only that offers additional features, and you can configure faster communications: http://forum.pjrc.com/threads/21680-New-I2C-library-for-Teensy3
 
Last edited:
I2C
or the Teensy3 has 3 UARTs. Connect Teensy's in a ring with daisy-chained UARTs. Message passing -- For an incoming data frame from the UART RX, take it if addressed to me, else pass it on to my neighbor who might want it.

Or use $5 HopeRF wireless radios on the hardware SPI or if that SPI is too busy, use a software SPI. These wireless radios with the RadioHead library can do broadcast to all, or address a specific destination. But the daisy-chained UARTs would be simpler but with a bit higher latency (at 115200 baud).
 
Last edited:
You didn't tell us how elaborate the communication needs to be and didn't tell us any physical challenges of the communication method, like wires need to be 20 feet long, etc.

You do know that PJRC sells a kit for connecting multiple strands of addressable LEDs in a nice weatherproof box with RJ-45 connectors (Ethernet) and has published extensively on how to do exactly this, right? If no one else jumps in, I'll circle back with a link later in the day. Gotta run!
 
pictographer said:
You do know that PJRC sells a kit for connecting multiple strands of addressable LEDs in a nice weatherproof box with RJ-45 connectors (Ethernet) and has published extensively on how to do exactly this, right?
Click to expand...
The OP actually mentioned he/she was using the Octows2811 adapter.

As I said, the adapter does limit things due to the pins that are available for other uses. The pins available are 0/1 (Serial1), 17/A3, 18-19/A4-A5 (i2c), 22/A8 and 23/A9. So, this eliminates using the built-in SPI, Serial2, Serial3, I2S, or CAN ports.

There are 13 additional digital ports available if you solder to the pads underneath the Teensy. On the Teensy 3.1 (but not 3.0), two of those pins provide a second i2c bus (pins 29/30). On both Teensy 3.0 and 3.1, there is an alternate Serial2 port (31/26), but I'm not sure if the library is configured to use it.. There are also 2 (Teensy 3.0) or 3 (Teensy 3.1) additional analog only input ports available as well, but I suspect the analog only pins would not be useful for establishing communication. So if you just wanted a single signal to start each of the Teensy's, you could control 13 slaves. But I suspect if you need to do something like pass information, it will not be as useful, and it might be better to use something like serial or i2c that is well defined.

Like stevech says, if the communication is one way, it would be possible to have all of the slave Teensys read from the serial port (hook the slave's RX to the master's TX, and connect all of the grounds), and have them just skip messages not meant for them. If you need communication back and forth, then it becomes an issue, in that you need to make sure you don't interfere with each other (there are many ways to do this).
 
Last edited:
Thank you all for your input.
Just to elaborate a little more on the project, The communication will be a simple string such as "disco" that gets sent to the master and the master would send that to the appropriate LED controller. The bandwidth will not need to be much, even 9600 would suffice. The distance between controllers will never be more than 15' and most being under 3'.
I like the idea of I2C even though I have never used it. I will look at the examples and try to get it working. If not I2C then I'm positive the UART idea from stevech will work.

With I2C I will still have a working system if one of my controllers goes down, right? With the UART one I will not pass the data if the controller in the chain fails.
 
Steve01 said:
With I2C I will still have a working system if one of my controllers goes down, right? With the UART one I will not pass the data if the controller in the chain fails.
Click to expand...
It depends on what happens when a node goes down. With i2c, it is a passive bus, which means if a Teensy is off-line, but the other Teensys are still connected, they should still be able to communicate. I suspect if a Teensy goes out when it is doing an i2c transaction, it may or may not cause problems. Note, at 15'/5m, you probably need to use i2c repeaters (see the two links in this article, for information about i2c repeaters and longer serial communication: http://forum.arduino.cc/index.php/topic,17007.0.html)

At 15'/5m, I think Wozzy's suggestion about using a mesh network would be the best (presumably using it via the Serial1 pins).

Here is a link I found via a google search on i2c limits: http://www.esacademy.com/en/library...c-bus/frequently-asked-questions/i2c-faq.html
 
You could do RS485 (medium-hard), CAN bus (hard), or
Wire all Teensys' UART RX ports together. Pull-up.
Wire-or all Teensys' UART TX ports together. Using Schottky diode or some such.
Devise a way to send data and error correct when two transmit at once and collide.
Poor man's Ethernet.

Or do the same with the radios I mentioned above, with no new development.
 
I wanted to update on the status and the testing.

I am starting with I2C and so far it has been working good. The controllers communicate on a breadboard with no problem and a 4.7K pullup but when I connected a longer CAT6 wire (16') the 'master would hang.
The 16' wire had a 4.7K pullup on each end and that didn't work, it just froze the controller. I then cut the length of CAT6 down to 10' with the 4.7K still in place and that was working about 50% but when I removed the 4.7K's and replaced with 1K's it is working 100%. So far I've only connected the master and one slave so I'm hoping the next slave will work just fine.
 
 
at 16 ft. you'll need a a proper buffer-chip or equiv. via discrete.
If you need 16', and don't need megabit rates, I2C and SPI are not a good choice.
 
I2C can be used over fairyl long distances when using a buffer chip as some people have already indicated. I have a working, breadboardable design using an NXP PCA9600 . This chip is FM+ specified so works @ I2C bus speeds up to 1MHz. I have tested this for my LED lighting systems on up to 20ft of CAT 5 cable.

However, I am not sure I understand your topology. Do you inted to daisy-chain all the devices or is it more like a star topology where each slave is connected to the master by it's own little cable ?
 
stevech said:
at 16 ft. you'll need a a proper buffer-chip or equiv. via discrete.
If you need 16', and don't need megabit rates, I2C and SPI are not a good choice.
Click to expand...

Agreed. The OP mentioned that the data transmission needs are low, so I2C and SPI would be overkill, potentially difficult to implement, and add (IMO) a lot of programming overhead.

If you can stand having multiple power supplies (distributed around the room with each controller), then some sort of RF connection likely makes the most sense. It minimizes the wiring, allows you to easily reconfigure, etc.

If you'd like to power all MCUs from one spot and communicate on a common bus, I suggest using RS485 on a serial line of choice. Half-duplex is very easy to implement, especially if there is just one master and many slaves. Use ethernet wiring (i.e. CAT5) and use three of the pairs to transmit power, while reserving one of them for the RS485 bus. Very robust, very easy to implement. Just be sure that all attached modules use the same pairs for power and communication or you might have a magic smoke event. Then daisy chain them together and remember (if it's needed) to have a terminating resistor at each end of the bus. What's especially nice about ethernet wiring is that it's cheap, comes in lots of lengths, many colors, is twisted, and can carry quite a bit of power.

Lastly, if the data bits are well defined (i.e. you know full well in advance what is being sent, in what order, etc.) then I heartily recommend the use of EasyTransfer from Bill Porter. It makes serial communications between MCUs really painless, very efficient, and just works. He even has a I2C version of Easy Transfer, but I consider that overkill and likely more trouble than it's worth for this application.
 
Last edited:
I want to thank everyone for offering advice, you all are a tremendous help.
After researching all the links that everyone has offered I have decided to go with the RS485 option since it is very robust and proven. I2C would work but I think when I go to pull all the wires and connect each controller I will begin finding the faults of the system. I found an RS485 converter that will make my life easier. http://yourduino.com/sunshop2/index.php?l=product_detail&p=323.
I'm going to connect all the 'send' and 'rcv' lines in parallel so the master will just send to all the controllers. The site mentioned shows a complete layout of the system and schematics, plus the boards are only $4.50 each.
 
The module has the 120 ohm termination resistor on every board (at least according to the schematic and photo). Not good.

You'll need to de-solder the R7 resistor from the 9 boards in the middle. That resistor is only supposed to be on the 2 boards at the ends of the cable. All the middle ones should NOT have that resistor.

Their connection diagram shows an example with 4 boards, using 2 more 120 ohm resistors at the far ends of the line. If connected that way, you'd need to remove the on-board 120 ohm resistor from all the boards.


Edit: I absolutely agree RS485 is a very reliable way to go. But whoever designed that particular module obviously wasn't paying careful attention to the need for termination resistors only on the 2 ends of the line and NOT in the middle.

They also didn't provide the ground line on the terminal block, only A and B. Ground should be connected to the cable shield at every location.
 
Last edited:
I would only use that RS485 module for prototyping, not for the final "product". For that I'd really use pre-configured, flat CAT5 cable as that can be had dirt cheap and takes the guesswork out of wiring and makes a plug-&-play deal out of it.
Then I'd redesign Paul's OCTOWS2811 adapter board and add the components needed for RS485 communication and two Ethernet sockets for daisy chaining the bus system. That would make a very robust installation electrically as well as mechanically.
 
Status
Not open for further replies.
Back
Top