This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Part Number: PCA9518

Hi,

A bit of a challenge here:

I am trying to design a large tree topology network based on low-cost components and good community support. I2C seems generally good for the last two aspects.

Ideally, a large number of hubs would be daisy-chained, resulting in a large tree structure. After each hub, the only slave device in this segment is the next hub. So it is rather point-to-point than a bus. The slave modules will be designed in the same project. I envisage addressing them by a broadcast call to all and using a proprietary addressing system in the sent data, in order to be able to address >112 devices. On each slave module, ideally up to 14 I2C connections would be available (yes, a massive tree structure). 

If the problem is not clear, I can include some sketches.

It seems however that the hubs, for instance PCA9518, produce signal quality that depends on their incoming signal, and can therefore not be daisy chained. When the incoming signal has been degraded by a previous hub in the tree structure, at some point the outgoing signal will not be readable for the next module/hub.

Therefore, I am looking for a cheap and fast solution to recreate the original signal quality with each hub, so I do not get degradation with the large number of hubs involved. It is possible to limit the number of connected slaves in one network segment to only one - the next hub. Furthermore, the distances between the modules are short (ca. 20cm with one connector in between)

The solution I can think of at the moment is using an inexpensive microprocessor at each slave module supporting I2C as a repeater, recreating I2C signals with original quality. These signals then go into PCA9518 hub(s) on the module, and from there on to the next modules, which do the same.

The problem is that this bit-banging solution would probably be quite slow. 

So, is there any simpler, faster possibility to re-create clean, original signal quality with multiple chained hubs? Maybe by combining a I2C repeater IC with PCA9518 hub ICs?

Or should I forget I2C and use bit-banging or hubs with other interfaces possibly geared towards point-to-point connections, such as serdes, serial backplate buses, ieee1394 or CAN? Or is it worth programming FGPAs for the task? 

It might be an unusual question, but any help would be very much appreciated, as it is a basic conceptual question for the project.

Best regards,

Christoph

  • 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

  • Cristoph,

    I don't think I perfectly understand your first question regarding number of transceivers on branches versus tree segments, but in general you would need a transceiver at every node (to convert logic-level data from an MCU to bus signaling) but only a few repeater nodes (only as many as are needed to prevent any given segment from going over a maximum number of nodes supported by the chosen transceiver).

    Changing the architecture to multi-master does change some things, though. RS-485 is not set up well as a physical layer to support collision detection or arbitration (although you may be able to come up with a solution that works well enough for your application). For this CAN would be a more natural choice. The challenges then would be reducing the signaling rate, since CAN is only intended for signaling rates of up to 1 Mbps (for "classical" CAN) or ~5 Mbps (for the newer "flexible data rate" or FD CAN). Some CAN transceivers can support up to 100 nodes on a network (provided that the cabling itself can support that), but you would still need some hub or gateway nodes.

    Here is an excellent introduction to CAN:

    www.ti.com/.../slla270.pdf

    Let me know what further questions you have.

    Regards,
    Max