1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Multimaster vs Polled I2C Throughput, Good Implementations?

Discussion in 'Embedded' started by Chris Graham, Jan 9, 2005.

  1. Chris Graham

    Chris Graham Guest

    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
     
    Chris Graham, Jan 9, 2005
    #1
    1. Advertisements

  2. 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, Jan 9, 2005
    #2
    1. Advertisements

  3. Chris Graham

    bithead Guest

    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.
     
    bithead, Jan 9, 2005
    #3
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.