Author: Vincent Himpe
E-mail: Vincent.himpe@ping.be
Last-modified: 08 Jul 1995
Version: 1.3
Archive-name: I2C-BUS-FAQ
My signature:
--------------------------------------------------------------
Vincent Himpe
/////
Internet: O *)
vincent.himpe@ping.be /
vi_himpe@mietec.be \__/
Fido:
2:291/1912.8
You can visit my Homepages: http://www.ping.be/~ping0751
God has put me on earth to do a certain number of things.
Right now I'm so far behind I'll probably never die.
--------------------------------------------------------------
"Extracted from The I2CFaq (c) Vincent Himpe. Posted in SCI.ELECTRONICS"
Some sections have been re-arranged or partially re-written. Some new sections give an address list and roadmap to I2C devices (which is not complete for the moment. Only Philips devices are incorporated. More to come in the next release).
[filipg - the next paragraph does NOT apply to THIS HTML version of this FAQ. This version comes in ONE part]
Furthermore the FAQ has been split into 2 pieces. This is due to the fact that some Usenet tools have problems accessing files larger then 64Kbyte. (Current FAQ is over 75 Kbytes long).
There is also a Q&A section and troubleshooting guide. These two are based on questions I got from people who start to use the bus.
I get lots of replies from people that want to know if this faq has been archived yet. Well it hasn't. I have two problems here.
The 'hull' of this FAQ was taken from the 8051-FAQ by Russ Hersh. Also check out that one. It's a great lead for people interested in I2C. Lot's of 8051 clones have an I2C controller on board. Hope its useful to you guys and girls out there.
Keep those replies coming
Regards,
Vincent
English is not my natural language but I guess you figured that one out already.
You can contact me:
By e-mail: Internet : Vincent.himpe@ping.be (preferred)
vi_himpe@mietec.be
Fido : 2:291/1912.8
By Snail-Mail: Vincent Himpe
A.De Taeyelaan 12
8792 Desselgem
Belgium
If you are a manufacturer and have an anonymous ftp site or BBS available that has information and/or tools for the I2C Bus please let me know by EMail so that I can add it to this FAQ. Also, please feel free to update me on new products.
comp.protocols.misc
sci.electronics
The schedule for posting will be once a month. I can't promise that it will be on time, but I hope to post it by the end of each month.
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 non-commercial 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 as posted in SCI.ELECTRONICS."
Thank you.
Subject: PIC microcontrollers
Newsgroups: comp.realtime
comp.robotics
sci.electronics
Maintainer: Tom Kellett
Tom@takdsign.demon.co.uk
Subject: 68hc11 microcontrollers
Newsgroups: comp.realtime
comp.robotics
sci.electronics
Archive: rtfm.mit.edu: <plus all mirror sites>
/pub/usenet/comp.answers/microcontroller-faq/68hc11
/pub/usenet/sci.answers/microcontroller-faq/68hc11
/pub/usenet/news.answers/microcontroller-faq/68hc11
Maintainer: Russ Hersch
Email: sibit@datasrv.co.il
Subject: Microcontroller primer and FAQ
Newsgroups: comp.sys.intel
comp.realtime
comp.robotics
sci.electronics
alt.comp.hardware.homebuilt
Archive: rtfm.mit.edu: <plus all mirror sites>
/pub/usenet/comp.answers/microcontroller-faq/primer
/pub/usenet/sci.answers/microcontroller-faq/primer
/pub/usenet/news.answers/microcontroller-faq/primer
Maintainer: Russ Hersch
Email: sibit@datasrv.co.il
Subject: Robotics
Newsgroups: comp.robotics
Maintainer: Kevin Dowling
(412)268-8830
Email: nivek@ri.cmu.edu
Smail: Carnegie Mellon University
The Robotics Institute
Pittsburgh, PA 15213
Subject: Electronics
Newsgroups: sci.electronics
Comments: There are a number of FAQs available in this newsgroup
on various subjects. Among some of the subjects covered
are: LCDs, stepper motors, etc
FAQ subject: Real-time
Newsgroups: comp.realtime
comp.answers
news.answers
Archive: rtfm.mit.edu: pub/usenet/comp.realtime
Maintainer: Mark Linimon
Lonesome Dove Computing Services
Roanoke, Virginia
Email: linimon@nominil.lonesome.com
Subject: Motorola 68K microprocessor line
Newsgroups: comp.sys.m68k
Archive: bode.ee.ualberta.ca : pub/motorola/general
ftp.luth.se : /pub/misc/motorola/faq
file name of archive is m68kfaq?.zip (? is version)
Maintainer: Robert Boys - Ontario, Canada
Email: r.boys@genie.geis.com
or
fboys@uoguelph.ca
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. 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. It's name literally explains it's 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. Offspring like D2B and ACCESS bus find their ways into computer peripherals like keyboards, mice, printers, monitors, etc. The I2C BUs has been adopted by several leading chip manufacturers like Xicor, SGS-Thomson, Siemens, Intel, TI, Maxim, Atmel, and Analog Devices.
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 it's 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:
-------- ------------
| CPU |-----------o--------| I/O port |
-------- | ------------
|
| ------------
+--------| Memory |
------------
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 response on the ACKNOWLEDGE signal of the CPU.
The ACKNOWLEDGE signal is issued by the CPU. When the chip which 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, and 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 physically is going on.
/| | Note 1
--o< |--+ |
\| | |
|---O
| |
| |
|-+ |
------| |
|-+ |
| | Note 2
--- |
/// |
SDA H ------\ The chip issuing the Start condition first pulls
L \------- the SDA (data) line low. And next
pulls the SCL (clock) line low.
SCL H ---------\
L \----
A Stop is just the mirror of the above.
SDA H /---- The Bus master first releases the SCL and then
L ---------/ the SDA line
SCL H /-------
L ------/
The start condition acts as a signal to all connected IC's that something is about to be transmitted on the BUS. The Stop condition tells the connected chips that the message has been completed.
SDA H /----------\
L -----/\----------/\-------
SCL H /----\
L --------/ \----------
This is necessary because not all chips on the bus are EDGE driven. The DATA must stay valid during the HIGH level of the CLOCK pulse. The only time the DATA line is allowed to change during the HIGH state of the clock is in a START or STOP condition.
Using the above information, a transfer could look like this:
SDA H -\ /---\ /---\ /---\ /---\ /---
L \-----/ \---/ \--------/ \-------/ \----/
SCL H ----\ /-\ /-\ /-\ /-\ /-\ /-\ /------
L \---/ \-----/ \---/ \--/ \--/ \--/ \--/
| START | 1 | 1 | 0 | 1 | 0 | 1 | STOP
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.
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.
Waiting for ACKNOWLEDGE.
When a chip is being addressed or has received data it will issue an ACKNOWLEDGE pulse. Therefore the MASTER must release the DATA line (set it to high level) and then release the CLOCK line. Now it must wait for the SLAVE to pull the DATA line low. Actually on the bus this looks like a START condition so nothing happens because of the fact that the IC's that have not been addressed are doing nothing.(they are waiting for a STOP condition remember ?)
When the SLAVE has pulled this line low the MASTER will take the CLOCK line low and then the SLAVE will release the SDA (data) line.
Now that the MASTER knows that the SLAVE is actually there it can continue. Generally the MASTERs (mainly CPUs 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.
This is how theoretically it should work
SDA H -\ /--------------------------------\ /--------
L \-/\--------------------------------/\------/\--------
SCL H ----\ |-| |-| |-| |-| |-| |-| |-| |-| |-| |-| |-| |
L \-| |-| |-| |-| |-| |-| |-| |-| |----| |---| |-| |-|
START | | |
| | |
| | |
addressed SLAVE pulls SDA LOW ---+ | |
CPU checks if SDA is LOW -------+ |
addressed SLAVE releases SDA ------------+
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 occurring. 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 it's array. It leaves the SDA line in the HIGH state until this action has been completed.
I have once spend a whole day figuring 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:
I figured 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 successfully. 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 ADRESS | WA | DATA | WA | P |
-----------------------------------------
---------------------------------------------------------------------
| S | SLAVE ADDR | WA | DATA | WA | DATA | WA |.....| DATA | WA | P |
---------------------------------------------------------------------
Note: S = START
WA = WAIT FOR ACKNOWLEDGE
P = STOP
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 to the SLAVE .
This goes as follows:
----------------------------------------------------
| S | ADDRESS SLAVE | WA | READ 8 BITS | GA | STOP |
----------------------------------------------------
GA = Give ACKNOWLEDGE
What physically happens is the following:
SDA H /-------------------------------\/--\ /--
L ----/\-------------------------------/ \--------/
SCL H --\ |-| |-| |-| |-| |-| |-| |-| |-| /-\
L \--| |-| |-| |-| |-| |-| |-| |-| |-------/ \------
ACK | MASTER controls SCL | | |
BY | Slave controls SDA | *1 | *2 | *3
SLAVE| | | |
Confused ? keep these rules in mind:
The chip controlling the CLOCK is the MASTER.
all others are SLAVES at that moment.
Now go and read the above again. (from Reading a BYTE on)
When you are reading another byte you just give another 8 clock pulses and then generate an ACKNOWLEDGE again. (note that it is the MASTER here that must generate the ACKNOWLEDGE ).
Reading one Byte
-----------------------------------------------
| S | SLAVE ADDRESS | WA | READ BYTE | GA | P |
-----------------------------------------------
or
------------------------------------------
| S | SLAVE ADDRESS | WA | READ BYTE | P |
------------------------------------------
Since STOP resets all SLAVEs why bother about giving an ACKNOWLEDGE? This works fine in practical applications.
Reading a sequence of bytes.
----------------------------------------------------------------------
| S | SLAVE ADDRESS | WA | READ BYTE | GA |....| READ BYTE | GA | P |
----------------------------------------------------------------------
or
-----------------------------------------------------------------
| S | SLAVE ADDRESS | WA | READ BYTE | GA |....| READ BYTE | P |
-----------------------------------------------------------------
Thats an easy one. This is being 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
Still following?
Now there is one more type of DATA telegram.
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 |
--------------------------------------------------------------------
So you start out as a normal WRITE operation.
AS WRITE = Address Slave in WRITE mode (even address)
Wait for ACKNOWLEDGE and WRITE a byte. This byte is being 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 send a STOP or continue reading from your SLAVE. 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.
You can easily do the following in one telegram.
START, Address slave, set location pointer, read, read,
set location pointer, read, set location pointer, write,
set location pointer, read, write, STOP.
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
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 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.
Still with me?
Congratulations you have reached the EXPERT grade :-)
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, you MUST always check that it has gone to the level you wanted. If it hasn't: BACKOFF ! it's occupied !.
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 asserting a SLAVE address. The first CPU wants to access SLAVE address 84 and the second CPU wants SLAVE address 87 (for example). So all goes well until they arrive at the 7th bit in the SLAVE address.
note: 84 = 01010100 (CPU 1)
87 = 01010111 (CPU 2)
||
++-- these are different.
Now CPU 1 has pulled SDA LOW.
CPU leaves SDA open.
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. CPU 2 on the other hand sees that the line is LOW while he has left it HIGH -> COLLISION. BACK OFF !.
CPU 1 hasn't even seen this so he just continues whatever he was doing.
Now CPU2 has to check that the slave address being put on the bus is not his own. If it is not his own 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 it's line LOW that always wins. The One which wanted the line to be HIGH when it is beefing pulled low by the other looses the BUS. We call this a loss of arbitration.
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 .
Getting the hang of it ?. You are ready to face the world of I2C :-)
2.6 Special cases 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 using the following setup:
+-----+
| CPU |
| +------o--------o---------o--------o-------------
| | | | | |
| +------|-o------|-o-------|-o------|-o-----------
| | | | | | | | | |
| +------|-|-o----|-|-------|-|------|-|-o---------
| | | | | | | | | | | |
| | | | | | | | | | | |
+-----+ | | | | | | | | | |
+-----+ +---+ +---+ +-----+
| SPI | |I2C| |I2C| |uWIRE|
+-----+ +---+ +---+ +-----+
CBUS is the ancestor of I2C. It was also developed by Philips. SPI is (c) Motorola and uWIRE is (c) National Semiconductor
Some general notes about these reserved addresses.
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:
----------------------------------------------------
| S | 0000 0000 | A | yyyy yyy1 | 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.
| Symbol | Unit | Standard mode | FAST mode |
| | | Min | Max | Min | Max |
=================+========+======+========+========+========+========+
Low level input | | | | | | |
voltage | Vil | V | -0.5 | 1.5 | -0.5 | 1.5 |
rel to VDD | | | -0.5 | 0.3Vdd | -0.5 | 0.3Vdd |
| | | | | | |
HIGH level input | | | | | | |
Volteg | Vih | V | 3.0 | *1 | 3.0 | *1 |
rel to VDD | | | 0.7Vdd | *1 | 0.7Vdd | *1 |
| | | | | | |
Hysteresis of | Vhys | V | - | - | 0.2 | - |
Schmitttrig | | | | | | |
| | | | | | |
Pulse width of | | | | | | |
spikes that must | tSP | nS | - | - | 0 | 50 |
be suppressed | | | | | | |
| | | | | | |
Low level output | | | | | | |
voltage | | | | | | |
At 3mA | Vol1 | V | 0 | 0.4 | 0 | 0.4 |
At 6mA | Vol2 | V | - | - | 0 | 0.6 |
| | | | | | |
Input current of | | | | | | |
BUS pins | Ii | uA | -10 | 10 | 10 | 10 |
| | | | | | |
Capacitance of | | | | | | |
each bus PIN | Ci | pF | - | 10 | - | 10 |
| | | | | | |
*1) Maximum Vih = VDD MAX + 0.5 V
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 accomplish 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 resistor must be adapted. For loads up to 200 pf a resistor is sufficient. For loads between 200pf and 400pF a current source is preferred.
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| 1 1 1 1 1 A9 A8 R/W |WA| A7 A6 A5 A4 A3 A2 A1 A0 | WA | .....
-----------------------------------------------------------------
A: 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 2 years.
Q: I want to extend it "by the book". Is there something like a Buffer for I2C?
A: 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.
Type: P82B715
Q: Can I isolate an I2C bus ? (using optocoupler or whatever)
A: This is possible. The circuit is rather complex due to the bidirectional nature of the I2C BUS.
However: Here it comes (for one channel).
------------o----------+ +------o-------------------
VCC | | | | VCC
| | | | | 3K3 | 270
| | 270 | | 3K3 | | | |
| | | | | | | |
| | | | | |
_______o____ | |C |
| | | | | / o______o_____
| | OL1--- | | --/ |/ OT1 | | |
1K8 | | \ / | | /--> B|\ | | |
| | --- | | | \E |C | |
| | | | | | / | | |
| |E | | o___B|/ NPN | | | 1K8
| | / | | | |\ | | |
_____o__B|/ | | | | \ | |
|\ | C | | |E | |
SDA | \ C | \ |B | | | |
or | | OT2 \| \-- | | OL2 --- |
SCL PNP | | /| <--\ | | \ / |
| C | E / | | | --- |
| \ |B | | | E| | SDA or
| \|____o | | \ | | SCL
| NPN /| | | | | PNP \|__o______
| / | | | | |1K | /|B
| E | | | 1K | | | / |
| | | | | | C|
| | | | | |
GND | | | | | | GND
-----------o----o------+ +------o------o------------
A couple of remarks:
Since the speed of the I2C bus can be rather high it is recommended to use a fast optocoupler. 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 dealt 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 OL1 will stay dark. Since OT1 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 by the 270 ohm and 1K8 resistor. The PNP transitory will not get driven. OL2 will not light. So OT2 does not get driven. So far so good.
Now lets look what will happen if we send a 0. The first transistor will be turned on. Thus OL1 will start emitting light. This results in the fact that OT1 will be turned on. The transistor connected to the Emitter of OT1 will be turned on too. The output line is now being pulled low via the 1K8 resistor. This low level would turn on the PNP transistor. This would result in OL2 to light, OT2 to turn on etc. The circuit would go into a lockup. 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.
Q: 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?
A: 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.
LCD Drivers:
PCF 8566 96 segment LCD driver
PCF 8568 LCD Row driver for dot matrix displays.
PCF 8569 LCD Column driver for DOT matrix displays
PCF 8576 160 segment LCD driver
PCD 8577 64 Segment LCD driver
PCF 8578 LCD Row driver for Dot matrix LCD's
PCD 8579 Column driver for Dot matrix LCD's
SAA 1064 4 Digit Led driver
PCF 8574 8 Bit I/O port
PCF 8574A 8 Bit I/O port different address.
SAA 1300 5 Bit high current driver
PCF 8591 4 channel ADC + One DAC (all 8 bits)
TDA 8442 Quad 6 bit DAC
TDA 8444 Octal 6 bit DAC
PCF 8570 256 byte static ram
PCf 8571 128 byte static ram
PCF 8581 128 byte EEprom
PCF 8582 256 byte EEprom
PCF 8583 256 byte RAM + Realtime clock and calendar
PCF 8594 512 byte EEprom
PCF 8598 1K byte EEprom
PCF 8573 Clock/Calendar
PCF 8583 Clock/Calendar with 256 byte Ram
8xCL410 Low power 8051 cpu
8xC528 8051 Compatible CPU with 32Krom 512 byte ram
8xC552 8051 compatible CPU with 8Krom /UART/ADC/PWM
8xC751 8051 Compatible CPU 24 pin 300 mil's DIL
8xC752 8051 Compatible CPU 28 pin DIL
68070 68000 CPU with MMU/UART/DMA/TIMER
PCD3311 3312 DTMF / Tone generator
PCF8200 Voice synthesizer
SAA1136 PCM interface
SAA524x Teletext processor
SAA7191 S-VHS decoder
SAA7192 Digital color space converter
SAA7199 Digital encoder
SAA9020 Field memory controller
SAA9051 Digital TV decoder
SAA9068 PIPCO Picture in picture system
SAB3035 3037 Tuning interface
SAF1135 VPS decoder
TDA4670 Picture improvement circuit
TDA4680 Video processor
TDA8421 HiFi stereo audio processor
TDA8425 Audio processo rwith loudspeaker channel
TDA8440 Video switch
TDA8442 Color decoder interface
TDA8443 YUV to RGB unit
TDA8461 PAL / NTSC color decoder
TEA6100 Fm tuning interface
TEA6300 6310 Sound fader control
TSA551x TV Pll synthesizer
TSA6057 Fm Pll synthesizer
SAA1300 5 bit high current driver
UMF1009 Frequency synthesizer
Audio Video
SDA3312 TV PLL synthesizer
SDA2121 TV PLL synthesizer
SDA2516 1K bit EEprom
SDA2526 2K bit EEprom
SDA2546 4K bit EEprom
SDA2586 8K bit EEprom
SDA3526 2K bit EEprom with write protection
SDA3546 4K bit EEprom with write protection
SDA3586 8K bit EEprom with write protection
Memories
X24X00 128 bit EEprom
X24001 128 bit EEprom
X24C01 1k bit EEprom
X24012 1k bit EEprom
X24C02 2k bit EEprom
X24022 2k bit EEprom
X24C04 4k bit EEprom
X24042 4k bit EEprom
X24C08 8k bit EEprom
X24C16 16k bit EEprom
X24164 16k bit EEprom
Then by using software 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 . (probably already in 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.
You can contact Sharon Baker at Signetics (408) 991-3518. for further information
A company called Computer Access technology provides plug in boards for IBM-PC that give your system ACCESS bus features.
Note that the address has changed since the FIRST FAQ issue.
Computer Access Technology (CATC)
3375 Scott Blvd.
Suite #410
Santa Clara CA 95054
Phone +1-408-727-6600
Fax +1-408-727-6622
E-mail: catc@netcom.com
----+-----------------------------------------------------------------------
Low | 000x 001x 010x 011x 100x 101x 110x 111x
High+-----------------------------------------------------------------------
|
|
0000|
0001|
|
0010| SAA5240 SAA5240 SAA5240 SAF1134 SAA5252 SAA9020 SAA9020 SAA9020
| SAA4700 SAA5241 SAB9070 SAF1135 SAA9020
| SAF1134 SAA5243 SAF1134
| SAF1135 SAA5244 SAF1135
| SAA5245
| SAA5246
| SAA9041
| SAA4700
| SAF1134
| SAF1135
|
0011| SAA7250 SAA7250 SAA1136 PCF1810 PCF1810 PCF1810
| PCB5020 PCB5020 PCF1810 SAA1770 SAA1770
| PCB5021 PCB5021
| PCB5032 PCB5032
|
0100| SAA1137 SAA1137 PCA1070 PCA1070 PCD3311 PCD3311 SAB3028 PCD5002
| PCD4430 PCD4430 PCD3312 PCD3312
| SAA7194 SAA7194
| PCF8574 PCF8574 PCF8574 PCF8574 PCF8574 PCF8574 PCF8574 PCF8574
| TDA8444 TDA8444 TDA8444 TDA8444 TDA8444 TDA8444 TDA8444 TDA8444
|
0101|
0110|
0111| PCF8576 PCF8576 PCF8577 PCF8577A PCF8578 PCF8578 PCF8566 PCF8566
| SAA1064 SAA1064 SAA1064 SAA1064 PCF8579 PCF8579
| PCF8574A PCF8574A PCF8574A PCF8574A PCF8574A PCF8574A PCF8574A PCF8574A
|
|
1000| TEA6320 TDA8424 TDA8405
| TEA6330 TDA8425 TDA8415
| TDA8526 TDA8416
| TDA8420 TDA8420 TDA9840
| TDA8421 TDA8421 TDA8940T
| TDA9860 TDA9860 TDA8417
| NE5751 NE5751 TDA6360 TDA6360
| TDA8480 TDA8480
|
|
1001| TDA8440 TDA8440 TDA8440 TDA8440 TDA8440 TDA8440 TDA8440 TDA8440
| TDA8540 TDA8540 TDA8540 TDA8540 TDA8540 TDA8540 TDA8540 TDA8540
| PCF8591 PCF8591 PCF8591 PCF8591 PCF8591 PCF8591 PCF8591 PCF8591
|
1010| PCF8570 PCF8570 PCF8570 PCF8570 PCF8570 PCF8570 PCF8570 PCF8570
| PCF8571 PCF8571 PCF8571 PCF8571 PCF8571 PCF8571 PCF8571 PCF8571
| PCF8580 PCF8580 PCF8580 PCF8580 PCF8580 PCF8580 PCF8580 PCF8580
| PCF8582 PCF8582 PCF8582 PCF8582 PCF8582 PCF8582 PCF8582 PCF8582
| PCF8581 PCF8581 PCF8581 PCF8581 PCF8581 PCF8581 PCF8581 PCF8581
| PCF8582 PCF8582 PCF8582 PCF8582 PCF8582 PCF8582 PCF8582 PCF8582
| PCF8583 PCF8583
|
1011| SAA7199 SAA7191 TDA8416 TDA2518 PCA8510 SAA7186 SAA9065
| SAA7152 SAA7186 PCA8516
| PCF8570C PCF8570C PCF8570C PCF8570C PCF8570C PCF8570C PCF8570C PCF8570C
|
1100|
| TSA5510 TSA5510 TSA5510 TSA5510 TSA5510 TSA5510 TSA5510 TSA5510
| TSA5511 TSA5511 TSA5511 TSA5511 TSA5511 TSA5511 TSA5511 TSA5511
| TSA5512 TSA5512 TSA5512 TSA5512 TSA5512 TSA5512 TSA5512 TSA5512
| TSA5514 TSA5514 TSA5514 TSA5514 TSA5514 TSA5514 TSA5514 TSA5514
| TSA5519 TSA5519 TSA5519 TSA5519 TSA5519 TSA5519 TSA5519 TSA5519
| SAB3035 SAB3035 SAB3035 SAB3035 SAB3035 SAB3035 SAB3035 SAB3035
| SAB3036 SAB3036 SAB3036 SAB3036 SAB3036 SAB3036 SAB3036 SAB3036
| SAB3037 SAB3037 SAB3037 SAB3037 SAB3037 SAB3037 SAB3037 SAB3037
| UMA1010 UMA1010 UMA1010 UMA1010 UMA1010 UMA1010 UMA1010 UMA1010
| UMA1009 UMA1009 UMA1009 UMA1009 UMA1009 UMA1009 UMA1009 UMA1009
| TEA6000 TSA6057 TSA6057
| TEA6100 PCA8516 PCA8516
| TSA6060 TSA6060
| TSA6061 TSA6061
|
1101| TDA8443 TDA8443 TDA8443 TDA8443 TDA8443 TDA8443 TDA8443 TDA8443
| PCF8573 PCF8573 PCF8573 PCF8573 UMA1000 UMA1000 UMA1000 UMA1000
| TDA1551 PCD4440 PCD4440
|
1110| SAA7192 SAA7192
1111|
ftp.funet.fi (nic.funet.fi)
/pub/compilers/8051
/pub/microprocs/MCS-51 <mirror of ftp.pppl.gov>
Philips-News@InetBSystems.us.com - Email (not ftp)
- send Email with "subscribe" in the subject field to be put
on list for newsletter
Philips-archive@InetBSystems.us.com - Email (not ftp)
- send Email message with the word "help" in the subject line to
learn how to access the archive
Philips-forum-request@InetBSystems.us.com - Email (not ftp)
- send an Email message with the word "subscribe" in the subject
line to participate in the forum, and receive usage
instructions and guidelines
Philips-Info@InetBSystems.us.com - Email (not ftp)
- send Email message to get information on all of Philips Email
services
info@circellar.com - Email (not ftp)
- send Email to get information file on services available
- all Circuit Cellar INK and BYTE related files available
ftp.oak.oakland.edu
- has information and software for a wide range of
microprocessors and microcontrollers, you may have to look
around a bit
ai.uga.edu
/pub/hardware
- stuff on the Philips 87C750/1/2 microcontrollers
- stuff on I2C
- assembler, an update for the software in the DS-750 kit,
notebook of some early experiences and code
- responses welcome, Michael A. Covington (mcovingt@ai.uga.edu)
http://www.hut.fi/~iisakkil/stuff.html
- c source to bit-bang I2c on a PC printer port.
Various manufacturers WEBsites
http://www.ramtron.com
http://www.siemens.com
Link to a LARGE number of links to commercial pages from various
companies:
http://dvt07.fagmed.uit.no/electronics.html
Circuit Cellar, Inc.
- contains code from their magazine articles and from the
original Circuit Cellar articles in Byte magazine, also
contains many other interesting items
- GOOD STUFF HERE!
- The BBS is mentioned in the masthead of each issue (on the
table of contents page). Excerpts from the BBS appear in Ken
Davidson's ConnecTime column in every issue with a description
of how to access the system at the end of every column.
- (203)871-1988
- Voice: (203)875-2751
- Fax: (203)872-2204
Philips Semiconductor - Europe
- support for: standard logic, programmable logic,
in-car electronics (now open), 8 and 16 bit microcontrollers,
I2C software, third party software, discrete semiconductors,
cross assemblers (general), RF (planned)
- PHIBBS is located in the Netherlands: +31-40-721102
- maximum 21600 baud / V42bis / HST/Vterbo
- 24 hours a day available
- Help desk: +31-40-722749 (9.00 AM - 16.00 PM CET)
Philips Semiconductor - North America
- support for their 8051 variants
- contains many good source code items
- partially mirrored on ftp.pppl.gov and nic.funet.fi
- (800)451-6644 or (408)991-2406
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 application notes on i2C and how to implement it on
8051 and 68000 compatible CPUs
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
Technical questions:
Sunnyvale, CA - (408)991-3518
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 analyzer. Hard and software for IBM PC.
A.b-DEV-KIT
Contains the interface board, a mouse and an expansion box.
Furthermore there are drivers and software + source code to start
developing you own access bus peripherals.
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: ken.davidson@circellar.com
- $21.95, $31.95 surface Canada and Mexico,
$49.95 air all other countries
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
Data book / Handbook / Users' Guide
- Philips I2C devices Handbook
- 8051 Handbook from philips (contains also complete I2C spec)
pub no : 9397-750-00013
- I2C peripherals for microcontrollers.
98-8080-574 (Philips ord.nr)
Currently depleted. Scheduled 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
Intel Corporation
- application notes
Philips Semiconductors (Signetics)
- application notes
Databooks from Philips, Xicor, SGS Thomson etc.
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)
Are all the lines 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.
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 pre-trigger to 1 division.
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.
_____
VCC ---|>|--|___|--- SDA
LED 470 Ohms
Replace the chip. It could be defective.
Now you can connect the other devices one by one. Each time try to access them.
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 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)
That's about it.
In most other cases you will need a storage scope to view what is actually happening on the I2C bus.