PCA9518: Daisy chaining of I2C (or other) hubs for multiple point - to - point connections creating a large tree network

Hello Christoph,
Large networks like this are done all the time for I2C, but it is a relatively slow protocol because it is an open drain architecture. I2C is an inexpensive, simple and robust communications protocol. What types of slave devices are you proposing to connect to and how fast to you have to communicate. What exactly do you mean by "network". Please provide me more information about your application.
-Francis Houde

Dear Francis,

Thanks for answering my post.

You find the requirements below. After calculating the necessary bandwidth, I am not sure if I2C is the right solution. It would help me to be directed to suitable interface solutions and related TI ICs, applications notes or other literature. Maybe I am overlooking something or some information is missing, I can provide that shortly.

I am looking for data transfer & interfacing solutions to implement the following highly reconfigurable tree bus design:

Up to 1000 identical hub modules can be connected by circuit-board mounted connectors in different configurations. Each module can hold a total of 8 connections. Maximum tree depth (modules connected in series) is 300. On each module, a local µC listens to the bus, reads in any packets that are addressed to it, and processes them. I imagine all packets sent to all modules, with 10-bit addressing (up to 1024 slaves) The components on each module should cost around USD2-3, of which the µC would take around USD1.

Please see below a scheme of the tree structure.

###

One module, the root of the tree, is connected to a microprocessor that receives, processes and distributes data from and to all of the modules of the tree structure.

The connection is bi-directional, but the data transferred from the main microcontroller (tree root) to the modules in the tree is much higher than the data transferred from the modules to the main microcontroller.

Let us start with the data transferred from the main controller to the tree modules:

Within a “frame” of about 10ms, the central microprocessor needs to distribute about 30 bytes of data to each of the modules.

As the modules are identical and can be reconfigured freely, it is possible to connect 300 modules in a line. This means, the bandwidth and hub delays of each connection needs to be able to sustain the complete data throughput for all 1000 modules.

That is, a throughput of 1000modules x 30 bytes plus addressing, error checking bytes etc. = around 40kbytes of data per 10ms, meaning 4 Mbytes / sec., including hub delays.

As the tree depth is approximately 300, this means the available time to transfer 40kbytes from the input to the 1-7 output(s) of a module is around 33µsec (10ms / 300 modules depth). During this time, all the data has to be checked as well to see if there is a packet addressed to the current module. This packet’s data is then processed by a local µC.

If I assume the hub delays should account for half of the available 33 µsec, and the data flow between modules can take up the other time,

• The necessary bandwidth is around 8 Mbytes / sec
• Each hub can have a delay of around 17 µs.

Of course, if the hubs are faster, I can get along with a smaller bandwidth and vice versa.

Due to the large number of modules that can be daisy-chained (up to 300), the signal quality of the outgoing signal should probably not have any deterioration compared to the input signal. 

The distance from input to output connection is approximately 20 cm / 8 inches. The number of electrical connections could be more than two wires if necessary, but a serial connection would be preferred to a parallel one, as there will be many connectors and their reliability will be critical.

Now for the data transfer from the tree modules to the main tree node µC: A maximum of 100 single modules will send data to the main microcontroller during each frame of 10ms, packet size will only be 4 bytes, resulting in a bandwidth of 40 kbytes including hub delays.

Currently, I can think of several solutions to reach the necessary speed. Please compare the figures below:

• Use a standard bus protocol and standard hub components with the necessary speed. The local µC is connected using an integrated bus interface. However, it seems that usual buses such as I2C, CAN, do not provide the necessary bandwidth. Ethernet seems too expensive with µCs with only 1 or 2 ports at USD 2-3 already. (see Alternative 1 below)
• Use point-to-point connections, and a FPGA that does the work of a hub and checks if a packet is addressed to the current module. That packet is then transferred to the local µC (Alternative 2).
• Use point-to-point connection and the local µC to receive, process and output the data to the connected modules down the tree using
  • Its I/O pins
  • Or separate transceiver ICs, for instance with SERDES functionality
  • (Alternative 3)
• Make subsections of the tree so that signal quality is sufficient within the segment, and use a standard bus inside that segment. As the tree is reconfigurable, the segments would need to be re-configured as well when connections are changed. The limits of the segments would need to be detected depending on the configuration. This seems quite complicated to realize, therefore I am not convinced of that solution. (Therefore  no figure)

Alternative 1:

Alternative 2:

Alternative 3:

As the data rate in both directions is so different, I wonder if it makes any sense to use two unidirectional connections with different speeds rather than one bi-directional one.

Any ideas for solutions are highly appreciated. If a lower but comparable transfer rate (down to 1/4 of the figures mentioned here) can be reached with much simpler means, this is also interesting for me.

Thank you and best regards,

Christoph

 

Hi Christoph,

Have you considered using RS-485 as bus interface among these nodes? Many modern RS-485 transceivers are specified to support as many as 256 nodes on a common differential bus, and data rates can go as high as ~50 Mbps. It sounds like a single bus would not be possible (given that your node count can be as high as 1000), but if there is an MCU on each module is should be relatively straightforward to delineate the bus into different segments and use the MCUs (or even simple repeater circuits) to bridge between them.

Here is a brief overview of the standard that can serve as an introduction if you are unfamiliar:

www.ti.com/.../slla070d.pdf

Best regards,
Max

Dear Max,

Thanks for your reply. I appreciate that you reply even if the request is probably a bit unusual.

RS485 sounds interesting. I have found several transceivers in your product range. I would like to ask if any of these are capable of acting as a bus master on one side, receiving data from several slaves (8 in fact) and on the other side, being able to pass this data on as one of several  slaves in the next bus segment. Illustration below:

 

Is there a limit to the number of "daisy-chained" transceivers? Ideally, I am looking for transceivers that are re-generating the signal in a way that there isn't any signal degradation.   

Regarding number of nodes: I understand that RS485 is an electrical protocol and the addressing scheme is implemented in a software protocol such as Modbus. With above drawn setup, it should therefore be possible to address an arbitrary number of nodes in the overall bus structure (>256)?

If there is no such type of transceiver, I will need some information about alternatives, for instance using ARM processors with 2 RS485 connections. I fear it is going to be complicated to reach a high data throughput (up to 50 Mbps) and low delay using a µC, but maybe I'm wrong.

If there is some application note about daisy-chaining transceivers or creating deep tree topologies (especially for RS485), I'd be quite interested as well of course.

Thank you and best regards

Christoph

Hi Christoph,

Yes, you are right that you could address any number of nodes as long as the software protocol can support it - RS-485 as a standard solely covers aspects of electrical signaling and not data protocol.

If you have a protocol able to support such a deep tree and just need transceivers to act as repeaters to resolve physical signaling limitations, it is possible to construct a repeater or fan-out circuit . Here is an example of a 1:4 fan-out hub:

www.ti.com/.../TIDA-01365

This approach allows for heirarchical networks to communicate using bi-directional, half-duplex signaling lines. (Basically, the trick is to control the driver/receiver enable controls appropriately based on whether data is flowing up-tree or down-tree. Half-duplex networks like this need to make sure that only one transmitter is active at a given time on a given signaling line to avoid corruption of data.)

Some limitations to consider would be the amount of "overhead" timing that would be needed. For example, if each slave only transmits after a request from a master, these requests would need to propagate through several repeaters to every slave. Similarly, the responses back would need to make their way to each node. The propagation delays themselves are typically fairly short (unless long cables are used), but if there is overhead added on each message to signal the start of a transmission, end of transmission, and wait some period between transmissions then this could all begin to add up and limit total throughput. You may be able to optimize this via protocol, though, for example by using sequential addressing on the slaves and reading from several of them with a single request from a master.

Max

Dear Max,

thank you for the explanation. I will look into that in more detail, it could be what I am looking for. I just need to understand if I need one transceiver per tree segment, or one transceiver per branch (that would be 8 per tree segment, as I have 8 connections to each tree node). If it is 8, it will probably be too expensive (I saw prices of around USD1 per transceiver). In that case, I will need to see if something like the fan-out hub can be realized by less components, for instance one fpga or one microcontroller or similar. I just fear that would impact the throughput.

A few additional questions though:

In fact, the two directions could be separated, as the data flow in both directions is independent (sorry I did not mention this before): In my application, the slaves will need to send data whenever their sensors capture an event. I guess they cannot be referred as slaves in that case, but rather as multiple bus masters? Still, the data from these bus users only needs to be read and processed at the tree root (no addressing necessary). On the other hand, data sent by the master (tree root) will not require a reply by the bus users in the tree, but needs to be addressed to individual recipients. No acknowledging is necessary. 

I understand that I have to realize some kind of bus arbitration / collision detection in case a bus user wants to send data while another one is currently sending. I guess I need to look into bus protocol algorithms. I am happy to hear any comments to that.

In order not to complicate things unnecessarily, I am also pursuing a different approach in parallel: To limit the bandwidth by putting more intelligence into the slave modules. This way, I should be able to use buses with lower bandwidth than RS485, for instance, I2C or CAN bus. With lower bandwidth, would you still recommend to use RS485, or is a different bus more suitable to realize such a deep tree topology, for instance because hubs exist as IC? With I2C, I did not find cascadable hubs though. Related to that, would it help to realize two separate, unidirectional buses instead of one bi-directional one?   

Thanks and best regards,

Christoph