I2C (Inter Integrated Circuit) Bus Technical Overview and Frequently Asked Questions - JohnHau/mis GitHub Wiki

Based on the I2C FAQ by Vince Himpe

In the early 1980's, NXP Semiconductors developed a simple bi-directional 2-wire bus for efficient inter-IC control. This bus is called the Inter-IC or I2C-bus. At present, NXP's IC range includes more than 150 CMOS and bipolar I2C-bus compatible types for performing communication functions between intelligent control devices (e.g. microcontrollers), general-purpose circuits (e.g. LCD drivers, remote I/O ports, memories) and application-oriented circuits (e.g. digital tuning and signal processing circuits for radio and video systems).

All I2C-bus compatible devices incorporate an on-chip interface which allows them to communicate directly with each other via the I2C-bus. This design concept solves the many interfacing problems encountered when designing digital control circuits. I2C has become a de facto world standard that is now implemented in over 1000 different ICs and is licensed to more than 50 companies.

History of the I2C Bus The I2C bus was developed in the early 1980's by Philips Semiconductors. Its 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 microcontroller's parallel address and data bus. This results in lots of wiring on the PCB's to route the address and data lines, not to mention a number of address decoders and glue logic to connect everything. In mass production items such as TV-sets, VCR's and audio equipment, this is not acceptable. In these appliances, every component that can be saved means increased profitability for the manufacturer and more affordable products for the end customer. Furthermore, lots of control lines implies that the systems is more susceptible to disturbances by Electromagnetic Interference (EMI) and Electrostatic Discharge (ESD).

The research done by Philips Labs in Eindhoven (The Netherlands) to overcome these problems resulted in a 2-wire communication bus called the I2C bus. I2C is an acronym for Inter-IC bus. Its name literally explains its purpose: to provide a communication link between Integrated Circuits.

Today, the I2C bus is used in many other application fields than just audio and video equipment. 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, Analog Devices and others.

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, and 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. Obviously, an LCD driver is only a receiver, while a memory or I/O chip can be both transmitter and receiver.

The I2C bus is a multi-master bus. This means that more than one IC capable of initiating a data transfer can be connected to it. The I2C protocol specification states that the IC that initiates a data transfer on the bus is considered the Bus Master. Consequently, at that time, all the other ICs are regarded to be Bus Slaves.

As bus masters are generally microcontrollers, let's take a look at a general 'inter-IC chat' on the bus. Lets consider the following setup and assume the MCU wants to send data to one of its slaves (also see here for more information; click here for information on how to receive data from a slave).

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.

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 operation (Write in our example). 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 (see below). 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 DATA. In our case, the MCU will transmit 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.

We have had several states on the bus in our example: START, ADDRESS, ACKNOWLEDGE, DATA , STOP. These are all unique conditions on the bus. Before we take a closer look at these bus conditions we need to understand a bit about the physical structure and hardware of the bus.

Bus Arbitration So far we have seen the operation of the bus from the master's point of view and using only one master on the bus.

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.

How can you know if some other device is transmitting on the bus ? Fortunately, the physical bus setup helps us out. Since the bus structure is a wired AND (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 is pulling the line low.

Therefore the general rule of thumb is: 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 is seen before making another attempt to start transmitting.

What about the risk of data corruption ? Since the previous rule says that a master loses arbitration when it cannot get either SCL or SDA to go high when needed, this problem does not exist. It is the device that is sending the '0' that rules the bus. One master cannot disturb the other master's transmission because if it can't detect one of the lines to go high, it backs off, and if it is the other master that can't do so, it will behave the same.

Clock Synchronization 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. This means that a HIGH to LOW transition on the SCL line will cause the devices concerned to start counting off their LOW period and, once a device clock has gone LOW, it will hold the SCL line in that state until the clock HIGH state is reached. However, the LOW to HIGH transition of this clock may not change the state of the SCL line if another clock is still within its LOW period. The SCL line will therefore be held LOW by the device with the longest LOW period. Devices with shorter LOW periods enter a HIGH wait-state during this time.

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. In this way, a synchronized SCL clock is generated with its LOW period determined by the device with the longest clock LOW period, and its HIGH period determined by the one with the shortest clock HIGH period.

Using the Clock Synchronizing Mechanism as a Handshake The I2C protocol also includes a synchronization mechanism. This can be 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. Let's consider a serial EEPROM. The actual writing process inside the EEPROM might take some time. Now if you send multiple bytes to such a device, the risk exists that you send new data to it before it has completed the write cycle. This would corrupt the data or cause data loss.

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. (That's how it is done in hardware in EEPROMs.)

Other cases might not be so simple. 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.

Now the synchronization mechanism can come in handy. This 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 is then not able to produce the ACK clock pulse because it cannot get the SCL line to go high. Of course the master software must check this condition and act appropriately. In this case, the master simply waits until it can get the SCL line to go HIGH and then just goes on with whatever it was doing.

There are a number of minor drawbacks involved when implementing this. If the SCL gets stuck due to an electrical failure of a circuit, the master can go into deadlock. Of course this can be handled by timeout counters. Plus, if the bus gets stuck like this, the communication is not working anyway.

Another 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. Other masters cannot use the bus at that time either.

This technique does not interfere with the previously introduced arbitration mechanism because the low SCL line will lead to back-off situations in other devices which possibly would want to "claim" the bus. So there is no real drawback to this technique except the loss of speed / bandwidth and some software overhead in the masters.

You can use this mechanism between masters in a multi-master environment. This can prevent other master from taking over the bus. In a two-master system this is not useful. But as soon as you have three or more masters this is very handy. A third master cannot interrupt a transfer between master 1 and 2 in this way. For some mission-critical situations this can be a very nice feature.

You can make this technique rigid by not pulling only the SCL line low, but also the SDA line. Then any master other than the two masters talking to each other will immediately back off. Before you continue, you first let SCL go back high, and then SDA, representing a stop condition. Any master which attempted to communicate in the meantime would have detected a back-off situation and would be waiting for a STOP to appear.

Special Addresses and Exceptions In the I2C address map there are so-called "reserved addresses". This section contains some more details on these addresses and what they do. For information about the Extended Addressing Mode, please refer to the corresponding chapter.

Note 1: The general call address

This address is being used to access all devices on the bus which are capable of handling the general call and need this data. Devices which are capable of handling this general call but do not need it will not answer.

All bytes transferred after this address may or may not be taken in by the slaves that are responding to it. If no slave is acknowledging a transmitted byte, the operation is stopped by issuing a STOP on the bus.

The meaning of the general call address is specified in the 1st byte transmitted after this "general call". This first byte can contain the following information:

Enhanced I2C (FAST Mode) Since the first I2C spec release (which dates back from 1982), a couple of improvements have been made. In 1992, a newer version of the I2C spec was released. This new spec contained some additional sections covering FAST mode and 10-bit addressing.

In the FAST mode, the physical bus parameters are not altered. The protocol, bus levels, capacitive load etc. remain unchanged. However, the data rate has been increased to 400 Kbit/s and a constraint has been set on the level of noise that can be present in the system. To accomplish this task, a number of changes have been made to the I2C bus timing.

Since all CBUS activities have been canceled, there is no compatibility anymore with CBUS timing. The development of ICs with CBUS interface has long been stopped. The existing CBUS IC's are discontinued. Furthermore, the CBUS devices cannot handle these higher clock rates.

The input of the FAST mode devices all include Schmitt triggers to suppress noise. The output buffers include slope control for the falling edges of the SDA and SCL signals. If the power supply of a FAST mode device is switched off, the bus pins must be floating so that they do not obstruct the bus.

The pull-up resistor must be adapted. For loads up to 200 pF, a resistor is sufficient. For loads between 200pF and 400pF, a current source (active pull-up) is preferred.

High-Speed I2C (HS-Mode) High-speed mode (Hs-mode) devices offer a quantum leap in I2C-bus transfer speeds. Hs-mode devices can transfer information at bit rates of up to 3.4 Mbit/s, yet they remain fully downward compatible with Fast- or Standard-mode (F/S-mode) devices for bi-directional communication in a mixed-speed bus system. With the exception that arbitration and clock synchronization is not performed during the Hs-mode transfer, the same serial bus protocol and data format is maintained as with the F/S-mode system. Depending on the application, new devices may have a Fast or Hs-mode I2C-bus interface, although Hs-mode devices are preferred as they can be designed-in to a greater number of applications.

High speed transfer To achieve a bit transfer of up to 3.4 Mbit/s the following improvements have been made to the regular I 2 C-bus specification:

Hs-mode master devices have an open-drain output buffer for the SDAH signal and a combination of an open-drain pull-down and current-source pull-up circuit on the SCLH output (1) . This current-source circuit shortens the rise time of the SCLH signal. Only the current-source of one master is enabled at any one time, and only during Hs-mode. No arbitration or clock synchronization is performed during Hs-mode transfer in multi-master systems, which speeds-up bit handling capabilities. The arbitration procedure always finishes after a preceding master code transmission in F/S-mode. Hs-mode master devices generate a serial clock signal with a HIGH to LOW ratio of 1 to 2. This relieves the timing requirements for set-up and hold times. As an option, Hs-mode master devices can have a built-in bridge (1) . During Hs-mode transfer, the high speed data (SDAH) and high-speed serial clock (SCLH) lines of Hs-mode devices are separated by this bridge from the SDA and SCL lines of F/S-mode devices. This reduces the capacitive load of the SDAH and SCLH lines resulting in faster rise and fall times. The only difference between Hs-mode slave devices and F/S-mode slave devices is the speed at which they operate. Hs-mode slaves have open-drain output buffers on the SCLH and SDAH outputs. Optional pull-down transistors on the SCLH pin can be used to stretch the LOW level of the SCLH signal, although this is only allowed after the acknowledge bit in Hs-mode transfers. The inputs of Hs-mode devices incorporate spike suppression and a Schmitt trigger at the SDAH and SCLH inputs. The output buffers of Hs-mode devices incorporate slope control of the falling edges of the SDAH and SCLH signals. The figure below shows the physical I 2 C-bus configuration in a system with only Hs-mode devices. Pins SDA and SCL on the master devices are only used in mixed-speed bus systems and are not connected in an Hs-mode only system. In such cases, these pins can be used for other functions.

Optional series resistors Rs protect the I/O stages of the I2C-bus devices from high-voltage spikes on the bus lines and minimize ringing and interference. Pull-up resistors Rp maintain the SDAH and SCLH lines at a HIGH level when the bus is free and ensure the signals are pulled up from a LOW to a HIGH level within the required rise time. For higher capacitive bus-line loads (>100 pF), the resistor Rp can be replaced by external current source pull-ups to meet the rise time requirements. Unless proceeded by an acknowledge bit, the rise time of the SCLH clock pulses in Hs-mode transfers is shortened by the internal current-source pull-up circuit MCS of the active master.

Extended Addressing (10-bit) Due to the increasing popularity of the I2C bus the 7-bit address space got exhausted. This started posing problems for people currently in the phase of designing a new I2C compatible IC. Therefore the I2C standard has been updated to implement a 10-bit addressing mode.

A chip that conforms to the new standard receives two address bytes. The first consists of the extended addressing reserved address including the 2 MSB's of the device address and the Read/Write bit. The second byte contains the 8 LSB's of the address.

This scheme insures that the 10 bit addressing mode stays completely transparent for the other devices on the bus. Any new design should implement this new addressing scheme.

Note: The above waveform is slightly exaggerated. You will not notice SDA going high in (2) and (5). A small spike might barely be visible.

Note: An Acknowledge of a byte received from a slave is always necessary, EXCEPT on the last byte received.

If the master wants to stop receiving data from the slave, it must be able to send a stop condition.

Since the slave regains control of the SDA line after the ACK cycle issued by the master, this could lead to problems.

Let's assume the next bit ready to be sent to the master is a 0. The SDA line would be pulled low by the slave immediately after the master takes the SCL line low. The master now attempts to generate a Stop condition on the bus. It releases the SCL line first and then tries to release the SDA line - which is held low by the slave. Conclusion: No Stop condition has been generated on the bus.

This condition is called a NACK : Not ACKnowledge . Do not confuse this with No ACKnowledge:

Condition Can Only Occur... Not acknowledge (NACK) After a master has read a byte from a slave No acknowledge After a master has written a byte to a slave

No Acknowledge Condition This is not exactly a condition. It is merely a state in the data flow between master and slave.

If, after transmission of the 8th bit from the master to the slave the slave does not pull the SDA line low, then this is considered a No ACK condition.

This means that either :

The slave is not there (in case of an address) The slave missed a pulse and got out of sync with the SCL line of the master. The bus is "stuck". One of the lines could be held low permanently. In any case the master should abort by attempting to send a stop condition on the bus.

A test for a "stuck bus" can be performed in the stop condition cycle.

I2C FAQ What is the maximum distance of the I2C bus? This depends on the load of the bus and the speed you run at. In typical applications, the length is a few meters (9-12ft). The maximum capacitive load has been specified (see also the electrical Spec's in the I2C FAQ). Another thing to be taken into account is the amount of noise picked up by long cabling. This noise can disturb the signal transmitted over the bus so badly that it becomes unreadable.

The length can be increased significantly by running at a lower clock frequency. One particular application - clocked at about 500Hz - had a bus length of about 100m (300ft). If you are careful in routing your PCB's and use proper cabling (twisted pair and/or shielded cable), you can also gain some length.

If you need to go far at high speed, you can use an active current source instead of a simple pull-up resistor. Philips has a standalone product for this purpose. Using a charge pump also reduces "ghost signals" caused by reflections at the end of the bus lines.

I'd like to extend the I2C bus. Is there something like a repeater for I2C? Yes indeed this exists. Philips manufactures a special chip to buffer the bi-directional lines of the I2C bus. Typically, this is a current amplifier. It forces current into the wiring (a couple of mA). That way you can overcome the capacitance of long wiring.

However, you will need this component on both sides of the line. The charge pump in this devices can deliver currents up to 30mA which is way too much for a normal I2C chip to handle. With these buffers you can handle loads up to 2nF. The charge amplifier 'transforms' this load down to a 200pF load which is still acceptable by I2C components.

Can I do galvanic decoupling of my I2C bus? This is possible. The circuit is rather complex due to the bi-directional nature of the I2C bus.

Note: Since the speed of the I2C bus can be rather high, it is recommended to use a fast optocoupler. However, this circuit will not work on speeds higher then 10KHz. A 6N139 will do the job in all cases. The two PNP and the two NPN transistors can be any standard type, e.g. 2N2219 and 2N2222 (USA) or BC547 and BC557 (EUROPE).

How does it work ?

The problem with bi-directional lines is that a buffer tends to get stuck on a certain level. This case has been taken into account in the above schematic. In the following explanation we assume that the left side is transmitting and the right side is receiving (the circuit is symmetrical)

Let's assume we send a logic 1 into the left side. The LED of the top optocoupler will stay dark. Since its transistor does not receive any light, it is not turned on. The next transistor does not get driven and the line at the end is being pulled high via resistors 1' and 3'. The PNP transistor 5' will not get driven. Therefore the LED connected to it will not light up and there is no feedback signal.

Now let's see what will happen if we send a logic 0. The first transistor 5 will be turned on, therefore the led connected to it will start emitting light. This results in the fact that its matching transistor will turn on. The transistor connected to the emitter will be turned on also. The output line is now being pulled low via resistor 3'. This low level would turn on the PNP transistor, which would result in the other optocoupler to light, its transistor to turn on etc. In other words, the circuit would go into a lock-up. However, since the NPN transistor is pulling the anode of the LED to ground, this will not happen. This way we have eliminated the deadlock.

Are there stand-alone I2C controllers? Yes indeed. There is a special chip to do the I2C interfacing. The PCD8584 or PCF8584 incorporate a complete I2C interface. These chips are designed in such way that they can interface to almost any microcontroller around.

How can I generate a repeated start condition? Let's assume the following situation: The controller lets the SCL line go high and the device pulls SDA low to acknowledge. So far no problem but how do you generate a repeated start condition now? The device is pulling SDA low.

First you have to complete the ACK cycle. To do this, you must pull SCL low again. The slave will release the data line when it detects that SCL is low. Now you can issue a stop command. To do this, you let the SCL go high again and then pull low the SDA line.

This is the confusing part of the procedure. Normally, you would suspect that by letting the clock line go high again you will be clocking in the first bit of a new byte. As a matter of fact that is the case. But since the chip will detect a START condition, this operation gets cancelled.

Can I abort an ongoing I2C bus transmission? Is it okay to abort an on-going transmission any time.

According to the specification, this should work. It depends on the layout of the component. A real I2C compatible IC will be able to handle this. It might make sense to test this before you use it.

Usually, when a START or STOP condition is detected, the internal logic of the chip is forced into a certain state. Internally, the logic that detects START and STOP is different from the logic that does all other processing. The START together with the address register is to be considered as a functional unit inside the chip.

When a START is detected, all internal operations are cancelled and the chip will compare the incoming data with its own address.

When a STOP is detected, ALL chips on the bus will reset their internal logic to IDLE mode except for the START detector (this is also used to cut power consumption). Therefore, when a start condition is issued on the bus, the START detector will 'wake-up' the rest of the internal logic.

Do I need to generate an ACK in read mode on the last byte? This is a somewhat puzzling question. Indeed this is a bit strange. Usually, if you have read the last byte in a chip and generate an ACK, the chip should do nothing anymore, so the bus should be clear for you to create a STOP condition. Apparently, there are some chips that start transmitting data again. One such chip is the PCF 8574 I/O expander.

Though not always desirable, this feature can come in handy. If you need to sample incoming data fast, then you just continue reading from the chip. This prevents that you lose 'arbitration' of the bus in a multi-master environment.

It also speeds things up. You don't have to address the chip over and over again so you save the time for START, Address, ACK and STOP stage for every next byte read. This can lead to a more than doubled transfer rate.

Why does the SCL line have to be bi-directional? The clock line needs to be bi-directional when using a MULTI-MASTER protocol and when using the synchronization protocol.

When you are using only one Master then this is not required since the clock will always be generated by this device. If you run Multi-master then this changes. One master must be able to receive data from another master. At that time it must be able to receive clock information via the clock line also.

How it works:

Rs are serial resistors used to minimize cross talk and undershoot. They also protect the I/O drivers of the I2C devices against higher than allowed voltages and current injection. These resistors are advised if you run a long bus on high speed (such as in enhanced I2C mode).

When the bus becomes idle, all output stages on the bus are turned off and SCL and SDA) go high. This will not happen immediately, the voltage will rather rise during a certain time. Now assume the switch (IC1) is not there. The charge time of the bus capacitor would only be determined by the value of R1. The larger R1 and Rs, the longer it will take for the bus to reach a sufficient stable HIGH level.

We can't make the Rs resistors too small because then we would go out of spec on the maximum allowable current into one I2C device when turning on its output driver.

When we calculate for a current of 3mA, we end up at approximately 1800 Ohms for the serial resistance.

  5V / 3mA = 1666 Ohms.

To stay somewhere below this 3mA rating, we pick 1800 Ohms. The charge time for a bus capacitance of about 200pF would be around 360 ns. That is out of spec. The spec for rise or fall time in Fast I2C is set to approx 300ns.

But we can't drop the value of our resistor without breaking the other spec of 3mA of maximum current.

The idea is to change the value of the resistor temporarily using the analog switch IC1. If the voltage level sensed by the switch is in the range 0.8 to 2 volts then it will turn on. This means that as soon as the voltage on the SDA line starts rising, resistor R2 will kick in. R1 and R2 in parallel result in a resistance of 720 Ohms. This increases the charge current to a value of

5 volts / 720 Ohms = 7 mA.

This is allowable for a brief period of time. Of course all of this is a dynamic process. The actual charge current will change due to the fact that the bus voltage will rise.

When the output stage is turned off, this current slightly drops due to the fact that the voltage on the bus is rising. The moment our switch kicks in you see the current doubling. The same effect is then present as before the switch closed: the current drops as the bus voltage rises. When the switch opens again the current drops a little to charge the capacitor up to 5 volts. But at that time, all chips already detect a logic one and are well within the 300ns rise time.

How can I monitor the I2C bus? There are a few commercial I2C monitor / debuggers around that can do this.

There is another possibility to do this: By using the stand-alone I2C controller PCF8584 from Philips. This chip has a certain mode in which it does not take part in the real I2C action but only records what is going on. It listens to all addresses, but does not generate any acknowledge. Using some software routines and a MCU you could build a universal I2C data logger.

How can I test / debug the I2C bus? There is no general way to debug an I2C bus. However, a few guidelines might help to get it running.

First thing is to check the levels on the bus. You should see a clear signal that has a low level that is lower then 0.8 volt and a high level which is at least 3.5 volts.

If the high level is not high enough or does not rise fast enough then you can try to lower the value of the pull up resistor. You must take care however not to surpass the maximum allowable current in the I2C driver stage. The minimum allowable resistor for a 5 volt driven I2C bus is 5 V / 3mA = 1600 Ohms. A typical value of 4700 ohm should work fine.

Make sure the bus is not 'stuck' to '0'. This could be the result of a bad power supply (chips go into latch up during power-on) or a bad chip.

There are a few commercial I2C monitor / debuggers around.

Is there an RS232 / I2C converter? Yes, there are at least two of them. Please visit one of the following links:

http://www.emicros.com/i2c232.htm http://www.pickeringswitch.com/simrc/simrcspec.html Which microcontrollers do have an on-chip I2C interface? A LOT of MCU's have a real I2C interface implemented in hardware, but this should not restrict the use of the I2C bus on other MCU's. ANY MCU can be made to talk to I2C using some small software routines.

There are microcontrollers with on-chip I2C modules as well as stand-alone I2C bus peripherals.

To list all the devices here would be impossible. A good overview can be found here: http://www.embeddedlinks.com/chipdir (search for keyword I2C)

Are there PC cards available with an I2C interface? There are a number of debugging tools out there which can monitor an I2C bus

How can I use my oscilloscope to trigger on an I2C start condition? Everybody who ever tried to make a simple oscilloscope Sync on I2C signals knows that this is almost impossible. You will need a very advanced (read: very expensive) scope or logic analyzer to monitor I2C signals. You can do it if your scope has the possibility to trigger on 2 independent channels and if you can program the conditions like level, high-to-low or low-to-high. One such a scope is a Tektronix TDS540.

How it works:

The Start condition in I2C is defined as: Pulling the SDA line low while SCL line is high - which is exactly what the little circuit monitors.

Every transition of the SDA line from HIGH to LOW will make the D-latch sample the level of the SCL line. If at that time the SCL line is low, then the output of the D-latch will go or remain low.

On the other hand, if the SCL line is HIGH (which indicates a start condition), the output of the D-latch will become high.

If you connect the output of the D-latch to the trigger input of a common oscilloscope and set the scope to trigger on RISING edge of the trigger channel, then you have exactly what you want. Every time a start condition is transmitted on the bus, the D-latch will trigger the scope.

What bus speeds are available with I2C? The bus speed for I2C was increased over the years. The following modes are available:

Standard mode, with a bit rate up to 100kbit/s 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

Overview of the Different Versions of the I2C Specification The very first specification dates back to the year 1982. It only covered Standard mode (up to 100 kbit/s) and 7-bit addressing. Extensions like Fast Mode, Hs-Mode or 10-bit addressing were added in later versions.

Version 1.0 - 1992 This version of the 1992 I2C-bus specification included the following modifications:

Programming of a slave address by software has been omitted. The realization of this feature was rather complicated and had not been used. The "low-speed mode" has been omitted. This mode was, in fact, a subset of the total I2C-bus specification and did not need to be specified explicitly. The Fast-mode was added. This allows a fourfold increase of the bit rate up to 400 kbit/s. Fast-mode devices are downwards compatible i.e. they can be used in a 0 to 100 kbit/s I2C-bus system. 10-bit addressing was added. This allows 1024 additional slave addresses. Slope control and input filtering FOR FAST-MODE DEVICES was specified to improve the EMC behavior. NOTE: Neither the 100 kbit/s I2C-bus system nor the 100 kbit/s devices have been changed. Version 2.0 - 1998 As the I2C-bus became a de facto world standard implemented in over 1000 different ICs and licensed to more than 50 companies, an update of the specification became necessary as many of the newer applications required higher bus speeds and lower supply voltages. This version 2.0 of the I2C-bus specification met those requirements and included the following modifications:

The High-speed mode (Hs-mode) was added. This allows an increase in the bit rate up to 3.4 Mbit/s. Hs-mode devices can be mixed with Fast- and Standard-mode devices on the one I2C-bus system with bit rates from 0 to 3.4 Mbit/s. The low output level and hysteresis of devices with a supply voltage of 2 V and below has been adapted to meet the required noise margins and to remain compatible with higher supply voltage devices. The 0.6 V at 6 mA requirement for the output stages of Fast-mode devices has been omitted. The fixed input levels for new devices were replaced by bus voltage-related levels. Application information for bi-directional level shifter was added. Version 2.1 - 2000 Version 2.1 of the I2C-bus specification is the most current version. It includes the following minor modifications:

After a repeated START condition in Hs-mode, it is possible to stretch the clock signal SCLH. Some timing parameters in Hs-mode have been relaxed.

I2C Driver in Pseudocode It is written in PseudoCode which is an imaginary programming language that any programmer should be capable of porting to his/her favorite language.

First we will define a set of basic interface routines. All text between / / is considered as remark.

Following variables are used :

n,x = a general purpose BYTE SIZE = a byte holding the maximum number of transferred data at a time DATA(SIZE) = an array holding up to SIZE number of bytes. This will contain the data we want to transmit and will store the received data. BUFFER = a byte value holding immediate received or transmit data. / $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ / / **** I2C Driver V1.1 Written by V.Himpe. Released as Public Domain **** / / $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ / DECLARE N,SIZE,BUFFER,X Byte DECLARE DATA() Array of SIZE elements SUBroutine I2C_INIT / call this immediately after power-on / SDA=1 SCK=0 FOR n = 0 to 3 CALL STOP NEXT n ENDsub SUBroutine START SCK=1 / BUGFIX !/ SDA=1 / Improvement / SDA=0 SCK=0 SDA=1 ENDsub SUBroutine STOP SDA=0 SCK=1 SDA=1 ENDsub SUBroutine PUTBYTE(BUFFER) FOR n = 7 TO 0 SDA= BIT(n) of BUFFER SCK=1 SCK=0 NEXT n SDA=1 ENDsub SUBroutine GETBYTE FOR n = 7 to 0 SCK=1 BIT(n) OF BUFFER = SDA SCK=0 NEXT n SDA=1 ENDsub SUBroutine GIVEACK SDA=0 SCK=1 SCK=0 SDA=1 ENDsub SUBroutine GETACK SDA=1 SCK=1 WAITFOR SDA=0 SCK=0 ENDSUB / this concludes the low-level set of instructions for the I2C driver The next functions will handle the telegram formatting on a higher level / SUBroutine READ(Device_address,Number_of_bytes) Device_adress=Device_adress OR (0000.0001)b /This sets the READ FLAG/ CALL START CALL PUTBYTE(Device_adress) CALL GETACK FOR x = 0 to Number_of_bytes CALL GETBYTE DATA(x)=BUFFER /Copy received BYTE to DATA array / IF X< Number_of_bytes THEN /Not ack the last byte/ CALL GIVEACK END IF NEXT x CALL STOP ENDsub SUBroutine WRITE(Device_address,Number_of_bytes) Device_adress=Device_adress AND (1111.1110)b / This clears READ flag / CALL START CALL PUTBYTE(Device_adress) CALL GETACK FOR x = 0 to Number_of_bytes CALL PUTBYTE (DATA(x)) CALL GETACK NEXT x CALL STOP ENDsub SUBroutine RANDOMREAD(Device_adress,Start_adress,Number_of_bytes) Device_adress=Device_adress AND (1111.1110)b / This clears READ flag / CALL START CALL PUTBYTE(Device_adress) CALL GETACK CALL PUTBYTE(Start_adress) CALL GETACK CALL START /create a repeated start condition/ Device_adress=Device_adress OR (0000.0001)b /This sets the READ FLAG/ CALL PUTBYTE(Device_adress) CALL GETACK FOR x = 0 to Number_of_bytes CALL GETBYTE DATA(x)=BUFFER CALL GIVEACK NEXT x CALL STOP ENDsub SUBroutine RANDOMWRITE(Device_adress,Start_adress,Number_of_bytes) Device_adress=Device_adress AND (1111.1110)b / This clears READ flag / CALL START CALL PUTBYTE(Device_adress) CALL GETACK CALL PUTBYTE(Start_adress) CALL GETACK FOR x = 0 to Number_of_bytes CALL PUTBYTE (DATA(x)) CALL GETACK NEXT x CALL STOP ENDsub / $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ / / **** I2C Driver . (c)95-97 V.Himpe . Public Domain release *** / / $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ / Some notes about the high level routines.

The READ and WRITE routine read / write one or more byte(s) from / to a slave device. Generally this will be used only with Number_of_bytes set to 1. An example:

PCD8574=(0100.0000)b CALL READ(PCD8574,1) result = DATA(0) / will read the status of the 8 bit input port of a PCD8574. / DATA(0)=(0110.01010)b CALL WRITE(PCD8574,1) / will write 0110.0101 to the 8 bit port of the PCD8574 / When do you need a multi-read ? Consider a PCF8582 EEPROM. You want to read its contents in one time.

PCF8582=(1010.0000)b CALL READ(PCF8582,255) You can do the same with WRITE for the EEPROM with the restriction that Number_of_bytes is not larger than 4 AND that you write on page boundaries (multiple of 4 for offset).

You will have to check the components datasheets.

The most useful instructions are RANDOMREAD and RANDOMWRITE.

Write 4 bytes of data to location 20h of the EEPROM:

DATA(0)=(1010.0011)b DATA(1)=(1110.0000)b DATA(2)=(0000.1100)b DATA(3)=(1111.0000)b CALL RANDOMWRITE (PCF8582,(20)h,3) The same goes for reading 16 bytes from the EEPROM starting at address 42h:

CALL RANDOMREAD(PCF8582,(42)h,15) The results are stored in DATA. All you have to do is read them out of the array for processing. When you give the devices address to these routines you don't have to care about the R/W flag. It will be automatically set to the right state inside the routines.

Legal Notes and Copyrights The use and manufacturing of I2C devices is subject to a copyright and patents from NXP.

This means that you (as a semiconductor manufacturer or system developer) need to purchase a license from NXP to use I2C technology in your system.

However, if you buy components which carry the I2C logo from NXP or another manufacturer then you immediately have the license to use these components.

For further legal information about this please contact your local NXP representative.

Standard NXP Copyright notice :

"Purchase of NXP I2C components conveys a license under the NXP I2C patent to use the components in the I2C system, provided the system conforms to the I2C specifications defined by NXP."