From: NAME: Vincent Himpe To: "piclist@mitvma.mit.edu"@oberon@mrgate Newsgroups: SCI.ELECTRONICS,COMP.PROTOCOLS.MISC,SCI.ANSWERS,NEWS.ANSWERS Subject: I2c Bus FAQ Version 1.1 From: vincent.himpe@ping.be (Vincent Himpe) Followup-To:POSTER Archive-name: I2C-BUS-FAQ This article is a collection of information sources on the i2c Bus The following topics are addressed: 0) Preface 1) ABOUT THIS FAQ 1.1) Who put this FAQ together? 1.2) How can I contribute to this FAQ? 1.3) What newsgroups will this FAQ be posted to? 1.4) May I distribute this FAQ or post it somewhere else? 1.5) 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 adressing (new I2C standard) 9) ACCESS Bus A) Overview of existing I2C compatible IC's 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 0) Preface I've been around on the internet and Fidonet for some time now. And more and more often I see people asking questions about I2C. These questions range from 'general information wanted' to 'help wanted in bug-chasing'. Scouting out on the networks just turned up bits and pieces of information. Therefore i thought it was time for an I2C FAQ. This is the second release of the FAQ.Some typing errors and general errors have been corrected. Additional sections cover the new I2C standard including the FAST mode and extended adressing features. There is also a list of common I2C chips that are available from different manufacturers.However it's still far from complete. I Hope it will continue to grow out over time. The 'hull' of this FAQ was taken from the 8051-FAQ by Russ Hersh. Also check out that one.It's a great lead for people interested in I2C.Lot's of 8051 clones have an I2C controller on board. Hope its useful to you guys and girls out there. Keep those reply's coming Regards, Vincent As usual greetings go to : Russ Hersh for allowing the use of this layout. Saved me lots of typework. Phil Wood for giving additional info on books availble from Philips. Phil is a sales manager for Philips components in the USA and can be reached via E-Mail: woodp@zilker.net The guys from Philips PCALE Eindhoven . And last but not least : Stephen Phillips for pointing out grammatical errors. English is not my natural language but i guess you figuered that one out already. 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 list? If you have any suggestions or additions please inform me. You can contact me : By e-mail : Internet : Vincent.himpe@ping.be (preferred) vi_himpe@mietec.be Fido : 2:291/1912.8 By Snail-Mail : Vincent Himpe A.De Taeyelaan 12 8792 Desselgem Belgium I hope that those of you who know of interesting items for this FAQ will share with everyone by contributing to this list. A good amount of stuff is turning up thanks to everyone's help. If you are a manufacturer and have an anonymous ftp site or BBS available that has information and/or tools for the I2C Bus please let me know by EMail so that I can add it to this FAQ. Also, please feel free to update me on new products. 1.3) What newsgroups will this FAQ be posted to? This FAQ will be posted to the following newsgroups: comp.protocols.misc sci.electronics These newsgroups often contain discussions, announcements, or information about I2C. Check them out from time to time. The schedule for posting will be once a month. I can't promise that it will be on time, but I hope to post it by the end of each month. 1.4) May I 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 list for noncommercial purposes. I hereby give my permission to one and all to pass this list around and post it wherever you want - as long as it is not for financial gain. 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 : /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 : /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.And 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