History of the I2C Bus:
The I2C bus was developed in the early 1980's by Philips Semiconductors.
The original purpose was to provide an easy way to connect a CPU to peripheral chips in a TV-set.
Peripheral devices in embedded systems are often connected to the MCU as memory-mapped I/O devices, using the micro controller's parallel address and data bus.
This results in lots of wiring on the PCB's to route the address and data lines.
Furthermore, lots of control lines increases the disturbances by Electromagnetic Interference (EMI) and Electrostatic Discharge (ESD).
The bus is generally accepted in the industry as a de-facto standard.
The I2C bus has been adopted by several leading chip manufacturers like Xicor, ST Microelectronics, Infineon Technologies, Intel, Texas Instruments, Maxim, Atmel, etc..
The I2C Bus Protocol:
The I2C bus physically consists of 2 active wires and a ground connection.
The active wires, called SDA and SCL, are both bi-directional.
SDA is the Serial Data line.
SCL is the Serial Clock line.
Every device hooked up to the bus has its own unique address, no matter whether it is an MCU, LCD driver, memory, or ASIC.
Each of these chips can act as a receiver and/or transmitter, depending on the functionality of the device.
1. LCD driver is only a receiver.
2. Memory or I/O chip can be both transmitter and receiver.
The I2C bus is a multi-master bus.
Means that more than one IC capable of initiating a data transfer.
The I2C protocol specification states that, one who initiates a data transfer on the bus is considered the Bus Master and all the other Ic’s are slave.
Bus masters are always intelligent Micro controller's.
First, the MCU will issue a START condition. This acts as an 'Attention' signal to all of the connected devices.
All ICs on the bus will listen to the bus for incoming data.
The number of bytes that can be transmitted per transfer is unrestricted.
Then the MCU sends the ADDRESS of the device it wants to access, along with an indication whether the access is a Read or Write flag.
Having received the address, all IC's will compare it with their own address
If it doesn't match, they simply wait until the bus is released by the stop condition of other data transfer.
Each byte has to be followed by an acknowledgement bit.
If the address matches, however, the chip will produce a response called the ACKNOWLEDGE signal.
Once the MCU receives the acknowledge, it can start transmitting or receiving the second DATA.
When all is done, the MCU will issue the STOP condition
This is a signal that the bus has been released and that the connected ICs may expect another transmission to start any moment
The data on the SDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the SCL line is LOW.
The start condition acts as a signal to all connected IC's that something is about to be transmitted (ADDRESS) on the bus. As a result, all connected chips will listen to the bus.
After a message has been completed, a STOP condition is sent.
This is the signal for all devices on the bus that the bus is available again.
If a chip was accessed and has received data during the last transaction, it will now process this information.
A Stop condition ALWAYS denotes the END of a transmission. Even it can be issued in the middle of a transaction or in the middle of a byte, in this case, it disregards the information sent and resumes the "listening state", waiting for a new start condition.
A HIGH to LOW transition on the SDA line while SCL is HIGH is one such unique case. This situation indicates a START condition.
A LOW to HIGH transition on the SDA line while SCL is HIGH defines a STOP condition.
START and STOP conditions are always generated by the master.
Once the start condition has been sent, a byte can be transmitted by the MASTER to the SLAVE
This first byte after a start condition will identify the slave on the bus (address) and will select the mode of operation which is specified by the LSB.
As the I2C bus gained popularity, it was soon discovered that the number of available addresses was too small.
one of the reserved addresses has been allocated to a new task to switch to 10-bit addressing mode.
If there are slaves on the bus that can operate in the extended 10-bit addressing mode, they will ALL respond with an ACK signal to the master.
The second byte that gets transmitted by the master will then be taken in and evaluated against their address.
Note:
Even in 10-bit extended addressing mode, Bit 0 of the first byte after the Start condition determines the slave access mode ('1' = read / '0' = write).
I2C has a master/slave protocol. The master initiates the communication. The sequence of events are:
1. The Master device issues a start condition. This condition informs all the slave devices to listen on the serial data line for instructions.
2. The Master device sends the address of the target slave device and a read/write flag.
3. The Slave device with the matching address responds with an acknowledgement signal.
4. Communication proceeds between the Master and the Slave on the data bus. Both the master and slave can receive or transmit data depending on whether the communication is a read or write. The transmitter sends 8-bits of data to the receiver which replies with a 1-bit acknowledgement.
When the communication is complete, the master issues a stop condition indicating that everything is done.
The I2C bus was originally developed as a multi-master bus. This means that more than one device initiating transfers can be active in the system.
When using only one master on the bus there is no real risk of corrupted data, except if a slave device is malfunctioning or if there is a fault condition involving the SDA / SCL bus lines.
This situation changes with 2 MCU's:
When MCU 1 issues a start condition and sends an address, all slaves will listen (including MCU 2 which at that time is considered a slave as well). If the address does not match the address of CPU 2, this device has to hold back any activity until the bus becomes idle again after a stop condition.
As long as the two MCU's monitor what is going on on the bus (start and stop), there is no problem.
Let's assume one of the MCU's missed the START condition and still thinks the bus is idle.
How can you know if some other device is transmitting on the bus ?
The physical bus setup helps us out.
Since the bus structure is designed in such a way (if one device pulls a line low it stays low), you can test if the bus is idle or occupied.
When a master changes the state of a line to HIGH, it MUST always check that the line really has gone to HIGH.
If it stays low then this is an indication that the bus is occupied and some other device.
If a master can't get a certain line to go high, it lost arbitration and needs to back off and wait until a stop condition.
What about the risk of data corruption ?
The problem of data corruption will occur if both the masters pulls the SDA low at the same time.
The two MCU's are accessing a slave in write mode at address 1111001.
The slave acknowledges this. So far, both masters are under the impression that they "own" the bus.
MCU1 wants to transmit 01010101 to the slave.
MCU2 wants to transmit 01100110 to the slave.
The moment the data bits do not match anymore one of them loses arbitration and backs off.
For as long as there has been no STOP present on the bus, it won't touch the bus and leave the SDA and SCL lines alone.
The moment a STOP was detected, MCU2 can attempt to transmit again to acquire the owner ship of the bus again.
All masters generate their own clock on the SCL line to transfer messages on the I2C-bus.
Data is only valid during the HIGH period of the clock.
A defined clock is therefore needed for the bit-by-bit arbitration procedure to take place.
Clock synchronization is performed using the wired-AND connection of I2C interfaces to the SCL line.
When all devices concerned have counted off their LOW period, the clock line will be released and go HIGH.
There will then be no difference between the device clocks and the state of the SCL line, and all the devices will start counting their HIGH periods.
The first device to complete its HIGH period will again pull the SCL line LOW.
NOTE:
A synchronized SCL clock is generated with its LOW period determined by the device with the longest clock LOW period.
Its HIGH period determined by the one with the shortest clock HIGH period.
Sync clock
Master clk
Device clk
Using the clock synchronizing mechanism as a handshake
The I2C protocol includes a synchronization mechanism which is used as a handshake mechanism between slow and fast devices or between masters in a multi-master session
When a slow slave (slow in terms of internal execution) is attached to the bus then problems may occur.
This lead to duplication of data and corruption.
The slave must have some means to tell the master that it is busy. It could of course simply not respond to the ACK cycle.
This would cause the master to send a stop condition and retry.
Think about an A/D converter. It might take some time for the conversion to complete.
If the master would just go on it would be reading the result of the previous conversion instead of the newly acquired data.
The synchronization mechanism is so simple, the mechanism works on the SCL line only. The slave that wants the master to wait simply pulls the SCL low as long as needed.
This is like adding "wait states" to the I2C bus cycle.
The master simply waits until it can get the SCL line to go HIGH and then just goes on with whatever it was doing .
The drawback is speed. The bus is locked at that moment. If you have rather long delays (long conversion time in our example above), then this penalizes the total bus speed a lot.
TRANSFERRING DATA
Every byte put on the SDA line must be 8-bits long.
The number of bytes that can be transmitted per transfer is unrestricted.
Each byte has to be followed by an Acknowledgement bit.
Data is transferred with the most significant bit first.
If a slave can’t receive or transmit another complete byte of data until it has performed some other function, for example servicing an internal interrupt, it can hold the clock line SCL LOW to force the master into a wait state.
Acknowledge:
The receiver must pull down the SDA line during the acknowledge clock pulse so that it remains stable LOW during the HIGH period of this clock pulse .
The Standard-mode I2C-bus specification, with its data transfer rate of up to 100 kbit/s and 7-bit addressing, has been in existence since the beginning of the 1980’s.
To meet the demands for higher speeds, as well as make available more slave address for the growing number of new devices. The following changes were made.
Fast-mode, with a bit rate up to 400 kbit/s.
High-speed mode (Hs-mode), with a bit rate up to 3.4 Mbit/s.
10-bit addressing, which allows the use of up to 1024 additional slave addresses.
I2C Bus Standard,Inter Integrated Circuit Bus Standards
RAJESHS, Tuesday, October 27, 2009
Subscribe to:
Post Comments (Atom)
Comments :
Post a Comment