Post by thread:I2C

I've done master and slave in software on PIC. I think the master runs slower than most hardware driven masters, but who is counting cycles when you can do it all on 2 wires. The slave runs at a compatible speed to the master software. Our most complex I2C setup is: Master PIC with lots of logic, LCD, keypad, etc 0 Clock/alarm (via interrupt line) device for time keeping, 24 hou r wakeup alarms, etc. 2 8 kByte memory device 3 PIC with 6 line serial link to a PC. Non-I2C interrupt line to master when a message arrives The interrupt lines are needed to trigger the master to read from the device when an event occurs. <spam_OUTedtoddTakeThisOuTsni.net> Ed Todd

Hi, I have spent a torrid weekend trying to get my 16C74 communicating with a 24LC16B I2C memory chip. I just want to store a value at a time down and then retrieve the values for display on an LCD unit (this side of it works fine). I have based my efforts on AN578, but this uses a multi-master environment that is controlled through interrupts. I have therefore removed all the interrupt and keyboard stuff and just use the RDBYTE and WRBYTE routines. It appears to write ok but the values read back seem to be garbage. So my questions are: 1) Is there any point using the I2C features on the 16C74 for my application (or is it all done in software - as all the modes supported are slave modes). 2) Do I need interrupts. 3) Is there a better example (code etc) anywhere which shows me more clearly. I expect you've had similar questions to these before - sorry!! Thanks for any help, Steve (Parker). PS: the application is storing altitude values in a model rocket.

Have a look at AN567. The code is very simple and easy to use. Regards Steen Jensen From: .....Steve.ParkerKILLspam@spam@SRC.BAE.CO.UK on 23-02-98 12:07 GMT Please respond to PICLISTKILLspamMITVMA.MIT.EDU To: .....PICLISTKILLspam.....MITVMA.MIT.EDU cc: (bcc: Steen Schelle Jensen/Sales/DK_GDK/Grundfos) Subject: I2C Hi, I have spent a torrid weekend trying to get my 16C74 communicating with a 24LC16B I2C memory chip. I just want to store a value at a time down and then retrieve the values for display on an LCD unit (this side of it works fine). I have based my efforts on AN578, but this uses a multi-master environment that is controlled through interrupts. I have therefore removed all the interrupt and keyboard stuff and just use the RDBYTE and WRBYTE routines. It appears to write ok but the values read back seem to be garbage. So my questions are: 1) Is there any point using the I2C features on the 16C74 for my application (or is it all done in software - as all the modes supported are slave modes). 2) Do I need interrupts. 3) Is there a better example (code etc) anywhere which shows me more clearly. I expect you've had similar questions to these before - sorry!! Thanks for any help, Steve (Parker). PS: the application is storing altitude values in a model rocket.

Check out my PIC84 to 24LC16B test program. It may be of help to you. It is under the "Engineering Design and Support Files" section at: http://www.siliconsoft.com/ftp1site.htm -Wayne Foletta SiliconSoft, Inc. You wrote: {Quote hidden}> > Hi, > I have spent a torrid weekend trying to get my 16C74 communicating > with a 24LC16B I2C memory chip. I just want to store a value at a > time down and then retrieve the values for display on an LCD unit > (this side of it works fine). I have based my efforts on AN578, > but this uses a multi-master environment that is controlled through > interrupts. I have therefore removed all the interrupt and keyboard > stuff and just use the RDBYTE and WRBYTE routines. It appears to > write ok but the values read back seem to be garbage. So my > questions are: > 1) Is there any point using the I2C features on the 16C74 for my > application (or is it all done in software - as all the modes > supported are slave modes). > 2) Do I need interrupts. > 3) Is there a better example (code etc) anywhere which shows me > more clearly. > I expect you've had similar questions to these before - sorry!! > Thanks for any help, > Steve (Parker). > PS: the application is storing altitude values in a model rocket. >

I am developing a I2C bus on a 68HC11. I will be using PICs on the peripherals. What is the least expensive PIC that has I2C on board? Dose anyone know where a bit bang routine for a PC parallel port is available and does are there any standard documents for I2C? I am new to the list and new to PICs so I mostly a consumer of information on PICs at the present. This will change. I am a pretty good source of information on embedded systems in general I have been doing then for 10 years now. Thanks Gordon Gordon Couger EraseMEgcougerspam_OUTTakeThisOuTrfdata.net 624 Cheyenne Stillwater, OK 74075 405 624-2855 GMT -6:00

Hi Gordon <gcougerspam_OUTrfdata.net> and PIC people. I've been working with I2C networked PICs for some time now, developing a smart front panel for hi-fi. Debugging this kind of thing, even with a storage scope, is like driving screws with your thumbnail. It's bad enough debugging one gadget, but if the other gadgets are of unknown re liability and written by someone else, then you can get into finger-pointing standoffs with other enginee rs. I developed an I2C snooping tool for my PC, so that I could do things like read a whole EEPROM on screen as hex bytes. I can exchange particular messages to I2C slaves. I can tell my panel to shut do wn its application, read its switches and rotor, then write text to the display. Most usefully, I can gat her evidence to say "look mate, your gadgets writing the wrong data to EEPROM, it's _your_ bug!" The I2C hardware is simple. STB drives SDA, AFD drives SCL. These are open-colle ctor outputs with pull-ups. Some chips like the 16C552 read the STB and AFD _pins_ back, but some may return nothing (write only) or the bits driving the OC buffers. For this reason, I've made it so SDA is sensed by BSY, SCL is sensed by ACK. This is easier to optoisolate if needed, and easier to tell if the PC or a slave is driving a signal low. I'd advise isolation for anything remotely connected to the mains. Yesterday I p lugged a TV aerial cable into my I2C- programmable TV tuner/teletext project. I was shocked (literally) t o find 144VDC between the co-ax cable and my project ground. Turns out this condition exists while the liv ing-room TV is in standby mode (it shares the same aerial). Okay it is obviously of non-lethal impedance, but if it caused me to say ouch!' then it may damage chips. Just shows that opto-isolating your PC->I2C in terface is welcome insurance against unexpected nasties! Once you have the code, you can use the same routines for I2C debugging tools an d hobby projects. I wrote my code in plain old C, so I can port it to micros if I wish, or wrap it in a DLL for Windows. Hope these tips help. Keith.

You can find a detailed description of how to use the I2C bus on the Philips site, www-us.semiconductors.philips.com. The document of interest would be, "The I2C bus and how to use it." Look under microprocessors. As for the slave address. Typically the upper address range of a slave devices is hard coded. And the lower 3 lsb of the address range is user selectable. I2C uses a 7 bit address range (there's also a 10 bit, but you can read up on that on your own). Later DW {Original Message removed}

Some I2C devices have a hardwired ID code (according to some predefined ID ranges for particular devices in the I2C spec.), while other devices allow you to set at least some part of the ID code by grounding some input pins (typically 3, for 8 possible addresses). CIAO - Martin. ______________________________ Reply Separator _________________________________ Subject: I2C Author: pic microcontroller discussion list <@spam@PICLISTKILLspamMITVMA.MIT.EDU> at Internet Date: 6/11/98 10:56 AM Hi All, An usaul quick question, The I2C bus supply mulitple devices, correct ? You have to address them, so how the receiving device will know what is its address ? Where can I find the detailed description of I2C bus ? Lots of thanks, Peter

On Thu, 11 Jun 1998, Peter Schultz wrote: > The I2C bus supply mulitple devices, correct ? In general right. Some serial EEPROMS have restricted address capability. Hence it is allowed to have only one of them per I2C bus. > You have to address them, so how the receiving device will know what is its > address ? > Where can I find the detailed description of I2C bus ? Have a look in the datasheet of the PIC17C75X there is a long appendix about I2C. You can find it on the Web page of microchip (http://www.microchip.com). I guess it is also written in datasheets of other PICs. Good look! Andreas, London, UK ------------------------------------------------------------------------------ my e-mail addresses: KILLspamA.DanteKILLspamCity.ac.uk RemoveMEdanteTakeThisOuTsnoopy.e-technik.uni-dortmund.de ------------------------------------------------------------------------------

Peter Schultz wrote: > Hi All, > An usaul quick question, > The I2C bus supply mulitple devices, correct ? > You have to address them, so how the receiving device will know what is its > address ? > Where can I find the detailed description of I2C bus ? > Lots of thanks, > Peter Here are a few links : http://www.wasp.co.za/~tjaart/electronicsearch.html -- Friendly Regards Tjaart van der Walt spamBeGonetjaartspamBeGonewasp.co.za |--------------------------------------------------| | WASP International | |R&D Engineer : GSM peripheral services development| |--------------------------------------------------| |SMS TakeThisOuT0832123443EraseMEspam_OUTwasp.co.za (160 chars max)| | http://www.wasp.co.za/~tjaart/index.html | |Voice: +27-(0)11-622-8686 Fax: +27-(0)11-622-8973| | WGS-84 : 26¡10.52'S 28¡06.19'E | |--------------------------------------------------|

I'd recommend getting it straight from the horses mouth, i.e. Philips. That's where Microchip got it from, to write their own text. Why risk transcription errors? It is a very clever bus, and well thought out, but Microchip's app notes are virtually or worse than useless. It's unfortunate that it is possible to write I2C code that seems to work but is not completely correct or robust. If I were Microchip, I'd be embarrassed to publish these notes as they indicate an inadequate understanding of the I2C bus and software to drive it. If they can't provide code to drive the I2C bus properly, have they ever fully tested their hardware? Believe me, their SSP I2C hardware is pretty half-assed.

> Van: Andreas Dante <RemoveMEdanteTakeThisOuTsnoopy.E-Technik.Uni-Dortmund.DE>> > Aan: PICLISTEraseME.....MITVMA.MIT.EDU > Onderwerp: Re: I2C > Datum: donderdag 11 juni 1998 22:51 > > On Thu, 11 Jun 1998, Peter Schultz wrote: > > The I2C bus supply mulitple devices, correct ? > In general right. Some serial EEPROMS have restricted address capability. > Hence it is allowed to have only one of them per I2C bus. This is not a restriction in the EEPROM itself, but by way of adressing-space. All Memory-devices should have an Device adres address of 1010AAA? Binary. (AAA == Device sub-address. can be set on pins 1, 2 & 3. ? is the Read/Write bit) Regard a 2048-byte RAM/EEPROM as eight seperate devices thrown together, and it'll make more sense (you _address_ them as eight devices, from A0 thru AE (disregarding the Read/write bit) ). Add to this the secondary address-byte and there you have your memory-limit. (Extended adressing modi devices have a special base-address) [Cut] Greetz, Rudy Wieser

part 0 1490 bytes content-type:multipart/alternative; boundary="------------0FFBDACECAC875829620D" (decoded 7bit) --------------0FFBDACECAC875829620D7B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Hi All, > There are some code athttp://margo.student.utwente.nl/el/ports/i2c/i2c .zip Algorithm for accessing an I2C bus. i2c_faq .zip I2C FAQ by Vincent Himpe. pci2c .zip Philips I2C monitoring program !! It uses the PC printerport. pci2cbd .zip Schematic (only a few ports) for using the Philips I2C monitoring program. Very interesting for beginners --------------0FFBDACECAC875829620D7B2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> <BLOCKQUOTE TYPE=CITE> <PRE>Hi All,</PRE> </BLOCKQUOTE> There are some code atmargo.student.utwente.nl/el/ports/i2c/i2c &nbs p;     .zip    Algorithm for accessing an I2C bus. i2c_faq   .zip    I2C FAQ by Vincent Himpe. pci2c     .zip    Philips I2C monitoring program !! It uses the PC printerport. pci2cbd   .zip    Schematic (only a few ports) for using the Philips I2C monitoring program. Very interesting for beginners    </HTML> --------------0FFBDACECAC875829620D7B2-- part 1 260 bytes content-type:text/x-vcard; charset=us-ascii; name="vcard.vcf" (decoded 7bit) begin: vcard fn: Jose Antonio Gracia Negre n: Gracia Negre;Jose Antonio email;internet: EraseMEjgranecolon.net x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard

I am using a PIC 16C74A @ 4Mhz in my design. I am attempting to use the I2C module in the master mode. I am addressing a 24C01C device for non-Volatile memory. I am looking for some assembly code to do this with. The things I have found at Microchips are either too encrypted to follow or are for processors which are to different from the PIC I am using. If anyone could help I would greatly appreciate it Jess LaFentres Electro/Mech. Eng. Global Surgical Corp. 3610 Tree Court Ind. Blvd. St. Louis MO 63122-6622 (314)861-5286 Phone (314)225-2036 Fax RemoveMEjlafentrEraseMEEraseMEglobalsurgical.com

I've done it with C77 as master and 74A as slave in the production version, but have run the master code on the 74A as a testbed when we ran out 77s back in the spring, and couldn't source any (remember that fiasco ? Nobody could get a 77 to save their grandmother's life for about 6 weeks back in March/April sometime). Anyway, the code is in production, so it works. The gotcha is that it's for C (Hi-Tech flavour). The upside is that, except for the actual bit bashing that shoves the 1's & 0's out the door, the rest is pretty much 1-for-1 mappable to assembly code. Except for the bank switching, too, of course 8^) If you are still interested, even though its in C, let me know. Ken ---------------------------------------------- Kenneth C. Finney ============================================== Wilkes Associates, Inc. Software Engineering - Embedded Systems Design & Development - Project Management ============================================== 170 The Donway West Ste. 405, Toronto, Ontario Office: (416) 445-9224 Mobile: (416) 453-6400 ---------------------------------------------- > {Original Message removed}

Yes, I've checked the archives, still uncertain, and reluctant to ask. Trying initially to get an F84 to talk to a 24LC65 but have other I2C ICs in the wings. No problem with start bits or bytes but have run into difficulty over the 9th clock pulse. I have the Philips guide to I2C as well as AN515 (are the sub headings mixed up BTW ?) and Nicole Ambrose's program from the archives. Unfortunately everything else relating to I2C at the archives seems to be unavailable. I'm uncertain because every sample of code I look at seems to be using a different method at the 9th pulse to determine Ack. I won't go into details but suffice to say I'm confused. Part of the reason is sparse commenting on code, but we've been there before haven't we. Notes like "move FF into the accumulator" after movlw 0ffh aren't particularly helpful. Plenty of what-it-does but hardly any why- it-does-it. OK, what I'd like to know specifically is - after the 8th data bit has been clocked into the EEPROM, do you change the PIC SDA to an i/p to test Ack or can you just send a "dummy" 9th pulse out, and assume on a single-memory bus that Ack has been generated ? Nowhere have I seen an explicit direction to change SDA direction at Ack testing time and can't tell whether there's an implied one. Can someone take a minute to give a blow-by-blow, doesn't even have to be code, about I2C procedure please. Jinx

After the 8th bit, the EEPROM should pull the data line low for an ACK or leave it high for NACK. The IIC bus must be pulled high with resistors (1k or 10k depending on how fast you want to go) and the PIC must only drive low (not drive high) .. open-drain outputs are ideal for this but you can achieve the same effect by seting the PORT bits low and using the TRIS bits to drive the line low or let the resistors pull it high. I have code for a 17C756 talking to a 24C64 here: http://kdsl32.dnvr.uswest.net/cgi-bin/tl.exe/AERC/poscalc/eeprom.asm It is commented .. I think pretty well but I haven't gotten anyone else's opinions yet. The port initializations (after reset) are here: http://kdsl32.dnvr.uswest.net/cgi-bin/tl.exe/AERC/poscalc/init1.asm Note that RA2 and RA3 are open-drain outputs on the 17C756, specifically designed for IIC or similar applications. On a normal output you would simply program the PORT bit low and toggle the TRIS bit in the same manner as the PORT bits are toggled in my 17C756 code. Hope this helps, Ken {Quote hidden}>Yes, I've checked the archives, still uncertain, and reluctant to ask. >Trying initially to get an F84 to talk to a 24LC65 but have other I2C >ICs in the wings. No problem with start bits or bytes but have run >into difficulty over the 9th clock pulse. > >I have the Philips guide to I2C as well as AN515 (are the sub >headings mixed up BTW ?) and Nicole Ambrose's program from >the archives. Unfortunately everything else relating to I2C at the >archives seems to be unavailable. > >I'm uncertain because every sample of code I look at seems to be >using a different method at the 9th pulse to determine Ack. I won't >go into details but suffice to say I'm confused. Part of the reason is >sparse commenting on code, but we've been there before haven't >we. Notes like "move FF into the accumulator" after movlw 0ffh >aren't particularly helpful. Plenty of what-it-does but hardly any why- >it-does-it. > >OK, what I'd like to know specifically is - after the 8th data bit has >been clocked into the EEPROM, do you change the PIC SDA to >an i/p to test Ack or can you just send a "dummy" 9th pulse out, >and assume on a single-memory bus that Ack has been generated ? >Nowhere have I seen an explicit direction to change SDA direction >at Ack testing time and can't tell whether there's an implied one. > >Can someone take a minute to give a blow-by-blow, doesn't even >have to be code, about I2C procedure please. > >Jinx

>Thanks, helpful. One reason I wanted a text explanation is because >it can be heavy-going sorting out calls and labels, even in a smallish >program, especially when there's a something you don't understand. >Open-drain pin RA4 would be the pin to use for SDA on an F84 then >to make life a little easier ? Perhaps. I actually found the ordinary pins quite easy to use on a 16C74, particularly because it is ok to use BCF and BSF directly on the TRISA, TRISB, or TRISC registers (thus you needn't use a mirror register like you do with PORTA, PORTB, or PORTC with read-modify-write instructions). For example, with an open-drain pin: BSF PORTA_MIRROR,2 MOVF PORTA_MIRROR,W MOVWF PORTA With an ordinary pin: Initialization: CLRF PORTA Toggling a pin high: BSF STATUS,RP0 BSF TRISA,2 BCF STATUS,RP0 A shortcut I often used was to point FSR at TRISA at the start of a subroutine that talks to the EEPROM. Then, in the body of ths subroutine, I could use the following (instead of switching STATUS,RP0 back and forth): BSF INDF,2 So, actually, I think it is easier to not use an open-drain pin as long as you can use 2 pins on the same port and point FSR to that port. For the 17C756 I chose to use the open-drain pins only because they were not useful for anything else and I was short on pins. I just found my code for a 16C74 talking to a 24C65. It gives a good example of using ordinary (not open drain) outputs. I posted it here: http://ken.webster.org/picee.txt The program I chopped it out of is here: http://kdsl32.dnvr.uswest.net/cgi-bin/tl2.exe/MPLAB/GPSPOS/main.asm Ken

On Sat, 8 Jan 2000, Ken Webster wrote: > BSF PORTA_MIRROR,2 > MOVF PORTA_MIRROR,W > MOVWF PORTA Uh-oh, really? I'm new to pic, I simply assumed that BxF would work on the output ports directly, either by RMW or bit-addressability. (Seems unlikely the TRIS trick will help me, I need to generate ~500KHZ on PA2, almost certainly hard pullup will be required.) The documentation doesn't say anything about this, but DOES say: "All write operations are read-modify-write operations, therefore a write to a port implies that the port pins are read, the value is modified, and then written to the port data latch". When I first read that, my reaction was "So what?", perhaps it should have been "What are they trying (and failing) to say?"

On Sun, Jan 09, 2000 at 04:49:51PM -0800, Rich Leggitt wrote: > Uh-oh, really? I'm new to pic, I simply assumed that BxF would work on the > output ports directly, either by RMW or bit-addressability. A BxF will always work, for the bit you select. It is the other bits in the same port that may mysteriously change state from what you set them too. The read phase of the BxF reads the port pins, not the port latches. > When I first read that, my reaction was "So what?", perhaps it should have > been "What are they trying (and failing) to say?" Exactly. -- James Cameron RemoveMEquozlspam_OUTKILLspamus.netrek.org http://quozl.us.netrek.org/

On Sun, Jan 09, 2000 at 09:41:31PM -0800, Rich Leggitt wrote: > OK, thanks, point noted. However, assuming that the output is well > buffered then is there any reason why a read always return the current > output state? But I will certainly no longer expect it hold state when > TRIS'd. I think you're asking how long it will take for the voltage on the pin (that is read in by a BxF instruction) will take to reach the point that agrees with the port latch. Depends on the capacitance of the pin, the package, the socket, the PCB traces, and the remaining electrical circuit beyond the pin. It can never be zero time, unless you had infinite driving current. Yes, "buffering" of the pin will change that. If your clock is faster, then you will notice it more often. Assuming you even code something to watch it happen. I was seriously depressed when I figured out that a square wave edge really isn't square. It made electronics so much more unpredictable. -- James Cameron RemoveMEquozlTakeThisOuTspamus.netrek.org http://quozl.us.netrek.org/