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)  How about 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

      8)  Overview of existing devices

      9)  ACCESS Bus

      A)  address map

      B)  SOURCES OF INFORMATION ON I2C

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

      C)  I2C PRODUCTS

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

      D)  I2C Documentation

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

      E)  Troubleshooting



0)  Preface


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

    This one is a month late. Last month there was no posting because of
    your's truly beeing on holidays.

    The main hot item in this release is the description of an I2C driver.
    This driver is portable to any language and CPU.
    THe driver is written in PSEUDOCODE. This is an imaginary programming
    language which resembles normal spoken language.
    That way it should be easily understandable for any programmer.
    Whether you are used to Asm,Basic,C,Forth,Pascal or Whatever the
    translation to your 'native' language should be a piece of cake.

    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.

    The FAQ is finally archived.You can download it from :

        FTP//fpt.uni.paderborn.de/elrad
        Check the INDEX.00 file there to know where it is

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

    Check the INDEX.00 file there to know where it is

    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 and many others ....




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

    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 post this FAQ to my local BBS?

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

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

     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 .

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


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



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


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

     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.

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.

  / $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ /
  / **** 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
     SDA=0
     SCK=0
     SDA=1
  ENDsub

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

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

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

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

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

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

  SUBroutine READ(Device_address,Number_of_bytes)
     Device_adress=Device_adress OR (0000.0001)b / This sets the READ FLAG /
     CALL START
     CALL PUTBYTE(Device_adress)
     CALL GETACK
     FOR x= 0 to Number_of_bytes)
         CALL GETBYTE
         DATA(x)=BUFFER / Copy the received BYTE in the DATA array /
         CALL GIVEACK
     NEXT x
     CALL STOP
  ENDsub

  SUBroutine WRITE(Device_address,Number_of_bytes)
     Device_adress=Device_adress AND (1111.1110)b / This clears READ flag /
     CALL START
     CALL PUTBYTE(Device_adress)
     CALL GETACK
     FOR x= 0 to Number_of_bytes
         CALL PUTBYTE (DATA(x))
         CALL GETACK
     NEXT x
     CALL STOP
  ENDsub

  SUBroutine RANDOMREAD(Device_adress,Start_adress,Number_of_bytes)
     Device_adress=Device_adress AND (1111.1110)b / This clears READ flag /
     CALL START
     CALL PUTBYTE(Device_adress)
     CALL GETACK
     CALL PUTBYTE(Start_adress)
     CALL GETACK
     CALL START
     Device_adress=Device_adress OR (0000.0001)b / This sets the READ FLAG /
     CALL PUTBYTE(Device_adress)
     CALL GETACK
     FOR x= 0 to Number_of_bytes
         CALL GETBYTE
         DATA(x)=BUFFER
         CALL GIVEACK
     NEXT x
     CALL STOP
  ENDsub

  SUBroutine RANDOMWRITE(Device_adress,Start_adress,Number_of_bytes)
     Device_adress=Device_adress AND (1111.1110)b / This clears READ flag /
     CALL START
     CALL PUTBYTE(Device_adress)
     CALL GETACK
     CALL PUTBYTE(Start_adress)
     CALL GETACK
     FOR x= 0 to Number_of_bytes
         CALL PUTBYTE (DATA(x))
         CALL GETACK
     NEXT x
     CALL STOP
  ENDsub

  / $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ /
  / **** End of the I2C Driver . (c)95 V.Himpe . Public Domain release *** /
  / $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ /

  Some notes about the high level routines.

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

  PCD8574=(0100.0000)b
  CALL READ(PCD8574,1)
  result = DATA(0)

  / will read the status of the 8 bit input port of a PCD8574. /

  DATA(0)=(0110.01010)b
  CALL WRITE(PCD8574,1)

  / will write 0110.0101 to the 8 bit port of the PCD8574 /

  When do you need a multiread ?
  Consider a PCF8582 EEPROM.
  You want to read its contents in one time.

  PCF8582=(1010.0000)b
  CALL READ(PCF8582,255)

  You can do the same with WRITe for the EEprom with the restriction
  that Number_of_bytes is not larger than 4.

  You will have to check the components datasheets.

  The most usefull instructions are RANDOMREAD and RANDOMWRITE

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

  DATA(0)=(1010.0011)b
  DATA(1)=(1110.0000)b
  DATA(2)=(0000.1100)b
  DATA(3)=(1111.0000)b
  CALL RANDOMWRITE (PCF8582,(20)h,3)

  The same goes for reading 16 bytes from the eeprom starting at adress 42h

  CALL RANDOMREAD(PCF8582,(42)h,15)

  The results are stored in DATA. All you have to do is read them out of
  the array to process.
  When you give the devices adress to these routines you don't have to care
  about the R/W flag. It will be automatically set to the right state inside
  the routines.



regards

Vincent
--------------------------------------------------------------
Vincent Himpe
                                                 /////
Internet :                                       O  *)
   vincent.himpe@ping.be                          /
   vi_himpe@mietec.be                            \__/

http://www.ping.be/~ping0751
--------------------------------------------------------------

--- ifmail v.2.8c
 * Origin: PING Belgium (2:5020/118@fidonet)


 sci.electronics (2:5020/118.51)  ECHOMAIL071 
 Msg  : 137 of 218                                                              
 From : Vincent Himpe               2:5020/118              03 Sep 95  18:27:00 
 To   : All                                                                     
 Subj : I2CFAQ version IV part 2 of 2                                           

ping.be!news
From: Vincent.Himpe@ping.be (Vincent Himpe)



8) Overview of existing I2C components and their function

   Philips

   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

   I/O expanders:

       PCF 8574   8 Bit I/O port
       PCF 8574A  8 Bit I/O port different address.
       SAA 1300   5 Bit high current driver

   Data convertors

       PCF 8591   4 channel ADC + One DAC (all 8 bits)
       TDA 8442   Quad 6 bit DAC
       TDA 8444   Octal 6 bit DAC

   Memory

       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

   Clocks

       PCF 8573   Clock/Calendar
       PCF 8583   Clock/Calendar with 256 byte Ram

   Master devices

       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

   Audio / Video

       PCD3311 3312  DTMF / Tone generator
       PCF8200       Voice synthesizer
       SAA1136       PCM interface
       SAA524x       Teletext processor
       SAA7191       S-VHS decoder
       SAA7192       Digital color space convertotr
       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

   Miscellanious

       SAA1300    5 bit high current driver
       UMF1009    Frequency synthesizer

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

   RAMTRON

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

   SGS-Thomson  (ST)

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

   Siemens

   Audio Video

      SDA3312   TV PLL synthesizer
      SDA2121   TV PLL synthesizer

   Memories

      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

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

   Xicor

   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



9)   ACCESS bus.

     A recent offspring of the I2C BUS is the ACCESS Bus. This bus was
     codeveloped by Philips,Signetics,Digital and Intel.The goal was to
     create a bus that could help us getting rid of all cabling involved
     with computer peripherals. You would have 1 bus connector where you
     could hook up your keyboard,mouse,digitizer,scanner,printer,monitor
     etc.

     Then by using sotware you could issue commands to your monitor or
     printer.Things like selecting fonts or programming brightness and
     picture size could be done from within software on the host platform.

     Things like Hotplugging are included in the standard.There has been
     a chip developed that could replace the standard 8042 (which is the
     keyboard controller in an ibm PC) by an access bus controller.
     Digital is using the bus in its Alpha based machines. Sony and some
     other manufacturers have monitors that support the remote programming
     features.Microsoft will support the bus fully .
     (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


A) address Map of existing I2C components.

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

  When a device occurs more than once this means that all of those addresses
  can be selected. This usually happens by pulling some of the devices pin(s)
  to a certain level

A.1 Overview of existing I2C components and their function

   Philips

   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

   I/O expanders:

       PCF 8574   8 Bit I/O port
       PCF 8574A  8 Bit I/O port different address.
       SAA 1300   5 Bit high current driver

   Data convertors

       PCF 8591   4 channel ADC + One DAC (all 8 bits)
       TDA 8442   Quad 6 bit DAC
       TDA 8444   Octal 6 bit DAC

   Memory

       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

   Clocks

       PCF 8573   Clock/Calendar
       PCF 8583   Clock/Calendar with 256 byte Ram

   Master devices

       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

   Audio / Video

       PCD3311 3312  DTMF / Tone generator
       PCF8200       Voice synthesizer
       SAA1136       PCM interface
       SAA524x       Teletext processor
       SAA7191       S-VHS decoder
       SAA7192       Digital color space convertotr
       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

   Miscellanious

       SAA1300    5 bit high current driver
       UMF1009    Frequency synthesizer

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

   RAMTRON

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

   SGS-Thomson  (ST)

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

   Siemens

   Audio Video

      SDA3312   TV PLL synthesizer
      SDA2121   TV PLL synthesizer

   Memories

      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

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

   Xicor

   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




B)  SOURCES OF INFORMATION ABOUT I2C


B.1)  FTP sites

    The following is a list of the various anonymous ftp sites that carry
    tools and examples about I2C and how to implement it.
    There are many others that  are not listed here that contains bits and
    pieces.  Usually you can find them using Archie and searching for
    "I2C","ACCESS BUS" and stuff like that.


    ftp.funet.fi (nic.funet.fi)
        /pub/compilers/8051
        /pub/microprocs/MCS-51   <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)


    awaiting final corporate approval... Philips Semiconductor ftp site


B.2)  Web pages

      http://www.hut.fi/~iisakkil/stuff.html
        - c source to bitbang I2c on a PC printer port.

      Various manufactureres websites

      http://www.ramtron.com
      http://www.siemens.com


B.3)  BBSs

    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




C)  I2C products

    This section includes descriptions and references to free and
    commercial software for the I2C Bus and lookalikes.  FTP sites and BBSs
    contain many quality packages and code samples for free.
    For heavy duty use, you might prefer the many commercial packages that
    are available.  With the public domain (or free) stuff, you're usually
    on your own. The commercial packages usually provide extensive
    documentation and support.


C.1)  Free development tools

    The following is a list of development tools that exist on the net.


    IBM PC program to control I2C bus from the printer port.

      Program: TV312.EXE  / TV400.EXE / I2CRAD.EXE
      Description: Control program by Philips Semiconductors for I2C bus.
      Location:  ftp.pppl.gov : /pub/8051/signetics-bbs
                 ftp.funet.fi : /pub/microprocs/MCS-51/signetics-bbs

      The same site has lots of APP notes on i2C and how to implement it on
      8051 and 68000 compatible CPU's.


    That's all right now. More to come in the next FAQ release


C.2)  Commercially available products


    Philips Microcontroller Product Group
                    811 East Arques Ave. / POB 3409
                    Sunnvale, CA  94088-3409
                    Technical documentation:
                        Sunnyvale, CA - (800)447-1500  Fax: (408)991-3773
                        Eindhoven, Netherlands - Fax: 31-40-724825
                    Technical questions:
                        Sunnyvale, CA - (408)991-3518

    A set of development boards for the I2C bus :

      S87C00KSD  I2C evaluation Board
      OM1016     I2C demo board with CPU and a number of peripherals like
                 I/O,AD/DA,LCD,RAM,EEprom,CLOCK,DTMF,IR receiver etc..
      OM1018     Manual for the above.
      OM1020     LCD and driver demoboard.
      OM4151     Similar to OM1016 but without IR link.
      OM4160     68070 based demoboard.
      OM1022     I2C bus analyser. Hard and software for IBM PC.


   ACCESS.bus

   A.b-DEV-KIT
      Contains the interface board , a mouse and an expantion box.
      Furthermore there are drivers and software + sourcecode to start
      developing you own acces bus peripherals.

    Signetics Corporation (see Philips Microcontroller Product Group)



D)  I2C DOCUMENTATION


D.1) Periodicals that sometimes have articles about I2C

    Various magazines and journals (journals seems to be THE popular name
    for magazines these days) provide articles from time to time on the I2C
    bus

    The Computer Applications Journal (Circuit Cellar Ink)
        - programming and construction articles
        - POB 7694, Riverton, NJ  08077-8784
        - FAX: (203)872-2204
        - Voice orders: (609)786-0409
        - On-line orders (BBS): (203)871-1988
        - Email orders: 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


D.2)  Books on I2C

    I don't have information on all of these, only that they exist.  I
    would greatly appreciate it if someone could provide a short synopsis
    and the complete book name if you are familiar with any of these
    titles.

    Data book / Handbook / Users' Guide
        - Philips I2C devices Handbook
        - 8051 Handbook from philips (contains also complete I2C spec)
          pub no : 9397-750-00013
        - I2C peripherials for microcontrollers.
          98-8080-574 (Philips ord.nr)
          Currently depleted.Sheduled for reprint in august

    IC01   Semiconductors for Radio and Audio systems
    IC02   Semiconductors for TV and Video systems.
    IC03   Semiconductors for Telecom systems
    IC14   8048 based microcontrollers
    IC20   8051 based microcontrollers

    Le BUS I2C  (in FRENCH !!)
       By Dominique Paret
       Dunod Technique  ISBN 2-10-001717-9



D.3)  Miscellaneous documentation on i2C

    Intel Corporation
        - application notes

    Philips Semiconductors (Signetics)
        - application notes

    Databooks from Philips,Xicor,SGS Thomson etc ...


E) Troubleshooting guide.

   Right. So you have built your first system using the I2C bus and you
   find out that it doesn't work as it should.

   This section covers a few of the common pitfalls involved in using the bus.


   First thing to check is : Are the pull-up resistors connected.

      Probably the most common error is that people forget to connect a
      pull-up resistor between SDA and VCC and SCL and VCC.

      Remember : SDA and SCL are open collector or open-drain lines.
      Resistance value should be between 4K7 and 47K.

      The longer you make your lines the lower the resistance value should be.
      This is to force more current into the lines to overcome the capacitance
      formed by the lines. (This is very important if you want to run on high
      speeds)

   Check that the lines can be toggled between the logic levels.

      Check that the levels on both SDA and SCL fall into the allowed range.
      Check this both for high and low levels.

   By now you should have a bus that is capable of transporting I2C signals.
   Now you can try to send some information to a chip or read some information
   It is best to connect only one slave device to the I2C bus.

   The chip is not responding.

      Check following things in order
        Are SCL and SDA connected correctly ?
        Are you accessing the right address ?
        Has the start command been issued correctly ?.

        If you have a storage scope you can monitor the bus by connecting
        Channel 1 to SDA and channel 2 to SCL. Set the scope on Single shot
        trigger on channel 2. Set pretrigger 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


        Send a couple of stop commands and then try again.It is possible that
        the chip is locking up due to power-on effects.

        Replace the chip. It could be defective.

   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.


__________________________________________________________

I disclaim everything.  The contents of this article might be totally
inaccurate, inappropriate, misguided, or otherwise perverse - except for
my name (hopefully I got that right).

Copyright (c) 1995 by Vincent Himpe, all rights reserved.
This FAQ may be posted to any USENET newsgroup,FTP-server, on-line service,
or BBS as long as it is posted in its entirety and includes this copyright
statement.

You are allowed to extract portions of this faq to send by e-mail provided
that mention the following information:

  '' Extracted from The I2CFaq (c) Vincent Himpe. ''

This FAQ ,or portions of it, may not be distributed for financial gain.
This FAQ ,or portions of it ,may not be included in commercial collections or
  compilations without express permission from the author.

