Multimaster vs Polled I2C Throughput, Good Implementations?

I'm considering whether to use a polled vs multimaster I2C network to connect a main controller to a few subsystems (in the same box). I propose to use a standard interface such as I2C because I need the flexibility to mix and match (my custom-made) modules in various configurations. I also need to maximize throughput, and keep latency reasonable.

Am I better off polling, which costs some bandwidth for the poll messages, or am I better off making the low latency devices masters and transmitting when needed. How much does throughput suffer due to multiples masters contending for the bus? Also to manage latency, I assume I would have to keep all transmissions short since there is no way of interrupting a transfer.

Another question: Can anyone comment on the quality of the I2C (or SMBUS) hardware inplementation in Atmel and Cygnal microcontrollers? Any brands of microcontrollers to avoid?

Note: I've also considered the CAN protocol which is more suitable in some ways, but it seems like overkill to connect a few local devices, and further limits the choice of microcontrollers.

- Chris

Reply to
Chris Graham
Loading thread data ...

"Chris Graham" wrote in

There is no general answer to this question.

You will have to calculate your worst case latency and service requirements for several different systems. Then you will need to estimate the software overhead for both polling and multi-master and calculate collision frequencies.

If you can you are better off with a single-master system: much simpler and deterministic. Calculate if you can live with polling, if so then I would go that way and not look back.

I do not know what your system is like. If message size and inter- arrival times are variable you may need to investigate queuing theory. In general the average communication load should not exceed ~1/3 of peak load.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Reply to
Nicholas O. Lindan

Be careful of the devices you choose. The PIC16F876 will only clock stretch on transmit, not receive. This limits the entire systems maximum clock rate to PICs ability. Supposedly the PIC16F876a fixed that problem, and now clock stretches on both TX and RX.

IMO, I2C is a pain in the rear to implement compared to UART based communications. If you plan on doing multi-master I2C arbitration, double the pain factor.

If you can find a high baud rate that all your modules can co-exist happily consider going with RS232 or RS485. Go I2C only when you have no other choice.

Reply to
bithead

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.