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