how many i2c devices (fanout) can be on a single i2c bus of Teensy 3.1?

Status
Not open for further replies.

RichardFerraro

Well-known member
I would like to hook up 16 Teensy 3.1's on a single i2c bus.

Does anyone know how many devices can sit on a single i2c bus to function (presuming optimal pullup resistors) ?

Alternatively, I could rely on the other i2c channel (pins 29/30) to halve the load, but would rather not.

thanks,

Richard
 
I've seen two i2c related products recently. I haven't used them myself, but they may help if you are running into limits:

1) On tindie, these devices allow you to separate i2c devices to be much further apart, using ethernet cables (it didn't say cat 5 or cat 6):

2) Adafruit is selling an i2c multiplexer to allow connecting up to 8 different i2c buses. I suspect (but don't know) this may help if you but 2 teensies per bus, rather than having all 16 on the same bus: https://www.adafruit.com/product/2717
 
This onehorse item allows multiplexing 8 devices - for when they are duplicate devices with the same address perhaps not relevant to this situation. Would allow setting up multiple independent bus groupings if they won't co-exist en-mass.

You could alter the topology perhaps with one master talking to two as slaves - that talk to two each as master - that gets 7 talking - repeat that once and you have eight more. You'd have to ripple the data up and down the chain but each bus would have less load and contention over address changes. You didn't mention anything about the application of time constraints or data mass involved.

<edit>: onehorse link missing: https://www.tindie.com/products/onehorse/tca9548a-i2c-multiplexer/
 
Last edited:
This onehorse item allows multiplexing 8 devices - for when they are duplicate devices with the same address perhaps not relevant to this situation. Would allow setting up multiple independent bus groupings if they won't co-exist en-mass.

I forgot about that. It's hard to remember all of the different boards he has produced. My thought with the i2c multiplexer that it may allow for less bus contention even if you are not worried about address contention, since at any given time, you only have 3 or 4 devices on the bus, instead of 17. Also, the total cable length in theory should only include the devices on the bus selected.

However, note, I am a software guy, and the above is based on my vague understanding on how devices work.
 
Another alternative if you don't mind some external chips (transceivers) or breakouts is utilizing the CAN bus between all the Teensy 3.1's; those 'extenders' are actually using CAN signalling and are fairly expensive because they have the I2C<->CAN logic onboard and bulky due to the ethernet jacks; using CAN directly on the Teensy you'd only need the CAN transceivers (and requisite sub-components) which are only a couple of bucks by comparison along with the required bits-and-bobs (resistor and capacitor generally, check the datasheet) they require:

DigiKey Product Search > Integrated Circuits (ICs) > Interface - Drivers, Receivers, Transceivers -> Protocol: CAN
 
There are generally 2 limitations to connecting a lot of I2C devices.

#1: The total capacitance and pullup resistance limit the speed of rising edges. Slower clock speeds and lower value resistors allow more capacitance, but you probably should not use less than 1K resistors.

#2: Ground shift between devices can add error to the logic thresholds. The may not be an issue, or it could become a big problem if the Teensys or other I2C chips are controlling high power stuff, which causes excessive ground currents.
 
The first question is whether the I2C address of the Teensy can actually be changed.
If so you can have 100+ devices on an i2C bus. The address space of the I2C bus is 7 bit so 128 but some are reserved and should not be used.

If not you need additional electronics anyway and I'd actually use RS485.
 
The first question is whether the I2C address of the Teensy can actually be changed.

Yes, of course it can! Just use Wire.begin(address) to listen on a specific address.

If not you need additional electronics anyway and I'd actually use RS485.

Indeed RS485 is vastly superior if you need long cables and reliance to a few volts of ground shift. There's a reason it's pretty much the standard for industrial and building control networks and stage lighting.

The good news for RS485 is Teensyduino has a tranmitterEnable(pin) function on its hardware serial objects, which makes controlling RS485 chips much simpler!
 
Last edited:
I did think so but have never had the need to try. So a lot of the replies above are informative but don't address the problem at hand. That actually takes a little nore detail form the OP.

How far are these Teensys going to be apart. A few inches, or a couple of feet ?

The advantage of I2C is that there is no need to use a seperate protocol as that is part of the I2C bus spec. , which can be convenient.
The distance between I2C devices can be increased by using a bus extender/buffer. The PCA9600 has worked very reliably in my applications and allows up to 1MHz of I2C bus fequency. I2C is a good choice when only one of the devices on the bus actuallly has processing power.E.g. a system in which multiple "dumb" sensors are attached to a microcontroller.

If each node on the bus has enough processing power - Teesnys certainly do - than RS485 has the advantage of being much more robust electrically. However there is propably more coding work needed as RS485 is an electrical spec. only and does not describe an actual protocol. A user either has to implement their own or use an existing implementation, such as modbus.
 
I can only add that I routinely design single boards with five or six i2C devices on them and have never had a problem with I2C communications when properly assembled. But this is not 16 devices and they are on the same board, not a meter part!
 
Thanks all for the great info. My network currently has 16 teensy 3.1s each on their own battery and each driving a 2amp draw led panel (thus to Paul's comment, there could be ground drift). For my test system, they are configured in a 4x4 grid at a 13.5" spacing (so figure about 2 feet between each. Mine are currently networked through xbee series 2. This is the endgame, but I thought a hardwired test bed would be nice and i2c sounded pretty good. Sparkfun says "32 devices to communicate through the same data line over a cable length of up to 4000ft with a maximum data rate of 10Mbit/s." I will look into this further.

thanks again,

Richard
 
32 devices, 4000 feet and up to 10 Mbit/sec sounds like the RS485 spec.

But even those are not all achievable simultaneously with RS485. This sounds like typical overly-optimistic marketing written by non-engineering people who don't actually understand the technology at all (perhaps not even well enough to get the protocol name correct).

For example, from Linear Tech's "RS485 Quick Guide" document:

rs485.png
 
Status
Not open for further replies.
Back
Top