> 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
overhead.)
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/faq.html