Messages in this thread | | | Date | Wed, 9 Sep 1998 12:55:56 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: [offtopic] Re: I2c was: Cobalt Micro (was Re: Build your own Mo therboards) |
| |
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.
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.
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.
Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.1.118 on an i586 machine (66.15 BogoMips). Warning : It's hard to remain at the trailing edge of technology.
- 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
| |