Himpe V.I2C bus FAQ.Ver 1.5.1995

Article 148028 of sci.electronics:
Path: news.scruz.net!legba.synergy.net!news.inetnebr.com!news.exodus.net!uunet!in2.uu.net!newsfeed.internetmci.com!EU.net!Belgium.EU.net!ping.be!news
From: Vincent.Himpe@ping.be (Vincent Himpe)
Newsgroups: sci.electronics
Subject: I2CFAQ version 1.5 retry (not UUencoded)
Date: Mon, 27 Nov 1995 01:23:55 GMT
Organization: PING Belgium
Lines: 1791
Message-ID: <49a2d3$326@ping1.ping.be>
NNTP-Posting-Host: dialup24.kortrijk.eunet.be
X-Newsreader: Forte Free Agent 1.0.82

Newsgroups: SCI.ELECTRONICS,COMP.PROTOCOLS.MISC
Subject: I2c Bus FAQ Version 1.5
From: vincent.himpe@ping.be (Vincent Himpe)
Followup-To:POSTER

Archive-name: I2C-BUS-FAQ

This article is a collection of information sources on the i2c Bus

The following topics are addressed:

0) Preface

1) ABOUT THIS FAQ

1.1) Who put this FAQ together?
1.2) How can I contribute to this FAQ?
1.3) What newsgroups will this FAQ be posted to?
1.4) May I distribute this FAQ or post it somewhere else?
1.5) Other interesting FAQs

2) ABOUT I2C

2.1) Historical background
2.2) I2C Bus protocol
2.3) Hardware Layout
2.4) Events on the I2C Bus

2.4.1) Start and Stop condition
2.4.2) Putting something on the bus.
2.4.3) addressing a SLAVE chip.
2.4.4) What happens next ?
2.4.5) Writing one or more bytes to a SLAVE.
2.4.6) Reading one or more bytes from a SLAVE.
2.4.7) Determining the SLAVE acces mode
2.4.8) Combined data format

2.5) MultiMASTER operation
2.6) Special addresses and exceptions
2.7) Electrical specs of the bus

3) Enhanced I2C (FAST mode)

4) Extended addressing (new I2C standard)

5) Q&A section

6) An I2C driver in Pseudocode

7) Debugging Tools

8) I2C interface system for IBM-PC

8.1 Hardware
8.2 Software ( sheduled for Release 1.6 during december )

9) Legal notes and Copyrights

A) ACCESS Bus

B) Address map

B.1) Overview of existing I2C components and their function

C) SOURCES OF INFORMATION ON I2C

C.1) FTP sites
C.2) Web pages about i2c
C.3) BBSs

D) I2C PRODUCTS

D.1) Free development tools
D.2) Commercially available products

E) I2C Documentation

E.1) Periodicals that have articles covering I2C
E.2) Books
E.3) Miscellaneous documentation

F) Troubleshooting



0) Preface


Hi and welcome to the Fifth edition of the I2C FAQ.

**** HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT ****

Philips has an FTP site on the net with lots of I2C related
stuff.

FTP to ftp://ftp.inetbsystems.us.com/pub/Philips-MCU/bbs

This adress will change in the future.Check out .

For the Philips News letter subscribe to :

Philips-news@inetbsystems.us.com

**** HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT HOT ***

This release contains schematics and software listing to implement
I2C on you parallel port using Qbasic that comes with DOS.
Also some debugging tools are described in this FAQ.

On demand of Philips an entry on the copyrights and licences
involved
with he use of the bus has been made to this FAQ.

This faq is archived on my Web Homepage.
When you log on select I2C

http://www.ping.be/~ping0751/I2C.HTM

The FAQ is archived.You can download it from :

FTP//fpt.uni.paderborn.de/elrad/020/

However the one on my homepage will be the most up to date
version.

If you store the FAQ on a server or homepage please inform me.
That way i can add the server adresses to the list.

Hope its useful to you guys and girls out there.
Keep those reply's coming

Regards,

Vincent


As usual greetings go to :

Russ Hersh,Phil Wood,Philips PCALE Eindhoven,Stephen Phillips
Ian Willis,Kevin Gardner,Dave Heller,Karl-Heinz Wietzke and many
others .

Special greetings go to:

Kevin Gardner 'The Copyright Section'
Tony Ayling for pointing out a bug in the PseudoCode driver.
Dave Heller ' The Philips FTP SIte
Karl-Heinz Wietzke for pointing out an error in the section
'Reading'


1) ABOUT THIS FAQ

1.1) Who put this FAQ together?

I put this FAQ together in response to my own frustration in
searching
for information about I2C.I've 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.

1.2) How can I contribute to this FAQ?

If you have any suggestions or additions please inform me.

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


I hope that those of you who know of interesting items for this
FAQ
will share with everyone by contributing to this list. A good
amount
of stuff is turning up thanks to everyone's help.

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.

1.3) What newsgroups will this FAQ be posted to?

This FAQ will be posted to the following newsgroups:
comp.protocols.misc
sci.electronics

These newsgroups often contain discussions, announcements, or
information about I2C. Check them out from time to time.

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.


1.4) May I distribute this FAq or post it somewhere else ?

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
continue to spend, a 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 as posted in SCI.ELECTRONICS.

Thank you.


1.5) Other interesting FAQ's

Microcontroller FAQs

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


Additional FAQs of interest

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

For more information on various microcontrollers and their
features,
refer to the Microcontroller primer and FAQ listed above.


2) ABOUT THE I2C Bus


2.1) Historical background.

The I2C bus was developed in the early 1980's by Philips
semiconductors.It's purpose was to provide an easy way to connect
a
CPU to peripherial chips in a TV-set.

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.Offsprings
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,Analog Devices.



2.2) 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 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 !
------------
Case : The CPU wants to talk to the I/O port.

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
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 ,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.


2.3 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
--o< !--- ! and an open drain or open collector
transistor.
\! ! ! When nothing happens the bus lines are
in the
! ---O logic HIGH state. Note here that an
external
! ! PULL-UP resistor is necessary. This is an
error
! ! that most beginners make.
!-- ! To put something on the BUS the chips 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 there even exist 3.3 volt ic's. It's clear that in this
case
the high level will be 3.3 volts.

2.4 Events on the BUS

We 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 controls
the
Clock line. The MASTER always generates the Clock pulses.

- 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.

2.4.1 Start And Stop condition.

A start condition looks like this:


SDA H ------\ The chip issuing the Start condition
first
L \------- pulls 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
L ---------/ then 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.

2.4.2 Putting something on the BUS

Putting a bit of any kind on the bus looks like this :

SDA H /----------\
L -----/\----------/\------- First the MASTER sets the data
line
to the appropriate level by
pulling
SCL H /----\ or not pulling the SDA line
low.
L --------/ \---------- Then it releases the SCL line
for
some time and pulls it low
again
before changing the state of
the
SDA line.

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.

2.4.3 addressing a SLAVE chip.


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.


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 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.


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 -------------


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 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 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.If you are writing to EEproms then take a bigger TIMEOUT
value
in account.

2.4.4 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.


2.4.5 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

2.4.6 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 to the SLAVE .

Exception :!!!

This reading part is a bit tricky.There is a special condition.
It was pointed out to me by Karl-Heinz Wietzke (Thanks Karl).

On the Last byte read the Master must generate a NACK signal !.
This looks the same as a normal ACKnowledge except the Clock
pulse
is missing.

ACK :

/---------\
SDA -/ \-----
/-----\
SCL ---/ \-------

NACK :

/---------\
SDA -/ \-----

SCL -------------------



A read sequence goes as follows:

---------------------------------------------------
! S ! address SLAVE ! WA ! READ 8 BITS ! NA ! STOP !
---------------------------------------------------

GA = Give ACKNOWLEDGE.
NA = Give NOT-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! ! ! !


*1 : The SLAVE releases SDA (SDA goes HIGH)
*2 : The MASTER first pulls SDA low then gives a CLOCK pulse
and releases SDA again.(SDA goes back high)

This acts as a signal to the SLAVE that the MASTER has
received
all 8 bits.

*3 : Depending on what happens next. A stop condition could be
issued
by the MASTER. Or another byte could be read.

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 ).
Remeber if this is the last byte you have read you must give a
NACK
instead of an ACK !.

Reading one Byte

----------------------------------------------
! S ! SLAVE address ! WA ! READ BYTE ! NA ! P !
----------------------------------------------

or

-----------------------------------------
! S ! SLAVE address ! WA ! READ BYTE ! P !
-----------------------------------------

Since STOP resets all SLAVEs why bother about giving an
NACKnowledge ?.
This works fine in practical applications.
Although some IC's need thsi last NACK signal to reset some
internal
circuitry. Check the datasheets before you do this.


Reading a sequence of bytes.


----------------------------------------------------------------------
! S ! SLAVE address ! WA ! READ BYTE ! GA !....! READ BYTE ! NA
! P !

----------------------------------------------------------------------

or

----------------------------------------------------------------
! S ! SLAVE address ! WA ! READ BYTE ! GA !....! READ BYTE ! P !
----------------------------------------------------------------


2.4.7 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)

Still following ?

Now there is one more type of DATA telegram.

2.4.8 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 !

--------------------------------------------------------------------

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 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 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 , 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 ?
Concratulations you have reached the EXPERT grade. :-)

2.5 MULTIMASTER communication.(collision detection)

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, 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 beeing put on the
bus is
not his own. If it is nit 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 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.

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 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 using the following setup :

-------
! CPU !
! !------o--------o---------o--------o-----------------------
! ! ! ! ! !
!
!------!-o------!-o-------!-o------!-o----------------------
! ! ! ! ! ! ! ! ! !
!
!------!-!-o----!-!-------!-!------!-!-o---------------------
! ! ! ! ! ! ! ! ! ! ! !
! ! ! ! ! ! ! ! ! ! ! !
------- ! ! ! ! ! ! ! ! ! !
------- ----- ----- -------
! SPI ! !I2C! !I2C! !uWIRE!
------- ----- ----- -------

How this exactly works would lead us too far.Maybe in the future
this
will be incorporated. 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
and uWIRE is (c) National Semiconductor


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
endvironment. (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 ! 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.


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 generated 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.





2.7) 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.


! 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

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.


3.0) Enhanced I2C (FAST mode)

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.


4.0) Extended addressing (10 bit address mode)

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! 1 1 1 1 1 A9 A8 R/W !WA! A7 A6 A5 A4 A3 A2 A1 A0 ! 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.

5.0) Q&A section

Q - What is the maximum distance of the bus ?

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 once 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------------

OT1 and OL1 are part of one optocoupler.
OT2 and OL2 are the other optocoupler.

A couple of remarks.
Since the speed of the I2C bus can be rather high it is
reommended 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 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 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
beeing pulled
hgih by the 270 ohm and 1K8 resistor. The PNP transitor 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 Emittor of OT1 will be tured
on too.
The output line is now beeing pulled low via the 1K8
resistor.
This low level would turn on the PNP transistor . This would
result in
OL2 to ligh, 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.

Q - 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.

A - 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.

Q - Is it okay to abort an on-going transmission any time.

A - 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
try 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 it's 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.

Q - Do i need to give the ack in read mode on the last byte.
My chip starts sending data and occupies the bus ... .

A - 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

-- This is a BUG fIx !! --

Q - I read the SDA and SCL are bidirectional.Why does the clock
line
need to be bidirectional ?

A - The clock line needs to be directional ONLY when using a
MULTIMASTER
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.


6) An I2C driver in PseudoCode

This section covers a sample I2C driver.
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.

Note. This driver assumes you to start a message with SDa and SCL
both HIGH
and end with both SDA and SCL high.

To make sure this is the fact you must send a STOP command
immediately
after power on.This will put SDA and SCL in the rigth state
and also
assert a RESEt to all attached slaves.

A Bug in the Start routine was fixed thanks to Tony Ayling.
Thanks Tony

/
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
/
/ **** I2C Driver V1.0 Written by V.Himpe. Released as Public Domain
**** /
/
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
/

DECLARE N,SIZE,BUFFER,X Byte
DECLARE DATA() Array of SIZE elements

SUBroutine START
SCK=1 / BUGFIX !/
SDA=0
SCK=0
SDA=1
ENDsub

SUBroutine STOP
SDA=0
SCK=1
SDA=1
ENDsub

SUBroutine PUTBYTE(BUFFER)
FOR n = 7 TO 0
SDA= BIT(n) of BUFFER
SCK=1
SCK=0
NEXT n
SDA=1
ENDsub

SUBroutine GETBYTE
FOR n = 7 to 0
SCK=1
BIT(n) OF BUFFER = SDA
SCK=0
NEXT n
SDA=1
ENDsub

SUBroutine GIVEACK
SDA=0
SCK=1
SCK=0
SDA=1
ENDsub

SUBroutine GETACK
SDA=1
SCK=1
WAITFOR SDA=0
SCK=0
ENDSUB

/ this concludes the low-level set of instructions for the I2C
driver /
/ The next functions will handle the telegram formatting on a higher
level /

SUBroutine READ(Device_address,Number_of_bytes)
Device_adress=Device_adress OR (0000.0001)b / This sets the READ
FLAG /
CALL START
CALL PUTBYTE(Device_adress)
CALL G
Vincent.Himpe@ping.be
vi_himpe@mietec.be
http://www.ping.be/~ping0751

:: No user-serviceable parts inside. Warranty void if opened !