Post by thread:[PIC]: I2C pullups

> I'm relatively certain that slaves do NOT drive SCL, mainly because if > you had a locked up slave holding SCL low it would prevent ANY communication > on the bus. By the spec, slaves MAY drive SCL low, which is called clock stretching. The purpose is that a slow slave can hold SCL low, after the master has released it, until the next bit is ready. The Master must wait for the actual rising edge to know the bit is valid. I have never seen a slave implementation that USES clock stretching (example: EEPROMs don't) EXCEPT one that's important to us: PIC's SSP in slave mode. As a slave, it ALWAYS pulls SCL low from the time it recognizes its slave read address, until the first byte of the response is loaded by the firmware. So it you are using a PIC as a slave, follow the spec, and provide pullups on both lines, and make sure the master is operating "open- drain", that is, pull down when presenting a low, and float the line and let the pull up present the high level. > I'm relatively certain that slaves do NOT drive SCL, mainly because if > you had a locked up slave holding SCL low it would prevent ANY communication > on the bus. TRUE. If you write I2C slave code for a PIC, you've got to be darn careful that you always respond to the SSPIF, even if you don't "think" the master wants any more data now. The SSP WILL lock the bus if you leave a slave-read (PIC slave sends data to master) transfer unfinished. -Barry. ------------ Barry King NRG Systems "Measuring the Wind's Energy" http://www.nrgsystems.com Check out the accumulated (PIC) wisdom of the ages at: PIC/PICList FAQ: http://www.piclist.com/faq -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Mike, I have a question, hope you can help! :o) I am just finishing off a board design using a 16F876 talking to 24LC256 eeprom. I am using the PIC MSSP outputs for clk and data, do these go open drain? Must they have pullup resistors? I wanted to keep the option of using bit-banging I2C (not the MSSP module) and in this mode the data and clk will be normal PIC output pins. So do I read you right that I need 2 pullup resistors, AND also 2 pass resistors to stop problems when the PIC pins go high and the eeprom pins may hold low?? I really don't want to switch the PIC pins from outputs to inputs at high frequencies. I prefer to leave them always as outputs, at least the clk pin. Thanks, -Roman Mike Harrison wrote: {Quote hidden}> >I must disagree. A slave on the i2c bus can also drive SCL low (clock > >stretching) - so if you actually drive SCL high with the master, and the > >slave drives SCL low, you've got a short. Perhaps these particular > >devices never do this - I don't know - but they are allowed to by the i2c > >spec. So to have a standard i2c interface, you need pullups on both SDA > >and SCL, and the only way you make either high is to set it as an input > >and let the pullup float it high. > Although the spec allows for it, I have never encountered a device > which does this. EEProms certainly never do. > In practice you shouldn't worry about driving SCL both ways and > omitting the pullup unless the slave device datasheet says it uses > clock stretching. > If a device _did_ use clock stretching, you would have to adapt the > code as well to cope with it. > > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

On Thu, 15 Mar 2001 22:52:47 +1100, you wrote: >Mike, I have a question, hope you can help! :o) >I am just finishing off a board design using a >16F876 talking to 24LC256 eeprom. >I am using the PIC MSSP outputs for clk and data, >do these go open drain? I have no direct experience of using the on-board I2C module, but the datasheet shows that it uses the pins as open-drain to be able to implement the full spec for the devices that need it, so you'd need both pullups. >Must they have pullup >resistors? I wanted to keep the option of using >bit-banging I2C (not the MSSP module) and in this >mode the data and clk will be normal PIC output >pins. If you're bit-banging and driving SCL fully, you don't need the pullup. Yuu always need an SDA pullup. >So do I read you right that I need 2 pullup >resistors, AND also 2 pass resistors to stop >problems when the PIC pins go high and the eeprom >pins may hold low?? No - you never need series resistors. If you have slave devices which can stretch the clock, you use a pullup and drive it open-drain. > I really don't want to switch >the PIC pins from outputs to inputs at high >frequencies. I prefer to leave them always as >outputs, at least the clk pin. You will always have to switch SDA in/out to fake an open-drain output. Unless you implement clock-stretching you can keep SCL as an output all the time. To summarise, If you're just talking to an eeprom, you don't need an SCL pullup if bit-bashing, but would if using the MSSP. I'd allow for an SCL pullup on the PCB - it won't hurt if you don't use it but would be a pain to add later if you decided to use the MSSP! {Quote hidden}>Thanks, >-Roman > > > >Mike Harrison wrote: > >> >I must disagree. A slave on the i2c bus can also drive SCL low (clock >> >stretching) - so if you actually drive SCL high with the master, and the >> >slave drives SCL low, you've got a short. Perhaps these particular >> >devices never do this - I don't know - but they are allowed to by the i2c >> >spec. So to have a standard i2c interface, you need pullups on both SDA >> >and SCL, and the only way you make either high is to set it as an input >> >and let the pullup float it high. >> Although the spec allows for it, I have never encountered a device >> which does this. EEProms certainly never do. >> In practice you shouldn't worry about driving SCL both ways and >> omitting the pullup unless the slave device datasheet says it uses >> clock stretching. >> If a device _did_ use clock stretching, you would have to adapt the >> code as well to cope with it. >> >> >> -- >> http://www.piclist.com hint: The PICList is archived three different >> ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Roman, > So do I read you right that I need 2 pullup > resistors, AND also 2 pass resistors to stop > problems when the PIC pins go high and the eeprom > pins may hold low?? I really don't want to switch > the PIC pins from outputs to inputs at high > frequencies. I prefer to leave them always as > outputs, at least the clk pin. In my designs, I have always switched from I to O and back as needed. Set the pin to I for a logic 1, and to O (that's an O for output, not a zero) to drive the pin low. At the same time, I also make sure that the corresponding bit is low so it drives the pin low (as opposed to accidentally driving it high when low was intended). That's according to spec, but have seen lots o' designs which drive SCL both directions. Also, my designs are all bit-banged I2C, not using an MSSP. If their devices are following the spec, they should never be driving the line high, either, and therefore you wouldn't need the current limiting resistors, just the pull-up's. -- Mitch -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Mike Mansheim wrote: > > > ... I really don't want to switch > > the PIC pins from outputs to inputs at high > > frequencies. I prefer to leave them always as > > outputs, at least the clk pin. > > I get the feeling this is a general rule of thumb amongst veteran pic > users. If anyone feels like discussing it, I'd like to learn why! > Also, is the high frequency in this case your i2c bus frequency? Yes the high frequency is the I2C bus frequency. I don't like changing from in to outs as I am a hardware guy. I like to design the input and output circuits as best as I can and that means making them dedicated with whatever capacitance and filtering is best for their exact purpose. Changing them from out to in means they go from being held at a steady voltage to going high impedance, floating if you like. The rare times I do this I prefer to change from output to input, wait for a settling time, then use as an input. I'm just a fussy hardware guy that likes to design stuff that leaves no failure "grey areas". In this case I do need to change from out to in to sense the ack signal from the eeprom slave, so I will do this only when it is required and actively drive the SDA for all other data. Many guys who know PICs much better than me always design stuff to constantly switch between inputs and outputs. Must be a personality thing?? I just like the least possible things that can go wrong. ;o) -Roman -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email spam_OUTlistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Thanks Mitch. I think i have settled on only switching to input for the ack wait period. I am sending blocks of 32 bytes, so my plan is to just drive SDA from the PIC using bit-banging and then switch to input for the ack. Its the simplest way i think. :o) -Roman M. D. Miller wrote: {Quote hidden}> > Roman, > > > So do I read you right that I need 2 pullup > > resistors, AND also 2 pass resistors to stop > > problems when the PIC pins go high and the eeprom > > pins may hold low?? I really don't want to switch > > the PIC pins from outputs to inputs at high > > frequencies. I prefer to leave them always as > > outputs, at least the clk pin. > > In my designs, I have always switched from I to O and back as needed. Set > the pin to I for a logic 1, and to O (that's an O for output, not a zero) to > drive the pin low. At the same time, I also make sure that the > corresponding bit is low so it drives the pin low (as opposed to > accidentally driving it high when low was intended). That's according to > spec, but have seen lots o' designs which drive SCL both directions. Also, > my designs are all bit-banged I2C, not using an MSSP. If their devices are > following the spec, they should never be driving the line high, either, and > therefore you wouldn't need the current limiting resistors, just the > pull-up's. > > -- Mitch > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

Roman Black wrote: > > Thanks Mitch. I think i have settled on only > switching to input for the ack wait period. > I am sending blocks of 32 bytes, so my plan > is to just drive SDA from the PIC using > bit-banging and then switch to input for > the ack. Its the simplest way i think. :o) > -Roman Roman: I haven't doe I2C for a while but I wonder if you can do what you say and still meet the I2C protocal requirements. -- Rich -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email .....listservKILLspam.....mitvma.mit.edu with SET PICList DIGEST in the body

On Fri, 16 Mar 2001 23:59:12 +1100, you wrote: {Quote hidden}>Mike Mansheim wrote: >> >> > ... I really don't want to switch >> > the PIC pins from outputs to inputs at high >> > frequencies. I prefer to leave them always as >> > outputs, at least the clk pin. >> >> I get the feeling this is a general rule of thumb amongst veteran pic >> users. If anyone feels like discussing it, I'd like to learn why! >> Also, is the high frequency in this case your i2c bus frequency? > > >Yes the high frequency is the I2C bus frequency. >I don't like changing from in to outs as I am a >hardware guy. I like to design the input and output >circuits as best as I can and that means making them >dedicated with whatever capacitance and filtering >is best for their exact purpose. > >Changing them from out to in means they go from >being held at a steady voltage to going high impedance, >floating if you like. No they don't as there is an external pullup. >Many guys who know PICs much better than me always >design stuff to constantly switch between inputs and >outputs. Must be a personality thing?? I just like >the least possible things that can go wrong. ;o) If it makes you feel happier, think of it as not so much switching from input to output as enabling a pull-down to create an effectively open-drain signal. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

>Thanks Mitch. I think i have settled on only >switching to input for the ack wait period. >I am sending blocks of 32 bytes, so my plan >is to just drive SDA from the PIC using >bit-banging and then switch to input for >the ack. Its the simplest way i think. :o) Sorry to enter the discussion so late, but I second Bob's recommendation that the TRIS toggling method is safe. I've got it running at 20MHz clearing/setting the TRIS bits to simulate open-drain operation without a single glitch. Actually, I would feel less comfortable in driving the signals directly due to the bus contention in the case of the slave holding the clock low. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

Richard Ottosen wrote: > > Roman Black wrote: > > > > Thanks Mitch. I think i have settled on only > > switching to input for the ack wait period. > > I am sending blocks of 32 bytes, so my plan > > is to just drive SDA from the PIC using > > bit-banging and then switch to input for > > the ack. Its the simplest way i think. :o) > > -Roman > > Roman: > I haven't doe I2C for a while but I wonder if you can do what you say > and still meet the I2C protocal requirements. Hi Rich. I have read the eeprom datasheet pretty thoroughly and this should work with this particular eeprom chip. I'm not trying to get a "proper" universal I2C bus going. The eeprom datasheet says "the master must release the SDA line at this point to allow the slave to generate an ack" which seems to imply to me that the entire 32byte block can be sent without releasing the SDA, then just release it for the ack. :o) -Roman -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

Drew Vassallo wrote: > > >Thanks Mitch. I think i have settled on only > >switching to input for the ack wait period. > >I am sending blocks of 32 bytes, so my plan > >is to just drive SDA from the PIC using > >bit-banging and then switch to input for > >the ack. Its the simplest way i think. :o) > > Sorry to enter the discussion so late, but I second Bob's recommendation > that the TRIS toggling method is safe. I've got it running at 20MHz > clearing/setting the TRIS bits to simulate open-drain operation without a > single glitch. Actually, I would feel less comfortable in driving the > signals directly due to the bus contention in the case of the slave holding > the clock low. Ok guys, i'm bending to your way now. :o) My bit rate is slow anyway, about 7500Hz. -Roman -- http://www.piclist.com hint: To leave the PICList KILLspampiclist-unsubscribe-requestKILLspammitvma.mit.edu

Roman Black wrote: {Quote hidden}> > Richard Ottosen wrote: > > > > Roman Black wrote: > > > > > > Thanks Mitch. I think i have settled on only > > > switching to input for the ack wait period. > > > I am sending blocks of 32 bytes, so my plan > > > is to just drive SDA from the PIC using > > > bit-banging and then switch to input for > > > the ack. Its the simplest way i think. :o) > > > -Roman > > > > Roman: > > I haven't doe I2C for a while but I wonder if you can do what you say > > and still meet the I2C protocal requirements. > > Hi Rich. I have read the eeprom datasheet pretty > thoroughly and this should work with this particular > eeprom chip. I'm not trying to get a "proper" > universal I2C bus going. > > The eeprom datasheet says "the master must release > the SDA line at this point to allow the slave to > generate an ack" which seems to imply to me that > the entire 32byte block can be sent without > releasing the SDA, then just release it for the ack. > :o) > -Roman > When you put it that way, it does make it sound OK. :-) I do, however, vote for using the TRIS register to do an open drain output. As mentioned by others, speed of read/modify/writes does not apply to the internal register since there is no unknown capacitive load on the TRIS register "pin". -- Rich > -- > http://www.piclist.com hint: To leave the PICList > RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList spamBeGonepiclist-unsubscribe-requestspamBeGonemitvma.mit.edu

Richard Ottosen wrote: > > The eeprom datasheet says "the master must release > > the SDA line at this point to allow the slave to > > generate an ack" which seems to imply to me that > > the entire 32byte block can be sent without > > releasing the SDA, then just release it for the ack. > >:o) > > -Roman > > > > When you put it that way, it does make it sound OK. :-) > > I do, however, vote for using the TRIS register to do an open drain > output. As mentioned by others, speed of read/modify/writes does not > apply to the internal register since there is no unknown capacitive load > on the TRIS register "pin". Yep. I think I have been swayed to this method by quite a few posts, thank you Richard and also thanks to everyone who offered advice. Seems the possible problems of conflicting high/low on the I2C SDA line is greater than the possible problems from switching the pin from output to input with every bit. In a perfect world I would use a series resistor AND pullup resistor, and just change to input for checking the ACK. But my board is so full it already has no room and is costing us extra for hole density per square inch. It's a small board with LOTS of air... :o) -Roman -- http://www.piclist.com hint: To leave the PICList TakeThisOuTpiclist-unsubscribe-requestEraseMEspam_OUTmitvma.mit.edu

> -----Original Message----- > From: Kevin Blain [SMTP:RemoveMEkevinbspam_OUTKILLspamWOODANDDOUGLAS.CO.UK] > Sent: Monday, March 19, 2001 9:24 AM > To: RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU > Subject: Re: [PIC]: I2C pullups > > When you TRIS a pin as input, then read it, does that not put a logic 1 in > the PORT register if the pin is pulled up? If so, when the pin is TRIS'd > to > output again, it will be outputting logic 1.?? > The port latch is only changed if a Write or Read Modify Write instruction is executed on the port. So if a pin is set as an input, and then a BSF/BCF etc is performed on the port, the port latch for that pin will be set to whatever state the pin is at. This won't happen by simply reading the state of the port however. Regards Mike {Quote hidden}> Therefore, care should be taken when doing I2C in this method to make sure > that the pin is set to output 0 whenever you tris back to an output. > > Regards, Kevin. > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics > > -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Kevin wrote: >When you TRIS a pin as input, then read it, does that not put a logic 1 in >the PORT register if the pin is pulled up? If so, when the pin is TRIS'd to >output again, it will be outputting logic 1.?? > >Therefore, care should be taken when doing I2C in this method to make sure >that the pin is set to output 0 whenever you tris back to an output. As an aside, when doing open-collector code I clear the port pin just before I change it to output. Just to sure that the pin will be low when I need it to be! Helps to avoid having a nasty level collision on a OR'd bus line. Regards... ___________________________________________ David Duffy Audio Visual Devices P/L U8, 9-11 Trade St, Cleveland 4163 Australia Ph: +61 7 38210362 Fax: +61 7 38210281 New Web: http://www.audiovisualdevices.com.au New email: avdSTOPspamspam_OUTaudiovisualdevices.com.au ___________________________________________ -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

>Therefore, care should be taken when doing I2C in this method to make sure >that the pin is set to output 0 whenever you tris back to an output. Also, don't overlook the fact that whenever ANY bit operation is done on ANY pin on the same port that you've got the I2C, you have to reset the latch to zero before you use your I2C routines again. Note that this applies to interrupt routines as well. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

>>Therefore, care should be taken when doing I2C in this method to make sure >>that the pin is set to output 0 whenever you tris back to an output. > >As an aside, when doing open-collector code I clear the port pin just >before >I change it to output. Just to sure that the pin will be low when I need it >to be! >Helps to avoid having a nasty level collision on a OR'd bus line. >Regards... I would be careful using this method of resetting the latches, because this won't work if you have ISR's that access the port pins. You have to reset the latch inside the ISR, not just before you tris the pin. --Andrew _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

On Mon, 19 Mar 2001 09:23:35 -0000, you wrote: >When you TRIS a pin as input, then read it, does that not put a logic 1 in >the PORT register if the pin is pulled up? If so, when the pin is TRIS'd to >output again, it will be outputting logic 1.?? No. However if you do a read-modify write (bsf,bcf) on another pin on the port (e.g. SCL), and the input is pulled high externally. this WILL rewrite the output register with a 1, so you do need to be careful. If in doubt use a BCF or explicit zero write on the pin before turning it back to an output. BCF is ok on the pin in question as it will ignore the previous state, but this is not a good idea if there are other input pins on the port whose output ports you don't want to change. This is actually another argument for not using open-drain on SCL, so you don't have to worry about messing up SCL when SDA changes! >Therefore, care should be taken when doing I2C in this method to make sure >that the pin is set to output 0 whenever you tris back to an output. Exactly. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics