I2C Bus FAQ Version 3.0
This article is a collection of information sources on the I2C Bus. The document exists as
a HTML file and as a iSilo document for Palm (tm) based organisers. You are free to use ,
copy , distribute and disclose the contents of this faq to anyone provided no money is
asked for the copy.
Use of information in this faq is solely at the users risk. No liability will be accepted for any damage or loss resulting from the use or abuse of information contained in this document.
Preface
Hi and welcome to the latest edition of the I2C FAQ. Over the years I have been supporting
people in their attempt to master this bus. I have collected a total of over 500 e-mails
with questions ranging from beginner level to things that even I could not solve in 1-2-3.
I Will try to summarize the knowledge I obtained in this revision of the FAQ.
I Would like to thank all the people who have bombarded me with interesting stuff and questions about I2C. I am also happy that my little knowledge could help.
Vincent September 1st 2000.
Back to Main Index
Who put this FAQ together?
I put this FAQ together in response to my own frustration in searching for information
about I2C. I have been playing with the bus for some time and, although I am not an expert
on this matter, i think my, and other people's, experiences with the I2C BUS can solve
common problems.
Back to Main Index
How can I contribute to this FAQ?
If you have any suggestions or additions please inform me or the future maintainer of the
FAQ.You can contact me by e-mail : [email protected] ( valid until 1 Jan
2001 ) after that E-mail will most likely no longer be possible.
I hope that those of you who know of interesting items for this FAQ will share with
everyone. A good amount of stuff is turning up thanks to everyone's help. If you have a
website you can put the FAQ or a link to the FAQ online there.
Back to Main Index
What newsgroups will it be posted in?
This FAQ has been posted a last time to the following newsgroup: sci.electronics.design
Back to Main Index
May I distribute this FAQ ?
I am putting no restrictions on the use of this FAQ except - It must be distributed in its
entirety with the copyright notice, and no financial gain may be realized from it. After
all, I have spent, and lot of time on this. The only thing that I intend to gain from it
is more information on I2C. For this reason I have appended a copyright statement to the
end of this FAQ. I feel pretty silly doing this, but I just want to protect myself.
The copyright does not limit the use of this FAQ for noncommercial purposes. I hereby give my permission to one and all to pass this FAQ around and post it wherever you want - as long as it is not for financial gain.
You are allowed to distribute portions of the FAQ as long as you
incorporate the following note. 'Taken from The I2C FAQ' and provide a link
to its storage on the internet.
Back to Main Index
ABOUT THE I2C Bus
Historical background.
The I2C bus was developed in the early 1980's by Philips semiconductors.Its purpose was to
provide an easy way to connect a CPU to peripherial chips in consumer applications
(radio's, TV-sets etc).
Normal Computer systems use ByteWide buses to accomplish this task. This results in lots of copper tracks on PCB's to route the Address and datalines. Not to mention a bunch 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. Complex circuits often need multilayer boards, and these are simply too expensive for household goods. Furthermore lots of control lines implies that the systems is more susceptible to disturbances by EMC and ESD.The research done by Philips Labs in Eindhoven (The Netherlands) 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.
Nowadays the extent of the bus goes much further than Audio and Video equipment.The bus is generally accepted in industry. Offsprings like D2B and ACCESS have made an attempt to find their ways into computer peripherals like keyboards, mice, printers, monitors, etc... . However they have been successed by the USB bus. Amazingly the USB bus steals some technology frmo I2C. The basic communication idea and adressing scheme is based on I2C.
The I2C BUS has been adopted by several leading chip manufacturers like Xicor,
SGS-Thomson, Siemens, Intel, TI, Maxim, Atmel, Analog Devices.
Back to Main Index
I2C Bus protocol
The BUS physically consists of 2 active wires and a ground connection. The active wires,
SDA en SCL, are both bidirectional. Where SDA is the Serial DAta line and SCL is the
Serial CLock line.
Every component hooked up to the bus has its own unique address whether it is a CPU, LCD driver, memory, or complex function chip.Each of these chips can act as a receiver and / or transmitter depending on its functionality. Obviously an LCD driver is only a receiver ,while a memory or I/O chip can both be transmitter and receiver. Furthermore there may be one or more BUS MASTER's.
The BUS MASTER is the chip issuing the commands on the BUS. In the I2C protocol specification it is stated that the IC that initiates a data transfer on the bus is considered the BUS MASTER. At that time all the others are regarded to as the BUS slaves.
As mentioned before, the IC bus is a Multi-MASTER BUS. This means that more than one IC capable of initiating data transfer can be connected to it. As MASTERs are generally microcomputers let's take a look at a general 'inter-IC chat' on the bus.
Lets consider the following setup :
Case : The CPU wants to talk to one of the attached components.
The CPU will issue a START condition (see further on for description of all these conditions). This acts as an 'ATTENTION' signal to all of the connected ic's. ALL IC's on the bus will listen to the bus for incoming data.
Then the CPU sends the address of the device he wants to address.This takes 8 clock pulses. At this moment in time all IC's will compare this address with their own.If it doesn't match they simply do nothing and wait until the bus is released by the STOP condition.If the address matches however the chip will produce a responce on the ACKNOWLEDGE signal of the CPU.
The ACKNOWLEDGE signal is issued by the CPU.When the chip whose address matches sees the ACKNOWLEDGE on the bus it Pulls the data line LOW. This is an indication to the CPU that there is a chip with the wanted address on the bus.
Now the CPU can start transmitting or receiving data In our case the CPU will transmit data.When all is done the CPU will issue a STOP condition. This is a signal that the bus has been released and that the IC's may expect another transmission to start any moment.
We have had several states on the BUS right now : START, address ,ACKNOWLEDGE
,DATA ,STOP. These are all unique conditions on the BUS. Before we take a closer look into
these I will talk about the hardware of the BUS. This is necessary to understand what is
physically going on.
Back to Main Index
Hardware layout of the I2C bus.
As stated before the BUS consists of 2 active signal lines and a ground potential.
Internally in the chip the bus looks like this :
The bus interface is built around an input buffer and an open drain or open
collector transistor. When nothing happens the bus lines are in the logic HIGH
state. Note here that an external PULL-UP resistor is neccessary. This is an error
that most beginners make. To put something on the BUS the chip drives its output
transistor, thus pulling the BUS to a LOW level. When the bus is IDLE ( nothing going on )
both lines are HIGH. The HIGH state is defined as NOT LOW (obvious isn't it).
What i mean here is that you cannot set a voltage on the HIGH Level. It depends on the supply voltage of the connected IC's.However as this is mostly 5 Volts you can say that HIGH is 5 volts and LOW 0 volt. Nowadays the 3.3 volt ic's are emerging rapidly. It's clear that in this case the high level will be 3.3 volts. The latest revision of I2C provides a means of interfacing mixed voltage circuits.
The nice thing about this concept is that it has a 'built-in' bus mastering technique. If the bus is 'occupied' by a chip that is sending a 0 then all other chips loose their comm's capability. More will be explained about this further on in the Faq.
However the open collector technique has a drawback too. If you have a long bus this
will have a serious effect on the speed you can obtain . The higher this RC constant
the slower you can go. This is due to the effect that it influences the 'sharpness' of the
edges on the I2C bus . At a certain point the chip will not be able to distinguisch
clearly between a logic 1 and 0.
Long lines present a capacitive load onto the output .Since the pull-up is passive you are
facing an RC constant which will reflect onto the shapes of the signals.
What's more is that you can get reflections at high speed .This can be so bad that 'ghost
signals' disturb your transmission and corrupt the data you transmit. And then even the
Schmitt trigger at the input of the chip will not keep you out of trouble. The following
image shows you exactly what can happen.
Therefore some strict electrical specs have been set forth. These are explained further
on.
To overcome this problem , Philips has developed an Active I2C terminator. This consists of twin charge pumps. You can look at this device as a dynamic resistor. The moment the state changes it provides a large current (low dynamic resistance) to the bus. Doing this it can charge the parasitic capacitor very quickly. Once the voltage has risen above a certain level the high current mode cuts out and the output current drops sharply.
I Have already mentioned some things like START, STOP, ACKNOWLEDGE, SLAVE, MASTER
and so on. In this section these things get explained. When reading this you must
keep the following 2 things in mind.
 | A MASTER is the device that initiates a message. Thus he controls the SCK line. The MASTER always generates the Clock pulses. |
| A SLAVE listens to the master and will send data only when asked. |
| The SDA and SCL lines can only be PULLED low. They cannot be DRIVEN high. To make them high the device just releases the line. The external pull-up resistor does the rest of the work. |
Back to Main Index
Start And Stop condition.
A START condition looks like this:
The bus is in idle mode when both Data and Clock line are high. The chip issuing the Start
condition ( the bus MASTER ) first pulls the SDA (data) line low and then pulls the SCL
(clock) line low.
A STOP condition is just the mirror of the above.
The Bus MASTER first releases the SCL and then the SDA line.
The start condition acts as a signal to all connected IC's that something is about to
be transmitted on the BUS. All the devices on the bus will go to listen mode and check the
incoming data for a match against their address on the bus. The Stop condition tells
the connected chips that the message has been completed and that the bus is free to use.
Back to Main Index
Putting something on the BUS
Putting a bit of any kind on the bus looks like this :
First the MASTER sets the data line to the appropriate level by pulling or not pulling the SDA line low. Then it releases the SCL line for some time and pulls it low again. Now it can change the state of the SDA to the level required for the next bit and the process continues all over again.
The DATA must stay valid during the HIGH level of the CLOCK pulse. If the data chenges while the clock line is high this will bee seen as either a START or STOP condition occurring ! ( depending on the direction of change ).
Using the above information ,a transfer could look like this :
As you can see in the above it is not necessary to have a clock with a constant duty
cycle.The BUS is very relaxed even in such a way that you can stop the clock in the middle
of a transaction and then continue later on. This is very useful. Consider the following :
Your cpu is in the middle of a transaction and gets an interrupt. It can process the
interrupt first and continue its message later on without any problem. (try doing that on
RS232 !). Since there is no minimum clock speed set you can have the communication running
at whatever speed you can handle.
Back to Main Index
Addressing a SLAVE.
EVERY byte put on the BUS MUST be 8 bits long. (8 clock pulses).
A byte is always sent with the MSB first. The number of bytes that can be transmitted in
one data 'telegram' is unrestricted. ('Data telegram' is everything going on on the bus
between a START and STOP condition). However it is allowed to end a transmission any time
by sending a STOP condition. Even when you are only 4 bits far in your telegram. Actually
what happens is that the STOP condition resets the bus control logic of all connected
chips. They start looking for a START condition again.
Back to Main Index
Waiting for ACKNOWLEDGE.
When a chip is being addressed or has received data it will issue an ACKNOWLEDGE pulse.
Therefore the MASTER must first (1) release the DATA line (set it to high level). The
Slave performing an ACQ will pull the DATA line low (2) Shown as the fat line on the image
below.
The MASTER will now send a clockpulse over the SCL line(3). When the clock pulse has been
completed ( SCL goes low again ) the slave will release the DATA line(4). Now that the
MASTER knows that the SLAVE is actually there it can continue. Generally the MASTERs
(mainly CPU's running software) use a timeout value. When no chip is responding after some
time they issue a STOP and then continue with their work. This prevents your software from
locking up if for some reason the addressed chip is not replying.
Concerning the SLAVE pulling low the SDA line it is so that generally the addressed IC will already have pulled the SDA line low even before the MASTER has set the clock HIGH. It is the falling edge of the last clockpulse that triggers the slave.
In the real life it is good practice to actually look during the high level of the CLOCK if the SDA is being pulled LOW or is LOW. Some chips need some time to process the address before they can respond by pulling the SDA low. This can be the fact when the addressed SLAVE is another CPU or an EEprom. Suppose the following : You address a SLAVE CPU. But just before the SLAVE CPU can pull the SDA low it has to process some interrupt occuring.If the transfer issuing CPU would look to the SDA line immediately it would see a HIGH level. Thus it would look like the SLAVE is not responding. The Same goes for EEproms. Since storing data to EEprom cells takes some time the ACKNOWLEDGE is used to indicate that the programming has been completed. So after the last bit has been transferred the EEprom starts writing the received data into its array. It leaves the SDA line in the LOW state until this action has been completed. this means that after the ACQ clockpulse the slave keeps the SDA line LOW !. It is the task of the masdter to wait now until SDA becomes high before continuing. this process might seem to violate the I2C bus spec but actually it doesn't. This process is called synchronisation. ( see the topic explaining this process ).
I have once spend a whole day figuering this one out !.The system once in a while did not work like it should have because the addressed device was not capable of generating an ACKNOWLEDGE in time.
The best way to do an ACKNOWLEDGE , in my humble opinion,is like this: Put the SCL
high, wait some time (your TIMEOUT value), then check if SDA is LOW. If it is LOW - >
The chip is there. If it is HIGH -> The chip isn't there. When removing the ACQ
clockpulse check if the SDA line effectively goes high. If not : the chip is in process of
writing internally.
What happens next ?
Now that the SLAVE has been addressed and responded to the ACKNOWLEDGE the rest of the
telegram (until we issue a STOP) depends solely on the addressed chip. You can just send
one or more bytes to the chip or receive one or more bytes from the chip. It can even be
that you first write something and then read something from the chip.
Back to Main Index
Writing One or More Byte's to a Slave.
After the Device has responded with an ACKNOWLEDGE (see above) you just send another 8
bits on the bus. Now you have to wait again for the SLAVE to ACKNOWLEDGE. If you are
through you issue a STOP command and then the bus is released again. If you need to send
more then you just send another 8 bits and wait for an ACKNOWLEDGE. And so on and on and
on.
I figuered out in real life that on the last transmitted byte you do not have to wait for the ACKNOWLEDGE. You can directly issue a STOP command. Apparently there are some chips that do not generate an ACKNOWLEDGE here !. Theoretically they should generate an ACKNOWLEDGE but for some reason they don't. The best way is as follows : after you have transferred your last byte just to set the SCL high , wait some time , take it low and then issue a STOP command. There is an exception though.
Devices like serial EEproms use the ACKNOWLEDGE for storing the information in the
Memory array.They do not pull the SDA line low until the programming has been completed.In
that way the MASTER has a way to know if the data has been written succesfully.Storing
data in EEprom memory is rather slow.So by monitoring the SDA line the CPU knows when the
chip has completed the WRITE to its memory array.
A byte write could look like this :
------------------------------
|S|SLAVE address|WA|DATA|WA|P|
------------------------------
A multi byte write looks like this:
-----------------------------
|S|SLAVE addr.|WA|DATA|WA|...
-----------------------------
----------------------
...|DATA|WA|DATA|WA|P|
----------------------
Note :
| S = START |
| WA = WAIT FOR ACKNOWLEDGE |
| P = STOP |
Back to Main Index
Reading one or more bytes from a slave.
Looks kind of the same as a byte write. The difference is the handling of the SDA line and
the ACKNOWLEDGE.
The MASTER generates a START , transmits the device address and waits for an ACKNOWLEDGE.
So far so good. Now the MASTER has to RELEASE the SDA (data) line. The SLAVE will pull it
low when needed. On every clock pulse , that the MASTER generates ,the SDA line will be in
the state set by the SLAVE.
When all 8 bits have been read the MASTER must GIVE the ACKNOWLEDGE or to the SLAVE or stop the transmission.
To give an acknowledge to a slave the master holds the SDA line low and gives a clockpulse on SCL. To stop stransmission you simply issue a stop condition on the bus : Keep SCL and SDA low. Now make SCL high , and then make SDA high.
If you give an ACQ pulse to the slave you have to read another byte. Immediately after the ACQ the slave will take hold of the SDA line and you might no longer be able to give a stop before clocking out the next 8 bits.
Note: Here the FAQ has been greatly modified. In the previous FAQ the text caused a lot of confusion.
Determining the SLAVE Access mode
Now there is one thing i haven't told you yet. How does your SLAVE know whether you
want to read from or write to it ?
Thats an easy one. This is beeing determined by the SLAVE address. Each byte consists of 8 bits. The 8th bit in the SLAVE address has a special meaning. When it is set to 0 it means you want to write to your SLAVE. When it is set to 1 it means that you you want to READ. You could see this as follow. The Even addresses are WRITE addresses, the ODD addresses are READ addresses. Each device has a consecutive WRITE and READ address.
Example : a PCF8574 General purpose 8 BIT I/O port.
| SLAVE address to WRITE is (01000000)b = 64d |
| SLAVE address to READ is (01000001)b = 65d |
So you can have a theoretical maximum of 128 device on you BUS. Practically this is not
the case. There have been set up a couple of addresses which you are not allowed to
use.(more about this later on). Now there is one more type of DATA telegram.
Back to Main Index
The Combined data format.
This is a format generally used by memory devices. Suppose you have an 128 byte deep
memory on the bus and you want to read the 84th byte. Normally you would have to read the
first 83 bytes before getting what you want. This takes too much time and occupies
the bus. In this case there are two possibilities. You first write to the SLAVE
address a byte which tells it on which location you want to read. Then you start a read
operation. That is one way of doing it. A more elegant way to do this is using a combined
mode telegram.
---------------------------
|S|AS WRITE|WA|SEND BYTE|..
---------------------------
-------------------------
..WA|S|AS READ|WA|READ|P|
-------------------------
To start this sequence you access the chip in write mode. AS WRITE = Address Slave in
WRITE mode (even address). Wait for ACKNOWLEDGE and WRITE a byte. This byte is beeing
treated by the memory as the location pointer. (that is how i2C memories work). Then you
wait for an ACKNOWLEDGE by the SLAVE and you generate another START condition. Now you
send the SLAVEs READ address ( ODD address ) Wait for ACKNOWLEDGE and you receive the data
byte. From now on you are in standard READ mode. So you can now either send a STOP
or continue reading from your SLAVE by giving an ACQ to the slave and clocking out the
next byte. All memory devices auto-increment their location pointer.
Now you can even go one step further and generate another START and then address the SLAVE as write. Send a new Data byte (which acts on the location pointer), send another start, enter read mode etc ...... This combined mode is really a very flexible means of addressing complex components. This may look very messy. But it has its pro's and con's:
PRO: If you have 2 CPU's on your bus which could want to take the bus this will assure you that you will be able to continue your actions on the bus without interference from the other CPU. Remember that when you have generated a START and have sent the SLAVE address the other CPU too will be waiting until a STOP appears on the bus. So he will not try to put something on the bus.There could be a risk involved using normal READ and WRITE operations
Picture this situation : CPU 1 accesses the MEMORY and sets the location pointer to 84 and issues a STOP condition. Now the BUS is FREE. CPU 2 sees this and thinks : okay my turn. He sets the location pointer to 92 because he wants to do something at that location. Now the bus is free again. CPU 1 says : aha ! the bus is free. Time to write for me. Now the data will land on location 92 and not on location 84 as it should have been. So : If you are dealing with memories on a Multimaster bus always use this last method. It keeps you out of trouble.
CON: If you have lots of operations to do you can create a bottleneck situation. The other CPU could be waiting and waiting for a chance to have his turn on the bus.
But is you don't have a MultiMaster environment this all is not necessary.
Congratulations you have reached the EXPERT grade. :-)
Back to Main Index
As stated above you can have more than one CPU on the BUS. When you have only one CPU there are no risks of having collisions on the bus. That situation changes with 2 CPU's.
When CPU 1 issues a START and sends an address the other one will back off. Because of the fact that if the address does not match his own address he has to wait until the bus is free. (STOP condition). So far no problem. But as Murphy is, as usual ,always around. It's when you least expect it that it goes wrong.Fortunately the BUS setup helps us out here.
When you (as a MASTER ) change the state of a line to HIGH , you MUST always check that it has gone to the HIGH level. If it hasn't : BACKOFF ! it's occupied !. Wait for a STOP to occurr and then retry.
What could happen is that the TWO CPU's start communication on the same moment in time.Since it is an open collector/drain bus they can only PULL the line low. They cannot force it HIGH. (they can only leave it HIGH by not turning on their output transistor).
So they start transmitting. And all goes well as long as they both are asserting
the same levels. (during START it's okay.They are doing the same) Then they start
transmitting data. for the first couple of bits all goes well until suddenly diaster
strikes. Bit 3 is different !. CPU1 wants to send a 0 while CPU2 wants to send a 1.
Now CPU 1 has pulled SDA LOW. CPU 2 leaves SDA open. Remeber that you cannot force the Line HIGH It is the job of the pull-up resistor to do that. Since they are both running clean and good written code they are testing what they have put on the BUS. CPU 1 sees that he has written a 0 and says 'okay for me'.. CPU 2 on the other hand sees that the line is LOW while he has left it HIGH ! so he knows that by now someone else has taken control. Time to BACK OFF !.
Now in an ideal world CPU2 would do even more !. When he knows for sure that this is
the first byte after the START generation he will switch from tranmist to receive mode !.
Why ? Well simple: CPU1 might be trying to talk to CPU2 !
If this is the first byte after a START condition this means that it is effectively a
slave address beeing transmitted. CPU2 has to check that this slave address beeing put on
the bus is not his own. If it is not his address he has to wait for the STOP command to
appear on the bus before attempting to take control again. On the other hand. If the
address is his own address he must respond. In the latter case CPU2 becomes the
slave device on the bus. This way all ends up well.
So from the above story we can conclude that is the one that has its line LOW that always wins. The One wich wanted the line to be HIGH when it is beeing pulled low by the other looses the BUS.We call this a 'loss of arbitration' or BACK-OFF. When a BACKOFF situation is generated it is good practice to have the cpu, that has to BACKOFF, wait for a STOP condition to appear on the bus.The other one is still busy transmitting.
The above example showed a situation where the two CPU's were in perfect sync with each other. In most situations this will not be the case. But even then the arbitration will still work. Suppose one of the CPU's missed the START condition and still thinks nothing is going on ... , or it came just out of reset and wants to start talking on the bus. These are real-life cases that WILL happen in a mulitmaster environment. ( remember Murphy's Law !) . Consider a multimaster system that has just been powered up. You will not know which cpu will come out of reset first.
So actually this mechanism does not only do arbitration , it is also very effective at ensuring that the information beeing sent is not lost or corrupted !. The message from the winning CPU is not distorted in any way.
If you struggled trough all of this , and the previous chapters then you are ready to
face the world of MultiMaster I2C
Back to Main Index
Bus synchronisation
The i2c protocol also includes a synchronisation mechanism. This can be used between
masters. However to my knowledge there are no chips that use this mechanism. This must be
implemented in software.
When a slower slave is attached to the bus then problems may rise. Suppose the
following : The master reads a byte from a slave. Lets say an A/D convertor. The slave
needs some time to make a conversion. The master adresses the slave in read mode
--------------------...
|S|READ_ADRESS|WACK|...
--------------------...
In the Wait_for_ack module happens something worth looking at.
In a normal ACQ sequence the slave will pull the ACQ line low immediately after the 8th clock pulse and before the ACQ clockpulse. The master will send a clockpulse , and sample the SDA line during this pulse. If SDA is low it means that the slave aknowledges the information sent. When the ACQ clockpulse is removed the slave releases the SDA line.
Now lets suppose that the slave has detected his home adress. It starts a conversion and waits until this conversion is done before giving acknowledge.That way the master can read the result immediately after the Acknowledge sequence. Of course the master would have timed out and considered the slave not to be present on the bus.
Now the synchronisation meachanism can come in handy. The Slave can pull the SCL low as long as needed. The master is then not able of giving the ACK clockpulse because it cannot raise the SCL line.Of course the master software must check this state. This is the routine the master must execute for a synchronisation aware Wait_for_ack sequence
What happens is this : (in our theoretical model)
The master has sent the last bit of the slave adress on the bus. The slave recognises its adress and pulls the SDA line low. ( it wants to acknowledge because it has detected its adress ). At the same time it starts the A to D conversion and pulls the SCL line low.
The master now wants to start the Wait_for_ack sequence. So it makes SDA high.( Never minding the Slave holding it low )
Now the master releases the SCL line.When testing the level of the SCL line the master will see that it is still low.This is due to the fact that the slave is holding the SCL low.So the master enters a loop that runs until the SCL line effectively turns high. The moment the slave has completed the conversion it releases the SCL line.
The master detects that the SCL has become high and checks the SDa line. Since the slave turned it low long ago it sees a valid acknowledge. The master will now begin to read the result of the conversion.
This technique is used by the serial EEproms on I2C. There are a number of drawbacks involved when implementing this. If the bus 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.
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.
The existing A/D convertors do not use this synchronisation system. They use the following technique :
| Adress chip. Slave will ack and starts new conversion. |
| The master reads a byte and sends stop. |
| This byte is the result of the previous conversion. |
The next time the master reads the chip it will read the value cycle above. Between the 2 accesses the bus is free for the master or another master to access a different slave. When the A/D has not completed conversion it can also simply not ACK. The master Wait_for_ack will timeout and the master will continue. It is the masters task to attempt a retry.
The Synchronisation mechanism is nothing else than a sort of handshaking. In a multimaster environment there is the risk that , when the 2 masters are talking to each other,using this handshake routine, they go into deadlock.
Master 1 attemps to adress master 2. He succeeds.But during the ACK sequence master 2 has to service an interrupt therefore he keeps SCL low. Master 1 will now wait for the SCl line to come high. Master 1 times out (because for some reason master 2 is still busy). Master 1 completes transaction and starts a retry. In the mean time master 2 came on line again and released the SCL line but is still pulling the SDa line low. Result Master 1 cannot start a new transmission. Because it will get a backoff situation ( bus is not free ).Master 1 will get stuck in an endless retry routine. While master 2 will be endlessly waiting for master 1 completing the ACK. Result : System in complete deadlock.
When using the synchronisation mechanism you must take care to avoid all possible
causes of a deadlock.This makes the interface driver very complex.
Back to Main Index
Special addresses and exceptions.
During the above i have mentioned that there are some exceptions about device addressing. Not all addresses can be used. There are some that have been reserved by PHILIPS for special purposes.
address R/W
0000 000 0 : general call
address
0000 000 1 : start byte
0000 001 x : CBUS address
0000 010 x : address
reserved for
different bus
format.
0000 011 x !
0000 100 x !
0000 101 x !} to be defined
0000 110 x !
0000 111 x !
This implements that all addresses below 16 are reserved for special purposes.
The reason behind this is that there are other buses around. Using this scheme you can
connect device that uses a different bus to the I2C bus !. It is possible to put SPI, I2C,
uWIRE and CBUS devices on the same I/O pins of your CPU. Since all buses different to I2C
use 3 lines you can
cut down on you CPU pin load.
How this exactly works would lead us too far. Maybe in the future someone will explain this. If somebody out there has experience with these other buses ? Could be interesting.
| CBUS is the ancestor of I2C. It was also developed by Philips. |
| SPI is (c) Motorola |
| uWIRE is (c) National Semiconductor |
Back to Main Index
Some general notes about these reserved addresses.
The general call address is received by all IC's on the bus. If there is an IC out
on the bus that can process this address it will respond by generating an
ACKNOWLEDGE. See Datasheets for info on which IC use them and why. You could use
this to invoke some special command in a MultiMASTER environment. (Like reboot all CPU's
or whatever. Since all chips will
respond to it ,it can be used for this purpose. However take care not to mess up anything
else.) There have been determined some actions on receipt of the General call address.
When the second Byte in a telegram containing a general call is :
| 00000110 :This is a RESET condition. All IC's capable of handling a general call message will reset and reload their SLAVE address.There are I2C compatible IC that have part of their address programmable.This allows you to have more than one IC of a certain type on your BUS. Further about this later on. They also set all their internal registers to the power-up state. |
| 00000010 :The same as above except that you must provide the SLAVE address.This does not RESET the registers to Power-up state. |
| 00000100 :Causes all IC's that define their address by hardware to reload this value.This does noet reset internal register. |
| 00000000 : PROHIBITED. |
| xxxxxxx1 : This is a HARDWARE general call. You can look to this as a kind of INTERRUPT generated by an I2C IC. |
This can be used in the following condition.: You have a keyboard controller. Each time
a key is pressed it transmits the following sequence :
-------------------------
|S|00000000|A|yyyyyyy1|..
-------------------------
----------------
.. A|Databyte|P|
----------------
Where yyyy yyy is its own address. What will happen is that the MASTER CPU will see the
General call address and see that the device with address yyyy yyy has something to tell
to the CPU. It will read the next byte. In our case the CPU will know that keyboard
controller yyyyyyy has detected a key and that the scancode of this key is contained in
the received databyte.
All other codes have not been assigned. All I2C ic's are designed to ignore them. So you are free to use them for whatever. (I generally use them to debug MultiMASTER modes).
| NO IC is allowed to generate an ACKNOWLEDGE of the START byte. |
| The start byte is used to syncronize Slow devices with fast devices. |
| The CBUS address is used in this way : After sending this address all IC's go into IDLE mode until they receive a STOP condition. In the mean time you can transfer data using a complete different protocol on your I2C bus. |
Back to Main Index
Electrical spec's of the I2C Bus
As the chips designed for an I2C bus can function on different Supply voltages the
following levels have been set.
| LOW level input voltage : -0.5v to 1.5v |
| LOW level relative to VDD : -0.5v to 0.3*Vdd |
| HIGH level input voltage : 3.0v |
| HIGH level relative to VDD 0.7*Vdd to Vdd |
For other electrical specs please refer to the component datasheets. The
number of interfaces connected is limited to the number of available addresses and the
load capacitance on the bus. This capacitance may not be bigger then 400pF. In the new
standard this is preferred to be less than 200pF.
Back to Main Index
Since the first I2C spec release (which dates back from 1982) a couple of improvements have been made.In 1993 the new I2C spec was released.This new spec conatains some additional sections covering FAST mode and 10 -Bit addressing. In this section the Fast mode will be covered , while in the next section information about 10 bit addressing is given.
In the FAST mode the physical bus parameters are not altered. The protocol,Bus levels,Capacitive load etc.. remain unchanged. However the datarate has been increased to 400 Kbit/s. To accomplisch this task a number of changes have been made to timing.
Since all CBUS activities have been canceled ,there is no compatibility anymore with CBUS timing.The development of IC with CBUS interface has been stopped. The existing CBUS ic's are being taken out of production.
The input of the FAST mode devices all include Schmitt triggers to suppress noise. The output buffers include slope control of 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 pullup resitor must be adapted. For loads up to 200 pf a resistor is sufficient.For loads between 200pf and 400pF a current source is preferred.
Due to the increasing popularity of the I2C bus the address space is nearly exhausted.This
starts posing problems for people currently in the phase of designing a new I2C compatible
IC. Therefore the I2C standard has been adapted.
A chip that conforms to the new standard receives 2 address bytes. The first consists
of 5 * a ONE ,the 2MSB's of the address and the Read/Write bit. The second byte contains
the LSB's of the address.
-----------------------
|S|11111A9A8 R/W|WA|...
-----------------------
-----------------------
A7A6A5A4A3A2A1A0|WA|...
-----------------------
This scheme insures that the 0 bit addressing mode stays completely transparent for the
other devices on the bus. Normally any new design should adept to this new addressing
scheme.
Back to Main Index
What is the maximum distance of the bus ?
This depends on the load of the bus and the speed you run it at. In typical applications a few meters (3 to 4). Better: The maximum capacitive load has been specified (electrical Spec's in this FAQ).
If you run at a lower clock frequency then you could go further. If you are careful in routing your PCB's and cabling then you can take it further.I once had an application that had a total of about 100 meter cable in it. The entire system was clocked on something like 500 Hz. I used twisted pair cable and twisted SCL with GND and SDA with VCC. No problem.The systems is now up and running for over 5 years.
If you need to go far at high speed then you can use an active current source . Philips
has a standalone product for this purpose. Or you could build one yourself. 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.
A last thing to be taken care of is the bus termination. Long lines will cause refelections. These reflections can cause 'ghost signals' to appear.This kan be overcome by using a charge pump mechanism like the Philips device has. See also next topic.
I want to extend it ''by the book''. Is there something like a Buffer for I2C ?
Yes indeed this exists. Philips manufactures a special chip to buffer the bidirectional lines of the I2C bus. Typically this is a current amplifier. What it does is force current into the wiring (a couple of mA). That way you can overcome the capacitance of long wiring. Philips P87B715
However You will need this component on oth sides of the line.The charge pump in this devices can deliver currents up to 30mA. And that 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' down this load to a 200pF load which is still acceptable by I2C components. Another possibility is to make such a charge pump yourself. This is fairly easy and can be accomplished by 1 chip and a few resistors. See a bit further on for details.
Can i isolate an I2C bus ? (using optocoupler or whatever)
This is possible. The circuit is rather complex due to the bidirectional nature of the
I2C BUS. Actually there are a number of solutions here. One has appeared in electronic
design new , one is included in the elektor book on i2c and yet another one has been
published in an issue of Elektor. See the end of this FAQ for information on these books.
However : Here it comes (for once channel).
Component Values
1: 270 Ohm
2: 3300 Ohm
3: 1800 Ohm
4: 1000 Ohm
5: PNP like 2n2219 or BC557
6: NPN like 2n2222 or BC 547
Optocouplers : 6n139 , 4n27 or Til 111
A couple of remarks. Since the speed of the I2C bus can be rather high it is reommended 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 2 PNP and 2 NPN transistors can be any standard type. Like 2N2219 and 2N2222 (USA) or BC547 and BC557 (EUROPE).
How does it work ?
The problem with bidirectional lines is that a buffer tends to get stuck on a certain
level. In the above schematic this has been dealth with. In the following explanation we
assume that the left side is transmitting and the right side is receiving.Since the
circuit is symmetrical you could do it the other way around too. Suppose you 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 beeing pulled high via resistors 1' and 3' . The PNP transistor
5' will not get driven. So the Led connected to it will not light. So there is no feedback
signal . So far so good.
Now lets look what will happen if we send a 0. The first transistor 5 will be turned
on. Thus the led connected to it will start emitting light.This results in the fact that
it's matching transistor will turn on . The transistor connected to the Emittor of will be
turned on too. The output line is now beeing pulled low via resistor 3' . This low level
would turn on the PNP transistor. This would result in The other optocoupler to light ,
it's transistor to turn on etc etc .. The circuit would go into a lock-up.
But since the NPN transistor is pulling the Anode of the led to ground this will not
happen. In this way we have eliminated the deadlock.
What if i don't want to emulate the bus by software or if i don't have an I2C interface on my system ? Is there something like an I2C controller ?
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 or computer around.
I am puzzled on how to generate a repeated start condition.
I make the SCK high and my device pulls SDA low to acknowledge. So far no problem but how do i make a new start now ?. The device is pulling SDA low. !
First you have to complete you ACK cycle. To do this you must make SCL low again. The slave will release the dataline when it detects that SCL went logic low. Now you can issue a stop command. To do this you make the SCK high again and then pull low the SDA line. This is the confusing part of the procedure. Normally one would suspect that by making the clock 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.
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. You should test
this before you use it.
Normally when a START or STOP condition is detected the internal logic of the chip is
forced into a certain state. Internally the part that detects START and STOP is differnet
then 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 chip's on the bus will reset their internal logic to IDLE mode. This is also used to cut power consumption. When a STOP is detected all logic is shut down except for the START detector. When a start is issued on the bus the START detector will 'wake-up' the rest of the internal logic.
Do i need to give the ack in read mode on the last byte.
My chip starts sending data and occupies the bus ... .
This is a question that got me puzzled .Indeed this is a bit strange. Normally if you have read the last byte in a chip and generate an ACK the chip should do nothing anymore. So the bus is clear for you to create a STOp condition. Apparently there are some chips that start transmitting data again.
Digging in to to spec showed an error in my FAQ. On the Last byte READ you must generate a NACK (NOT Acknowledge). Check out the description of the READ mode
I read the SDA and SCL are bidirectional.Why does the clock line need to be bidirectional ?
The clock line needs to be directional when using a MULTIMASTER protocol and when using synchronisation protocol. When you are using only one Master then this is not required since the clock will always be generated by the Master and you only have one on the BUS. If you run Multimaster then this changes.The Master must be able to receive data from the other master. At that time it must be able to check the Clock line too. For more information about bus synchronisation check out the topic dedicated to it.
Can i monitor an I2C bus in some way ?
This is possible. There are a few commercial I2C monitor / debuggers around that can do this.Information on these cards can be found elsewhere in this Faq There is another possibility to do this. By using the PCF 8584 chip from philips. This is a universal CPU to I2C interface. This chip has a certain mode in which it takes not part in the real I2C action but unly records what is going on. It listens to all adresses but does not generate an acknowledge.Using some software routines and a small cpu you could make a universal I2C data logger.
Is there a way to test/debug I2C buses ?
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. (
assuming you are running in a 5 volt environment )
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 drive I2C bus is 5volts / 3mA = 1600 Ohms. A typical value of 4700 ohm should do fine.
Make sure the bus is not 'stuck' . This could be the result of a bad power supply
(chips go into latch up during power-on) or a bad chip .
also check the Troubleshooting section
I want to experiment with I2C .Are there demokits available.?
Philips has at least 1 board ( i know of two different boards) for these purposes. It features a bunch of different I2C devices such as EEprom ,digital I/O ,A/D D/A , controllable switch , Real time clock , Ram , Display driver (led and LCD with even an alphanumeric LCD) and also can host a number of their 8051 compatible CPU's.
For people wanting to control I2C from their pc they can either buy a card or build one themselfves. A number of Programs is available to control I2C devices from this interfaces. You can use the Philips / signetics software or use the driver i wrote to control the I2C bus from within your programs.
Are there plug in board available for IBM Pc to emulate I2C ?
There are a number of debugging tools out there which can monitor an I2C bus .
Philips has one of these tools available. Contact you Philips/Signetics representative for
more information.
I2C Bus monitor MIIC-101
Micro Computer Control Corporation
PO Box 275
17 Model Ave
Hopewell New Jersey 08525
USA
Calibre ICA-90 I2C Adapter as IBM PC Plug-in Board
Calibre electronics Ltd
Broomfield House
Bolling Road
Bradford BD4 7BG
England
Also available from Farnell Components Part no : 256-109 cost : approx 350 Us $
In USA you can also contact
Saelig Co.
1193 Moseley Rd
Victor New York 14564
I have problems with long buses. Can i make an active pull-up ?
Absolutely. If you need to go off board however then you should use the P87B715 device
from philips.
for on board you can use following solution. Here comes the Schematic:
Now how does it work ?
First of all Rs. This is a series resistor used to minimize cross talk and undershoot .It also protects the I/O drivers of the I2C devices against overvoltages and overcurrent injection. These resistors are advised if you run a long bus on high speed ( such as in enhanced I2C mode). When the bus becomes free all output stages on the bus are turned off and SCL (or SDa for that matter) become high. This will not happen immediately , but the voltage will rise during a certain time. Now Suppose the switch is not there. The charge time of the bus capacitor is determined by the value of R1 only . The higher one of them is the longer it will take for the bus to reach a sufficient stable High level. We can't make the Series resistor too small because then we will go out of spec on the maximum allowable current into one I2C device when it turn's it's output driver on.
When we calculate for a current of 3ma we end up at approx 1800 ohms for the series
resistance. 5volts / 3ma = 1666 Ohms .
To stay somewhere below this 3mA rating we take 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 Max
current.
Now if we had a means to change the value of the resistor temporarily.... And that's
exactly what is done with the Analog Switch. If the voltage level sensed by the switch is
in the range 0.8 to 2 volts then it will turn on. Meaning that the moment the voltage on
the SDa line starts rising , this resistor will kick in and increase charge current to a
value of 5volts/(1K8//1K2) =
720 Ohms. the charge current will then rise to 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.
A small graphical representation will explain more:
Wave 1 represents the turn off of the I2C device.So the bus must go to a logic 1
Wave 2 is the what you get if you only use a resistor. The bus 'slowly comes up to 5 volts
due to the RC constant of Rpull-up and Cparasitic
Wave 3 shows the kicking in of the Analog switch. If the bus gets at approx 0.7 volts it
kicks in and kicks out when the bus reaches approx 3 volts
Wave 4 is how the voltage on the bus changes. You can clearly see that it rises much
faster when the switch is turned on.
And finally wave 5 show the current flowing into the I2C device. It starts at approx 3mA.
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 kick's in you see the current double. 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 withing the 300nS. Rise time.
This section covers a sample I2C driver. Currently Version 1.1
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.
| Basic functions |
 | I2C_init : initializes I2C bus |
| Start : Sends a Start condition |
| Stop : Sends a stop condition |
| PutByte : Sends a Byte |
| GetByte : reads a Byte |
| GiveAck : Gives ACK to slave |
| GetAck : Gets ACK from slave |
| Read : Reads a byte from an address |
| Write : Writes a byte to an address |
| Randomread : Reads a block of data |
| RandomWrite : Writes a block of data |
/$$$$$$$$$$$$$$$$$$$$$$$$$$$/
/**** I2C Driver V1.1 ****/
/ Written by V.Himpe. /
/ Released as Public Domain /
/$$$$$$$$$$$$$$$$$$$$$$$$$$$/
DECLARE N,SIZE,BUFFER,X Byte
DECLARE DATA(size) Array
SUBroutine I2C_INIT
SDA=1
SCK=0
FOR n = 0 to 3
CALL STOP
NEXT n
ENDsub
Back to Driver
SUBroutine START
SCK=1
SDA=1
SDA=0
SCK=0
SDA=1
ENDsub
Back to Driver
SUBroutine STOP
SDA=0
SCK=1
SDA=1
ENDsub
Back to Driver
SUBroutine PUTBYTE(BUFFER)
FOR n = 7 TO 0
SDA= BIT(n) of BUFFER
SCK=1
SCK=0
NEXT n
SDA=1
ENDsub
Back to Driver
SUBroutine GETBYTE
FOR n = 7 to 0
SCK=1
BIT(n) OF BUFFER = SDA
SCK=0
NEXT n
SDA=1
ENDsub
Back to Driver
SUBroutine GIVEACK
SDA=0
SCK=1
SCK=0
SDA=1
ENDsub
Back to Driver
SUBroutine GETACK
SDA=1
SCK=1
WAITFOR SDA=0
SCK=0
ENDSUB
Back to Driver
/ this concludes the lowlevel/
/ set of instructions for the/
/ I2C driver. The next /
/ functions will handle the /
/ telegram formatting on a /
/ higher
level
/
SUBroutine READ
(Device_addr,Number_of_bytes)
Device_addr=
Device_addr OR (0000.0001)
/ 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
IF X< Number_of_bytes THEN
CALL GIVEACK
END IF
NEXT x
CALL STOP
ENDsub
Back to Driver
SUBroutine WRITE
(Device_addr,Number_of_bytes)
Device_addr=
Device_addr AND (1111.1110)
/ This clears READ flag /
CALL START
CALL PUTBYTE(Device_addr)
CALL GETACK
FOR x= 0 to Number_of_bytes
CALL PUTBYTE (DATA(x))
CALL GETACK
NEXT x
CALL STOP
ENDsub
Back to Driver
SUBroutine RANDOMREAD
(Device_addr,
Start_addr,
Number_of_bytes)
Device_addr=
Device_addr AND (1111.1110)
/ This clears READ flag /
CALL START
CALL PUTBYTE(Device_addr)
CALL GETACK
CALL PUTBYTE(Start_addr)
CALL GETACK
CALL START
Device_addr=
Device_addr OR (0000.0001)
/ This sets the READ FLAG /
CALL PUTBYTE(Device_addr)
CALL GETACK
FOR x= 0 to Number_of_bytes
CALL GETBYTE
DATA(x)=BUFFER
CALL GIVEACK
NEXT x
CALL STOP
ENDsub
Back to Driver
SUBroutine RANDOMWRITE
(Device_addr,
Start_addr,
Number_of_bytes)
Device_addr=
Device_addr AND (1111.1110)
/ This clears READ flag /
CALL START
CALL PUTBYTE(Device_addr)
CALL GETACK
CALL PUTBYTE(Start_addr)
CALL GETACK
FOR x= 0 to Number_of_bytes
CALL PUTBYTE (DATA(x))
CALL GETACK
NEXT x
CALL STOP
ENDsub
Back to Driver
/ $$$$$$$$$$$$$$$$$$$$$$$$ /
/ End of the I2C Driver . /
/ $$$$$$$$$$$$$$$$$$$$$$$$ /
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 multiread ? 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. 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 adress 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
to process. When you give the devices adress 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.
Back to Main Index
So you have an I2C bus and you want to monitor activity. Using a regular scope this is
rather tough. When you are in control then you can easily generate a trigger for the
scope. If you are not in control ( in a TV set or other equipment ) then things
get more complicated. The tools described in this section should provide some easy means
to solve these problems.
I2C trigger generator.
This simple circuit allows any scope to trigger on an I2C transmission. Each time a start
condition is detected the output of the flipflop will generate a pulse that can be used to
trigger a scope..
The SCL and SDA are not connected wrong in the above schematic. You have to cross them in
order for the circuit to detec the Start. Remember that Start means : a falling edge on
SDA when SCL is high. And that is exactly what this circuit detects.
Checking who is controlling the bus.
To see who is actively pulling the bus low can be done using a simple resistor.
The low level generated by a slave will be lower then the low level generated by the
master. this is easily recognizable on an oscilloscope. That way you can examine whis
actually driving the bus. you could do the same for the clock line. then you can even look
into multimaster environments.
Back to Main Index
I2C interfacing system for IBM-PC.
This section covers a complete I2C experimenting system for the IBM PC. In this section i
will set up an environment to experiment with I2C.
The schematic is almost the same as the Schematic provided by Philips. As a matter of fact it is the same.A little addition has been made. However it is 100% compatible with the philips driver schematic. This was done so you can use it both with tools like TV400 from Philips and with my driver.
SCL and SDA speak pretty much for themselves. The trig Output is an addition i
made to the original schematic. When used with the driver described below it is able
to trigger an oscilloscope. Each time a Start condition occurs the trig output generates a
pulse.This will make it easier to monitor bus activity when experimenting wth the system.
You can write a loop that keeps doing the same over and over again. When you connect SCL
and SDa to channels X1 and X2 of the scope and the TRIG
to the Trigger input. You can see the transfer on the bus.
Back to Main Index
This module can be used with the programs developed by philips and available from their FTP site or from the internet.
Programs are TV400.ZIP and RAD216.ZIP. These contain a complete bus control terminal.
You can monitor bus activity
and also actively control lots of standard chips.It comes with libraries for nearly
all Philips IC's available. You can also control Non-Philips ic by using the
universal bus interface.
Back to Main Index
Quickbasic / PDS / POWERBasic Driver
This describes a set a routines written Basic that allow you to run an I2C bus over a standard printerport. The program is written in such a way that it can be run on different platforms without ( or with minor ) modifications.
' ****************************
' * I2CDRIVE I2C Bus Driver
' * (c)1995-2000 Vincent Himpe
' * Features ICee Debugger
' * Released as PUBLIC DOMAIN.
' * Use as you please
' * This driver can be used
' * in Quickbasic ,PDS and
' * PowerBasic
' * PowerBasic users must kill
' * the 'Sub DELAY' since
' * powerbasic has this
' * feature.
' ****************************
' * ICee Debugger.
' * If during run of the
' * program the computer beeps
' * this means that an adressed
' * chip is not responding.
' * Turn on the debugger by
' * issuing the I2CDebugOn
' * command immediately after
' * opening the bus and rerun
' * the program. You will get
' * detailed error information
' ****************************
DIM ICdta(10)
COMMON SHARED I2CLoPort,
I2Cmidport,
I2CHiPort,
I2Csavedstatus,
SCL,
SDA
COMMON SHARED I2Cdebug,
I2Ctimeout,
I2Cdevadr%,
I2Cresult%,
ICdta(), hold
' powerbasic users must replace
' COMMON SHARED by PUBLIC
hold = .001
' do not adapt this value.
' Adapt the value in DELAY
' $$$$$$$$$$$$$$$$
' $ Sample program
' $$$$$$$$$$$$$$$$
I2Copen 0, 1
' open port &h378 (LPT1)
' with ICee enabled
I2Cinit 10
' set a timeoutvalue
CLS
I2Cwrite 192, 12
' write '12' to device
' with adress 192
a = I2Cread(193)
' read a byte from
' the same device
I2Cwwsend 200, 1, 7
' write '7' to register
' '1' of device at adress
' 200
a = I2Cwwread(201, 1)
' read register 2 of
' device at 200
I2Cmultiread 200, 3
' read first 4 registers
' (0..3) of the slave at
' address 200
FOR a = 0 TO 3
PRINT ICdta(a)
NEXT a
END
' ----------------------------
SUB delay (count)
' Notice about this routine.
' When using powerbasic you
' must delete this routine
' in its entirity. It is
' needed for Qbasic only.
FOR a = 0 TO (count * 1000)
' adapt this value according
' to the CPU speed
NEXT a
END SUB
' ----------------------------
SUB holdsystem
' Freezes the system so you
' can read ICee debugger
' messages
CALL messg(" Press key ")
DO
a$ = INKEY$
LOOP UNTIL a$ <> ""
END SUB
' ----------------------------
SUB I2Cclose
' Closes the I2C driver.
' This resets the LPT port
OUT I2CHiPort,I2Csavedstatus
OUT I2CLoPort,127
END SUB
' ----------------------------
SUB I2Cdebugoff
' Turns off the I2C debugger
CALL messg("ICee DISABLED ")
I2Cdebug = 0
END SUB
' ----------------------------
SUB I2Cdebugon
' Turns the debugger on
CALL messg("ICee ENABLED ")
I2Cdebug = 1
END SUB
' ----------------------------
SUB I2Cgenstart
' transmits a start
IF I2Cdebug = 1 THEN
CALL messg("START")
END IF
' start of transmission
OUT I2CLoPort, 127
delay hold
OUT I2CHiPort, 8
delay hold
OUT I2CLoPort, 255
delay hold
OUT I2CLoPort, 255
delay hold
OUT I2CHiPort, 0
delay hold
END SUB
' ----------------------------
SUB I2Cgenstop
' transmits a stop
IF I2Cdebug = 1 THEN
CALL messg("STOP")
END IF
OUT I2CLoPort, 255
delay hold
OUT I2CLoPort, 255
delay hold
OUT I2CHiPort, 8
delay hold
OUT I2CHiPort, 8
delay hold
OUT I2CLoPort, 127
delay hold
END SUB
' ----------------------------
SUB I2Cgiveack
' Gives an ACK to a slave
OUT I2CHiPort, 0
delay hold
OUT I2CLoPort, 255
delay hold
OUT I2CHiPort, 8
delay hold
OUT I2CHiPort, 0
delay hold
OUT I2CLoPort, 127
delay hold
END SUB
' ----------------------------
SUB I2Cinit (timeout)
' aborts transmission and
' clears bus
FOR I2Ca% = 0 TO 5
OUT I2CLoPort, 255
delay hold
OUT I2CHiPort, 8
delay hold
OUT I2CLoPort, 127
delay hold
OUT I2CHiPort, 0
delay hold
NEXT I2Ca%
I2Ctimeout = timeout
OUT I2CHiPort, 8
delay hold
END SUB
' ----------------------------
SUB I2Cmultiread (adr%, count%)
' performs a multiread
adr% = (adr% OR 1)
I2Cdevadr% = adr%
CALL I2Cgenstart
CALL I2Ctransmit(adr%)
CALL I2Cwaitforack
I2Cdevadr% = 0
FOR i% = 0 TO count%
CALL I2Creceive
IF il% < count% THEN
CALL I2Cgiveack
END IF
ICdta(il%) = I2Cresult%
NEXT il%
CALL I2Cgenstop
END SUB
' ----------------------------
SUB I2Copen (port%, dbug%)
' Always call this before
' any other routines !
SELECT CASE port%
CASE 0
I2CLoPort = &H378
I2Cmidport = &H379
I2CHiPort = &H37A
CASE 1
I2CLoPort = &H278
I2Cmidport = &H279
I2CHiPort = &H27A
CASE 2
I2CLoPort = &H3BC
I2Cmidport = &H3BD
I2CHiPort = &H3BE
END SELECT
I2Csavedstatus = _
INP(I2CHiPort)
IF dbug% = 1 THEN
I2Cdebug = 1
ELSE
I2Cdebug = 0
END IF
END SUB
' ----------------------------
SUB I2Cpob
' puts bits on the bus
IF SDA = 1 THEN
OUT I2CLoPort, 127
delay hold
ELSE
OUT I2CLoPort, 255
delay hold
END IF
IF scl = 1 THEN
OUT I2CHiPort, 8
delay hold
ELSE
OUT I2CHiPort, 0
delay hold
END IF
IF I2Cdebug = 1 THEN
END IF
END SUB
' ----------------------------
FUNCTION I2Cread (adr%)
' reads a byte
adr% = (adr% OR 1)
I2Cdevadr% = adr%
CALL I2Cgenstart
CALL I2Ctransmit(adr%)
CALL I2Cwaitforack
I2Cdevadr% = 0
CALL I2Creceive
CALL I2Cgiveack
CALL I2Cgenstop
I2Cread = I2Cresult%
END FUNCTION
' ----------------------------
SUB I2Creceive
' receives a byte
IF I2Cdebug = 1 THEN
CALL messg("Receiving")
END IF
I2Cresult% = 0
OUT I2CLoPort, 127
delay hold
FOR I2Ca% = 7 TO 0 STEP -1
I2Cb% = 2 ^ I2Ca%
OUT I2CHiPort, 8
delay hold
I2Cin% = _
(INP(I2Cmidport) AND 128)
OUT I2CHiPort, 0
delay hold
IF I2Cin% = 128 THEN
I2Cresult% = _
I2Cresult% + I2Cb%
PRINT "1";
ELSE
PRINT "0";
END IF
IF I2Ca% = 4 THEN _
PRINT " ";
NEXT I2Ca%
PRINT
END SUB
' ----------------------------
SUB I2Csettimeout (tme)
' assigns a timeout value
I2Ctimeout = tme
END SUB
' ----------------------------
SUB I2Ctransmit (byte%)
' transmits a byte
IF I2Cdebug = 1 THEN
CALL messg("Transmitting")
END IF
I2Ca% = 0
FOR I2Ca% = 7 TO 0 STEP -1
I2Cb% = 2 ^ I2Ca%
IF (byte% AND I2Cb%) =_
I2Cb% THEN
OUT I2CLoPort, 127
delay hold
ELSE
OUT I2CLoPort, 255
delay hold
END IF
OUT I2CHiPort, 8
delay hold
OUT I2CHiPort, 0
delay hold
NEXT I2Ca%
OUT I2CLoPort, 127
delay hold
END SUB
' ----------------------------
SUB I2Cwaitforack
' waits for slave acknowledge
IF I2Cdebug = 1 THEN
CALL messg("Wait for ACK")
END IF
OUT I2CLoPort, 127
OUT I2CLoPort, 127
delay hold
OUT I2CHiPort, 8
OUT I2CHiPort, 8
delay hold
acknowledge = 0
acktimer = 0
WHILE acknowledge = 0
acktimer = acktimer + 1
I2C.mon = _
(INP(I2Cmidport) _
AND 128)
IF I2C.mon <> 128 THEN
acknowledge = 1
END IF
IF acktimer = _
I2Ctimeout THEN
acknowledge = 1
IF I2Cdevadr% <> 0 THEN
IF I2Cdebug = 1 THEN
CALL messg("No device")
CALL holdsystem
ELSE
BEEP
END IF
ELSE
IF I2Cdebug = 1 THEN
CALL messg("No ACK")
CALL holdsystem
ELSE
BEEP
END IF
END IF
END IF
WEND
OUT I2CLoPort, 127
OUT I2CLoPort, 127
delay hold
OUT I2CHiPort, 0
OUT I2CHiPort, 0
delay hold
END SUB
' ----------------------------
SUB I2Cwrite (adr%, dta%)
' writes a byte to a slave
adr% = (adr% AND 254)
I2Cdevadr% = adr%
CALL I2Cgenstart
CALL I2Ctransmit(adr%)
CALL I2Cwaitforack
I2Cdevadr% = 0
CALL I2Ctransmit(dta%)
CALL I2Cwaitforack
CALL I2Cgenstop
END SUB
' ----------------------------
FUNCTION I2Cwwread _
(adr%, sbadr%)
adr% = (adr% OR 1)
I2Cdevadr% = adr%
CALL I2Cgenstart
CALL I2Ctransmit(adr%)
CALL I2Cwaitforack
I2Cdevadr% = 0
CALL I2Ctransmit(sbadr%)
CALL I2Cwaitforack
CALL I2Cgenstart
adr% = adr% + 1
CALL I2Ctransmit(adr%)
CALL I2Creceive
CALL I2Cgenstop
I2Cwwread = I2Cresult%
END FUNCTION
' ----------------------------
SUB I2Cwwsend _
(adr%, sbadr%, dta%)
' writes with subadress
adr% = (adr% AND 254)
I2Cdevadr% = adr%
CALL I2Cgenstart
CALL I2Ctransmit(adr%)
CALL I2Cwaitforack
I2Cdevadr% = 0
CALL I2Ctransmit(sbadr%)
CALL I2Cwaitforack
CALL I2Ctransmit(dta%)
CALL I2Cwaitforack
CALL I2Cgenstop
END SUB
' ----------------------------
SUB messg (dta$)
' shows the ICee messages
PRINT dta$
END SUB
' ----------------------------
Legal Notes and Copyrights.
Standard Philips Copyright notice :
' Purchase of Philips I2c components conveys a licence under the Philips I2C
patent to use the components in the I2C system provided the system conforms to the
I2C specifications defined by Philips '
Back to Main Index
One offspring of the I2C BUS is the ACCESS Bus. This bus was co-developed by Philips, Signetics, Digital and Intel.The goal was to create a bus that could help us getting rid of all cabling involved with computer peripherals. You would have 1 bus connector where you could hook up your keyboard,mouse,digitizer,scanner,printer,monitor etc.
Then by using sotware you could issue commands to your monitor or printer.Things like selecting fonts or programming brightness and picture size could be done from within software on the host platform. Things like Hotplugging are included in the standard.There has been a chip developed that could replace the standard 8042 (which is the keyboard controller in an ibm PC) by an access bus controller. Digital is using the bus in its Alpha based machines. Sony and some other manufacturers have monitors that support the remote programming features.Microsoft will support the bus fully . (Windows 95).
Basically the hardware layer of the access bus is an I2C bus. All that has been done is implementing a software protocol to provide additional functionality to the system.
This bus gas never gained any support due to the lack of performance. The idea was good
but the speed was not available. Out of this idea the USB was developed. The basic
mechanisms in I2C have been modified and taken to a new level. While the physical layer is
different , the sync mechanisms , the handshaking , addressing , and multimaster mode is
an improvement of the I2C bus.
Back to Main Index
You might not realise it but every motherboard using Pentium II and later processors has
an I2C bus on board !. This bus is used for so called system management. This ranges from
voltage detectors on the motherboard , temperature monitors in the CPU to the
configuration paramteres for your memory. Todays DIMM memory modules have a small I2C
EEPROM onboard that hold the timing information for the memory. This information is read
during boot. The Slot One packaged processors have an I2C interface to read out the
temperature of the CPU !.
In portable computers the bus is even more used. the little Trackball , TouchStick or
Glidepoint all use I2C to transmit mouse coordinates !. Smart harddisk boast I2C buses.
The Battery in a notebook can have an I2C bus that is used to read voltage , temperature
and battery information. this bus is accessible via port &H80 in your computer. DO NOT
MESS WITH IT !. If you have no clue how it works don't use it. Find documentation first. !
You can screw up the motherboard or other peripherals .
Back to Main Index
SOURCES OF INFORMATION ABOUT I2C
The following is a list of the various anonymous ftp sites that carry tools and examples about I2C and how to implement it. There are many others that are not listed here that contains bits and pieces. Usually you can find them using Archie and searching for "I2C","ACCESS BUS" and stuff like that.
| ftp.funet.fi (nic.funet.fi) |
| /pub/compilers/8051 |
| /pub/microprocs/MCS-51 |
Web pages
| http://www.hut.fi/~iisakkil/stuff.html |
| http://www.ramtron.com |
| http://www.siemens.com |
| http://www.ping.be/electrozone |
Back to Main Index
I2C products
This section includes descriptions and references to free and commercial software for the
I2C Bus and lookalikes.FTP sites and BBSs contain many quality packages and code samples
for free. For heavy duty use, you might prefer the many commercial packages that are
available.With the public domain (or free) stuff, you're usually on your own. The
commercial packages usually provide extensive documentation and support.
The following is a list of development tools that exist on the net.
IBM PC program to control I2C bus from the printer port.
Program: TV312.EXE / TV400.EXE / I2CRAD.EXE
Description: Control program by Philips Semiconductors for I2C bus.
Location: ftp.pppl.gov : /pub/8051/signetics-bbs
ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs
The same site has lots of APP notes on i2C and how to implement it on 8051 and 68000 compatible CPU's.
Commercially available products
Philips Microcontroller Product Group
811 East Arques Ave. / POB 3409
Sunnvale, CA 94088-3409
Technical documentation:
Sunnyvale, CA - (800)447-1500 Fax: (408)991-3773
Eindhoven, Netherlands - Fax: 31-40-724825
A set of development boards for the I2C bus :
S87C00KSD I2C evaluation Board
OM1016 I2C demo board with CPU and a number of peripherals like
I/O, AD/DA, LCD, RAM, EEprom, CLOCK, DTMF, IR receiver etc..
OM1018 Manual for the above.
OM1020 LCD and driver demoboard.
OM4151 Similar to OM1016 but without IR link.
OM4160 68070 based demoboard.
OM1022 I2C bus analyser. Hard and software for IBM PC.
Back to Main Index
Periodicals that sometimes have articles about I2C
Various magazines and journals (journals seems to be THE popular name for magazines these days) provide articles from time to time on the I2C bus
The Computer Applications Journal (Circuit Cellar Ink)
- programming and construction articles
- POB 7694, Riverton, NJ 08077-8784
- FAX: (203)872-2204
- Voice orders: (609)786-0409
- On-line orders (BBS): (203)871-1988
- Email orders: [email protected]
Electronic Engineering Times
- industry announcements and trends
- FREE to qualified engineers and managers involved in
engineering decisions
- Fulfillment Dept., PO Box 9055, Jericho, NY 11753-8955
- FAX: (516)733-6960
Electronics Now
- construction articles
- Box 55115, Boulder, CO 80321-5115
- $19.97 one year
Elektor Electronics
- programming and construction articles
- World Wide Subscription Service Ltd
Unit 4, Gibbs Reed Farm, Pashley Road
Ticehurst TN5 7HE, England
- 27 UK pounds
or
- Old Colony Sound Lab, P.O. Box 243, Peterborough, NH 03458
- Tel. (603)924-6371, 924-6526
- Fax: (603)924-9467
- $57 USA and Canada per year
Back to Main Index
Books on I2C
I don't have information on all of these, only that they exist. I would greatly
appreciate it if someone could provide a short synopsis and the complete book name if you
are familiar with any of these titles.
Data book / Handbook / Users' Guide
- Philips I2C devices Handbook
- 8051 Handbook from philips (contains also complete I2C spec)
pub no : 9397-750-00013
- I2C peripherials for microcontrollers.
98-8080-574 (Philips ord.nr)
Currently depleted.Sheduled for reprint in august
IC01 Semiconductors for Radio and Audio systems
IC02 Semiconductors for TV and Video systems.
IC03 Semiconductors for Telecom systems
IC14 8048 based microcontrollers
IC20 8051 based microcontrollers
Le BUS I2C (in FRENCH !!)
By Dominique Paret
Dunod Technique ISBN 2-10-001717-9
De I2C bus. ( in DUTCH )
Published by Elektor from The netherlands
Currently only available in Dutch. ENglish translation upcoming.
ISBN .......
Philips Data Sheet on the I2C Bus * Free *
Order # 98-8080-575-01
by Mail
Philips semiconductors ! Philips Semiconductors
811 East Arques Anenue ! Literature distribution centre
PO BOx3409 ! 1000 Business centre drive
Sunnyvale California 94088-3409 ! Mount Prospect IL 60056
Or by FAX 1-708-296-8556
Phone 1-800-234-7381
Back to Main Index
Right. So you have built your first system using the I2C bus and you find out that it doesn't work as it should. So what do we do now ? This section covers a few of the common pitfalls involved in using the bus.
First thing to check is : Are the pull-up resistors connected.?
Probably the most common error is that people forget to connect a pull-up resistor between
SDA and VCC and SCL and VCC. Remember : SDA and SCL are open collector or open-drain
lines. Resistance value should be between 4K7 and 47K.
The longer you make your lines the lower the resistance value should be. This is to force more current into the lines to overcome the capacitance formed by the lines. (This is very important if you want to run on high speeds)
Check that the lines can be toggled between the logic levels. Check that the levels on both SDA and SCL fall into the allowed range. Check this both for high and low levels. Maybe there is a short circuit that straps one of the lines to VCC or GND.
By now you should have a bus that is capable of transporting I2C signals. Now you can try to send some information to a chip or read some information It is best to connect only one slave device to the I2C bus.
The chip is not responding.
Check following things in order Are SCL and SDA connected correctly ? Are you accessing the right address ? Has the start command been issued correctly ?.
If you have a storage scope you can monitor the bus by connecting Channel 1 to SDA and channel 2 to SCL. Set the scope on Single shot trigger on channel 2. Set pretrigger to1division. Or you can build the trigger circuit described in this FAQ under 'debugging tools'.
If you don't have a scope you can use another trick. Send the start command plus the
slave address .Now make the SCL line
high . Your Master is now waiting for ACK from the slave device. You can connect a
led + resistor between VCC and SDA. If the led does not light then something is wrong.
Send a couple of stop commands and then try again.It is possible that the chip is locking up due to power-on effects. Replace the chip. It could be defective.
If here it still does not work you have a problem in the I2C protocol. Check that the START , ACQ and STOP sequences are correct. Also verify that the data transmitted is correct. MSB first.
When you got it talking you can connect the other devices one by one. Each time try to access them.
Sometimes I get strange results. Reading a device a couple of times ends up with different data all the time. Writing does not give predictable results. Sometimes the bus even locks up.
The most logic explanation here is that you have a problem with the bus signals. They are either not high enough or noisy. Or the capacitance on the bus might be so high that the edges of the signals become too slow. decrease the pull up resistance. ( start by connecting half of the value. ) This should improve the problem.
Another possibility is that you have 2 chips on the same address. This can happen. Example : You have a circuit that uses 2 PCF8574 I/O ports. In your hurry you forget to wire them for different addresses. (You can have up to 8 of these in your circuit)
This FAQ compiles for a last time all i know about the I2C bus. Over time i got in touch with a lot of people , amongst them the people who designed the bus , people from Hewlett Packard , Synaptics and lots of other companies. I would like to extend greetings to those people. They had interesting problems and it was fun solving them. But the line has to stop somewhere.
I hope this FAQ may help someone out there.
Have a good life.
Vincent.