[lkml]   [1998]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [offtopic] Re: I2c was: Cobalt Micro (was Re: Build your own Mo therboards)
    On Wed, 9 Sep 1998, Richard B. Johnson wrote:

    > On Wed, 9 Sep 1998, Daniel Engstrom wrote:
    > > On 8 Sep, David Lang wrote:
    > >
    > > > it arbitrates the but by listening to the bus as it transmits, if it hears
    > > > something different then it is transmitting it stops transmitting and the
    > > > other station continues (the first thing it transmits is it's own id # and
    > > > the node with more 1 bits in it's address will win as it will transmit a 1
    > > > while the other node transmits a 0, the 1 will make it on the bus and the
    > > > other node will stop)
    > >
    > > That would be a CAN bus arbitration....
    > > Or maybe I2C uses the same method...
    > >
    > > /Daniel
    > The IIC bus has no arbitration capability at all. One checks a busy
    > bit to see if it is ready. If not busy, one sends data (address first).
    > The receiving machine ACKs every bus state change.
    > Since two (or more) parties can think the bus is free at the same time,
    > clashes are possible. This will hang the IIC bus. Therefore, once the
    > bus is crashed, both parties have to reinitialize their controllers to
    > make the bus free. Since the possibility exists that both parties will
    > detect a crashed bus at the same time, and attempt to reinitialize the
    > bus at the same time, deadlocks can (read will) occur.
    > Therefore, everybody on the bus has to use a pseudo-random back-off-time to
    > resolve deadlocks.

    Eh? Are we talking about $I^{2}C$? It sounds like you are talking about
    Ethernet. I could have sworn that I remembered I2C being a clocked
    tri-state bus (or whatever the correct terminology is), with automatic
    backoff (multiple devices can start transmitting at once: the first one to
    notice the bus differing from what it is sending simply stops
    transmitting. The bus is unharmed by this, and one message is guaranteed
    to go though. The devices that backed off start again after the mssage is
    complete, just as David Lang was describing). There is no exponential
    backoff, no bus crashing, no deadlocks, etc. I always thought it was an
    quite elegant bus, to be honest.

    > Further, since everything is done in software, fast machines can send
    > data faster than slow machines can receive it. This means the fast
    > machine must artificially slow down data transmission to match the
    > slowest receiver.

    Um, I can't think of any bus on which this isn't the case... And remember
    that I2C is often used in embedded designs (read: quick'n'dirty hacks), so
    a few timing constraints are nothing much to worry about.

    > This is an awful bus in all respects. It was a way to make (free) software
    > replace (non-free) hardware. I have assembly-language source-code (Intel
    > real-mode) if anybody is interested.

    Why in heavens name would one want to do anything with I2C, unless you
    have specific hardware that uses it? I can't see any rational reason for a
    Linux driver, unless someone felt a burning need to teach the parallel
    port how to speak I2C (and I don't want to think about the polling

    Kenneth Albanowski (, CIS: 70705,126)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.023 / U:0.496 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site