Method for full-duplex a large number of slaves

Thread Starter

philm01

Joined Mar 22, 2014
37
Hello all,

I have an application where I need to have half-duplex over 100+ slaves. I will only be having 1 master in this application. Right now, I am looking at implementing CAN, SPI, or I2C.

I am leaning more towards I2C because I can use an 8 bit address to address 255 different devices on a single bus. If I have multiple I2C buses, then I think that I can work with a 7-bit addressing scheme. (I will not be needing more then 255 addresses). Additionally, I would be using a I2C line buffer since I have many devices on the bus line. The devices will be placed fairly close to each other. No more then 1 meter from the master.

However, I want to turn to the community to see if anyone might have additional suggestions in implementing something such as this? If I2C is the best protocol to go with or if there is something else out there that I can use?

Thank you
 
Last edited:

JohnInTX

Joined Jun 26, 2012
4,564
I think you mean half-duplex? Full-duplex means that data goes both ways at the same time, something that I2C and CAN don't do.
That said, I'd probably lean towards I2C. SPI would require one CE/ for each slave meaning lots of IO. CAN is great when you need extremely robust multi-master communications with built in error-checking and retry but is more complex and expensive to implement. Based on your description, it might be overkill.

Keep in mind that I2C addressing uses 7 or 10 bits. 7 bit addressing gives you 127 addresses with some usually reserved. Maybe you could get along with one bus. If not, perhaps you could bank the 7 bit slaves using one of the external address pins on the chips. Many slaves use a block of addresses for internal registers so you might not be able to use 100+ actual chips on a 7 bit bus. I'm speculating here since I don't know what your slaves are.

While I2C provides a pretty good physical layer for short haul use, it doesn't provide any standardized method to ensure that the data has been transferred without errors. If that's important, you'll have to incorporate error-checking/correction/retries/bus monitoring etc. in your higher level protocol. The more expensive CAN does this all for you.

Hope that helps. If you let us know what kind of slaves you are using and something about the application we can discuss it in more detail.
 

ebp

Joined Feb 8, 2018
2,332
The I2C spec puts a limit of 400 pF on the capacitance on the bus. It is possible that 100 slaves on a single bus would exceed this when the capacitances of all the devices plus the interconnect is considered. Two buses might be necessary. I've never paid much attention to this issue since I've never put more than a few slaves on a bus, but I have seen SDA capacitance specs of up to 4 or 5 pF per device.

Lots of slave devices only have 3 or 4 address select lines, and as John has said, may use a block of addresses internally. Some devices can be purchased in variants with different "built in" addresses.
eg from one datasheet
The MAX7328 and MAX7329 versions differ only by their
slave ID address ranges. The MAX7328 has a slave ID
range of 0100xxx (0x20 to 0x27). The MAX7329 has a
slave ID range of 0111xxx (0x38 to 0x3F).
 

atferrari

Joined Jan 6, 2004
4,443
I presume that being just one master, it will be full duplex with just one slave at a time. So selecting the desired slave every time. Right?
 

John P

Joined Oct 14, 2008
1,914
It doesn't sound as though this can possibly be full duplex.

Assuming half duplex is intended, I think there's an issue with 100+ units on the same bus. It's a question of how many loads can all be connected together in parallel, and it depends on the interface components and anything else that's on the bus, though at least this is very short (1 meter max). Actually, given how close everything is together, I wonder if so many devices are really needed. Could the project work if there were fewer units, each doing more tasks? Over 100 devices within 1 meter of space makes me think it could be simplified.
 

Picbuster

Joined Dec 2, 2013
1,027
Hello all,

I have an application where I need to have full-duplex over 100+ slaves. I will only be having 1 master in this application. Right now, I am looking at implementing CAN, SPI, or I2C.

I am leaning more towards I2C because I can use an 8 bit address to address 255 different devices on a single bus. If I have multiple I2C buses, then I think that I can work with a 7-bit addressing scheme. (I will not be needing more then 255 addresses). Additionally, I would be using a I2C line buffer since I have many devices on the bus line. The devices will be placed fairly close to each other. No more then 1 meter from the master.

However, I want to turn to the community to see if anyone might have additional suggestions in implementing something such as this? If I2C is the best protocol to go with or if there is something else out there that I can use?

Thank you
The application is important to select a protocol (hw and sw).
Speed, interrupt, addressing sequence and fail detection are the main keys to make a decision.
Full duplex put you into software trouble when all devices start screaming for a service.
A very common method is half duplex master will ask slave and slave will answer.
When answer is not received within x time it will signal an error an be placed on a slow poll.

The used mechanism is not important and is defined by the hardware capabilities like speed and software integration.(interrupt driven or not)
Open Can could be an overkill in your application.
i2c is low level and a protocol has to be written.( fairly simple to build a half duplex protocol)
But distance 1m looks short but you need the i2c drivers to avoid wires direct connected to mcu.
This will bring you to RS485 chips and use the serial (async) from cpu advantage distance never an issue.
No significance price difference speed up to the maximum from mpu / slave number of addresses what ever you want. Defined in your software. Use the same communication protocol as used for i2c.

Picbuster
 

Thread Starter

philm01

Joined Mar 22, 2014
37
Hello all,

thank you for your replies. After additional review of the requirements. Doing Half-duplex is acceptable. So I will be utilizing this in the application. This should also simplify the overall design.

The slaves will be a other microcontrollers that I will be programming so I can customize it as much as I want.

Concerning the line buffer, I am currently looking at this part from NXP:

https://www.nxp.com/products/analog...aters-hubs-extenders/i2c-bus-extender:P82B715
 

ebp

Joined Feb 8, 2018
2,332
A possible fairly serious consideration is that I2C is "single ended" - the clock and data logic 0 and 1 are voltages with reference to circuit common ("ground"). With a large number of devices, especially if there is additional current from load control circuitry, much less actual load current, there is a possibility of significant voltage difference, both static and dynamic, in the ground path between the ends of the bus. This can cause signal integrity problems. Care will be required to analyze this and design to minimize it. Keeping the current for the solenoids out of the signal ground path will likely be imperative, which might mean using opto isolated drivers and completely separate power and ground distribution. Of course if the solenoids operate at AC mains voltage, isolation will be required in any case. Electromechanical relays could be used, but relay coil currents will likely be significantly higher than optocoupler or solid state relay input currents.
 

John P

Joined Oct 14, 2008
1,914
It might be the case that an object carrying an RFID tag is presented to one out of the array of sensors, but only one object arrives at once and only one solenoid needs to be activated. If that were true, it might simplify things. On the other hand, if multiple objects can trigger multiple RFID readers at the same time, then it gets harder. But if the RFID readers are the type that send out a character packet at 9600Bd in response to a trigger event, it should be possible to get several of them connected to a single microcontroller.
 
Top