Post by thread:[PICLIST] I2C pullups

on 3/13/01 7:28 PM, Glenn Mitchell at spam_OUTgmitchTakeThisOuT101FREEWAY.COM wrote: > Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS. The > datasheets state the SDA line needs to be pulled up. No mention of using a > pullup on SCL. Then in Serial PIC'n it says pullups are required on both > lines. Which is correct? Thanks for any help. Both lines require pullups. You might want to check the Phillips Semiconductor I2C specification. It's downloadable free from their website, but I don't remember the exact location. ------------------------------------------------------------ Roderick Mann .....rmannKILLspam@spam@latencyzero.com.sansspam -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> Hello. I am looking at the datasheets for 24LC32 and 24LC256 > EEPROMS. The > datasheets state the SDA line needs to be pulled up. No mention > of using a > pullup on SCL. Then in Serial PIC'n it says pullups are required on both > lines. Which is correct? Thanks for any help. It depends on you're masters. If you only have one master and that master can only be used in a one master environment (ie. a PIC which never selects it's SCL as an input) then it is possible that you will never need a pullup on SCL. However, to be safe I recommend putting one on the line anyways. The value depends on what kind of devices and distances are involved. TTYL -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>> Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS. >> The datasheets state the SDA line needs to be pulled up. No mention of >> using a pullup on SCL. Then in Serial PIC'n it says pullups are >> required on both lines. Which is correct? Thanks for any help. > If the master (which always drives SCL) tri-states the SCL line > then you do need the pullup on SCL. If you only have one master > in your setup and it actually swings hi-lo then you don't need it. > It depends on you're masters. If you only have one master and that > master can only be used in a one master environment (ie. a PIC which > never selects it's SCL as an input) then it is possible that you will > never need a pullup on SCL. 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. -- 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

{Quote hidden}> >> Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS. > >> The datasheets state the SDA line needs to be pulled up. No mention of > >> using a pullup on SCL. Then in Serial PIC'n it says pullups are > >> required on both lines. Which is correct? Thanks for any help. > > > If the master (which always drives SCL) tri-states the SCL line > > then you do need the pullup on SCL. If you only have one master > > in your setup and it actually swings hi-lo then you don't need it. > > > It depends on you're masters. If you only have one master and that > > master can only be used in a one master environment (ie. a PIC which > > never selects it's SCL as an input) then it is possible that you will > > never need a pullup on SCL. > > 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. 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. Slaves can of course drive SDA. Slaves tell the master that something went wrong by holding SDA low. TTYL -- 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

> 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

>> 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. > 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. Slaves can of course drive SDA. Slaves tell the > master that something went wrong by holding SDA low. Copied verbatim from the Phillips i2c bus specification .pdf file: "8.3 Use of the clock synchronizing mechanism as a handshake In addition to being used during the arbitration procedure, the clock synchronization mechanism can be used to enable receivers to cope with fast data transfers, on either a byte level or a bit level. On the byte level, a device may be able to receive bytes of data at a fast rate, but needs more time to store a received byte or prepare another byte to be transmitted. Slaves can then hold the SCL line LOW after reception and acknowledgment of a byte to force the master into a wait state until the slave is ready for the next byte transfer in a type of handshake procedure (see Fig.6). On the bit level, a device such as a microcontroller with or without limited hardware for the I2C-bus, can slow down the bus clock by extending each clock LOW period. The speed of any master is thereby adapted to the internal operating rate of this device. In Hs-mode, this handshake feature can only be used on byte level (see Section 13)." I've reversed the order that the information appears in the spec, so the above makes more sense in light of a discussion earlier in this section: "8.1 Synchronization All masters generate their own clock on the SCL line to transfer messages on the I2C-bus. Data is only valid during the HIGH period of the clock. A defined clock is therefore needed for the bit-by-bit arbitration procedure to take place. Clock synchronization is performed using the wired-AND connection of I2C interfaces to the SCL line. This means that a HIGH to LOW transition on the SCL line will cause the devices concerned to start counting off their LOW period and, once a device clock has gone LOW, it will hold the SCL line in that state until the clock HIGH state is reached (see Fig.8). However, the LOW to HIGH transition of this clock may not change the state of the SCL line if another clock is still within its LOW period. The SCL line will therefore be held LOW by the device with the longest LOW period. Devices with shorter LOW periods enter a HIGH wait-state during this time. When all devices concerned have counted off their LOW period, the clock line will be released and go HIGH. There will then be no difference between the device clocks and the state of the SCL line, and all the devices will start counting their HIGH periods. The first device to complete its HIGH period will again pull the SCL line LOW. In this way, a synchronized SCL clock is generated with its LOW period determined by the device with the longest clock LOW period, and its HIGH period determined by the one with the shortest clock HIGH period." -- 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 Mansheim wrote: > A slave on the i2c bus can .... 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. and Herbert Graf <PICLISTKILLspamMITVMA.MIT.EDU> replied: > 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. Herbert: Mike's correct; once the master has driven SCL low, a slave can hold it low. I don't think any 24Cxx serial EEPROMs do that, but other slaves do. > Slaves tell the master that something went wrong by holding SDA > low. Well, yeah... But only in the same sense that reverse-biased electrolytic caps "tell you that something went wrong" by exploding. Generally speaking, I2C devices don't contain special "error state" logic; if the bus locks up, it's usually just a natural side-effect of the communications failure. -Andy === Andrew Warren --- .....aiwKILLspam.....cypress.com === IPD Systems Engineering, CYSD === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation -- 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

{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. > > > 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. Slaves can of course drive SDA. > Slaves tell the > > master that something went wrong by holding SDA low. > > Copied verbatim from the Phillips i2c bus specification .pdf file: > > "8.3 Use of the clock synchronizing mechanism as a handshake > > In addition to being used during the arbitration procedure, the clock > synchronization mechanism can be used to enable receivers to cope with > fast data transfers, on either a byte level or a bit level. > > On the byte level, a device may be able to receive bytes of data at a > fast rate, but needs more time to store a received byte or prepare > another byte to be transmitted. Slaves can then hold the SCL line LOW > after reception and acknowledgment of a byte to force the master into a > wait state until the slave is ready for the next byte transfer in a type > of handshake procedure (see Fig.6). > > On the bit level, a device such as a microcontroller with or without > limited hardware for the I2C-bus, can slow down the bus clock by > extending each clock LOW period. The speed of any master is thereby > adapted to the internal operating rate of this device. > > In Hs-mode, this handshake feature can only be used on byte level > (see Section 13)." Ahh, well there it is, in HS mode there is no clock stretching, that's why I've never seen it. TTYL {Quote hidden}> I've reversed the order that the information appears in the spec, so > the above makes more sense in light of a discussion earlier in this > section: > > "8.1 Synchronization > > All masters generate their own clock on the SCL line to transfer messages > on the I2C-bus. Data is only valid during the HIGH period of the clock. > A defined clock is therefore needed for the bit-by-bit arbitration > procedure to take place. > > Clock synchronization is performed using the wired-AND connection of I2C > interfaces to the SCL line. This means that a HIGH to LOW transition on > the SCL line will cause the devices concerned to start counting off their > LOW period and, once a device clock has gone LOW, it will hold the SCL > line in that state until the clock HIGH state is reached (see Fig.8). > However, the LOW to HIGH transition of this clock may not change the state > of the SCL line if another clock is still within its LOW period. The SCL > line will therefore be held LOW by the device with the longest LOW > period. Devices with shorter LOW periods enter a HIGH wait-state during > this time. > > When all devices concerned have counted off their LOW period, the clock > line will be released and go HIGH. There will then be no difference > between the device clocks and the state of the SCL line, and all the > devices will start counting their HIGH periods. The first device to > complete its HIGH period will again pull the SCL line LOW. In this way, > a synchronized SCL clock is generated with its LOW period determined by > the device with the longest clock LOW period, and its HIGH period > determined by the one with the shortest clock HIGH period." > > -- > 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

On Wed, 14 Mar 2001 14:45:03 -0600, you wrote: {Quote hidden}>>> Hello. I am looking at the datasheets for 24LC32 and 24LC256 EEPROMS. >>> The datasheets state the SDA line needs to be pulled up. No mention of >>> using a pullup on SCL. Then in Serial PIC'n it says pullups are >>> required on both lines. Which is correct? Thanks for any help. > >> If the master (which always drives SCL) tri-states the SCL line >> then you do need the pullup on SCL. If you only have one master >> in your setup and it actually swings hi-lo then you don't need it. > >> It depends on you're masters. If you only have one master and that >> master can only be used in a one master environment (ie. a PIC which >> never selects it's SCL as an input) then it is possible that you will >> never need a pullup on SCL. > >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.

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 EraseMElistservspam_OUTTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

Roman, You said: > 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. and also: > 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) Well, I certainly don't think I know PICs much better than you, and I emphatically don't know as much electronics as you do, but.... If you look at the pin circuit inside the PIC, as described in the data sheet, you can see exactly what is happening when you set the TRIS bit for a pin: specifically neither the pull-up or pull-down FET can be turned on. There is no 'magic' here, and everything is well defined. Why are you uncomfortable using this capability to simulate an open-drain? What possible things do you see that can go wrong? Bob Ammerman RAm Systems (contract development of high performance, high function, low-level software) -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listservspam_OUTmitvma.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 KILLspamlistservKILLspammitvma.mit.edu with SET PICList DIGEST in the body

Bob Ammerman wrote: {Quote hidden}> > Roman, > > You said: > > > 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. > > and also: > > > 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) > > Well, I certainly don't think I know PICs much better than you, and I > emphatically don't know as much electronics as you do, but.... > > If you look at the pin circuit inside the PIC, as described in the data > sheet, you can see exactly what is happening when you set the TRIS bit for a > pin: specifically neither the pull-up or pull-down FET can be turned on. > > There is no 'magic' here, and everything is well defined. Why are you > uncomfortable using this capability to simulate an open-drain? > > What possible things do you see that can go wrong? It's not really the inside of the PIC that scares me, more the external hardware. Most of my inputs have RC filtering or such, and many of my outputs are very specific again with high loads or PWM RC networks etc. Just a general attitude that I like to make inputs be inputs and outputs should be outputs. I do make use of the RC analog converter trick, pulling a cap low and then switching pin to input and then timing how long it takes to charge, but I also use dead periods in software before I start checking the input and if I'm being extra paranoid I even write to the TRIS register twice. Possible problems: * Read/mod/write does exist with tris change, imagine a capacitive load at 5v, you change to an input, input pin reads 5v, it may take microseconds before that capacitive load drops to the proper 0v of the actual input signal. A port read reads the pin, the pin voltage can be very affected by external circuitry. Hence a settling delay in software is nice. * Switching an output to input may cause the ouptut load to turn on/off. This could cause power or inductive spike depending on load type, causing cmos register corruption, etc. I like to bring the port output to a known "safe" condition before swithing to an input, and I often write to TRIS, wait a nop or two and write to TRIS again. Just in case. Little cost, little probability but high consequence. :o) So i'm paranoid and a safety nut! Pretty funny that I get real safe and conservative about my hardware, then on weekends jump on a 150hp motorcycle and blast around a racetrack. Maybe it's a yin/yang balance thing?? ;o) -Roman -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email RemoveMElistservTakeThisOuTmitvma.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 TakeThisOuTlistservEraseMEspam_OUTmitvma.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 RemoveMElistservTakeThisOuTmitvma.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 piclist-unsubscribe-requestEraseME.....mitvma.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 EraseMEpiclist-unsubscribe-requestmitvma.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-requestEraseMEEraseMEmitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestspam_OUTKILLspammitvma.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 RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu

> -----Original Message----- > From: Kevin Blain [SMTP:KILLspamkevinbspamBeGoneWOODANDDOUGLAS.CO.UK] > Sent: Monday, March 19, 2001 9:24 AM > To: EraseMEPICLISTEraseMEMITVMA.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: .....avdspam_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. > >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

I'm looking at figure 22-2 in the 16F1936 datasheet (MSSP block diagram - I2C Master Mode), and I see nothing internal to the chip that would pull that line high, so that suggests that a pull-up resistor would be required. (It's an open drain output, with no pull up). Previously I was using a PIC16F877A which shows a buffer at that output pin, and I've never used a pull-up resistor on that line (only on the SDA line), to interface to a serial EEPROM. So I'm assuming I need a pull-up resistor for the 16F1936's SCL line now. How do I go about calculating the value of said resistor? The datasheet says nothing about it other than for SPI mode, "External pull-up/pull-down resistors may be desirable depending on the application." Thanks, -Neil.

PICdude wrote: > I'm looking at figure 22-2 in the 16F1936 datasheet (MSSP block > diagram - I2C Master Mode), and I see nothing internal to the chip > that would pull that line high, so that suggests that a pull-up > resistor would be required. (It's an open drain output, with no pull > up). Right. That's how IIC works. Both lines passively float high and are pulled actively down. Sometimes that's useful as it gets around collisions and allows multiple devices to be driving a line low, and provides a guaranteed idle state. This comes in handy for the ACK bit, during clock stretching, and in multi-master operation, for example. > Previously I was using a PIC16F877A which shows a buffer at that > output pin, I'm not sure what you mean by "shows a buffer". Of course all PIC outputs have drivers (buffers) for that purpose. These are enabled when the PIC is driving the pin, as apposed to it being a input. A few PIC pins are open drain, meaning the "buffer" is only a low side, not high/low driver. Some PIC pins, including a few on the 16F877A have passive pullups built in. These are usually too high impedence for making a good IIC bus, and don't come on by themselves just because you're using the pin for IIC. > and I've never used a pull-up resistor on that line (only > on the SDA line), to interface to a serial EEPROM. Wow, either you got very lucky or there is really a pullup lurking somewhere. Maybe you are using a pin with a weak internal pullup and it's on and you don't realize it. > So I'm assuming I > need a pull-up resistor for the 16F1936's SCL line now. How do I go > about calculating the value of said resistor? Ohms = volts / amps For example, if your system is using a 3.3V supply, then Ohms = 3.3V / 3mA = 1.1K Ohms That would be the minimum allowed pullup without exceeding the IIC spec. You want to be a little higher for safe margin, but not too much. 1.2K Ohms would be good if you want to go as fast as possible, otherwise 1.5K Ohms would be nice and safe with plenty of margin. Higher values are possible if you can guarantee to go slowly. However, higher values don't represent much of a power savings since the bits will have to be longer to compensate for the lower pullup current and the resulting longer slew times. Higher pullups also leave you open for more noise coupling. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

Neil, Depending on the capacitance of the load (up to 200pf or so), you want the pullup current to be between 3 and 12 ma generally. Obviously, the higher the current, the faster you can go, but you'll also use more power. So, unless this application is a really speed sensitive, don't care about power type, stay at the lower end of the renge. I have had good luck with resistors between about 1.2K and 10K. Generally, I use 4.7K as a rule. But the I2C comms I carry out aren't seepd sensitive meaning I don't have to talk fast. Just reliably. But, to stay within the I2C spec, you'll want at least 3ma of pullup current. With a 4.7K ohm resistor and 5v parts, you're talking about ~1ma, which isn't even close to being in spec. However, as I mentioned above, my applications use relatively slow comm rates, so I can get by with the lower current. The final choice is your. You could experiment to see what works best for you. But the spec calls for a pullup current of between 3 and 12ma. This equates to a resistance of between about 1.66K (3ma) to about 416 ohms (12ma). Regards, Jim > ---{Original Message removed}

jim@jpes.com wrote: > Depending on the capacitance of the load (up to 200pf or so), you > want the pullup current to be between 3 and 12 ma generally. Don't listen to this folks, it's just plain wrong. Standard IIC nodes are only required to provide a minimum of 3mA pulldown current to get to a logic low (The optional "fast" IIC bus specs requires up to 6mA pulldown capability). This means pullup current must be less than or equal to 3mA at logic low, not greater than 3mA. The supply voltage and the 3mA spec therefore define a *minimum* value pullup resistor. > Obviously, the higher the current, the faster > you can go, Yes. > but you'll also use more power. Not necessarily. Bus idle takes no power regardless of the pullup value. All the power is spent holding the bus lines low. The time spent low for a fixed message is inversely proportional to the bit rate. Therefore, going faster saves power. If you halve the pullup resistors but double the speed, the power will be about the same. The minimum power requirement is therefore a function of the capacitive loading, since that governs how fast you can go for a given pullup. Lower pullup resistors give you better noise immunity from outside influences, so there is some advantage to using lower pullups and going proportionately faster. > Generally, I use 4.7K as a rule. Which is rather different than the pullup current between 3 and 12 mA you recommended earlier. At 5V with 4.7K Ohms, you get barely over 1mA. Fortunately that is within spec, so it's OK if you've taken your slew rate into account and adjusted the maximum speed accordingly. > But, to stay within the I2C spec, you'll want at least 3ma of pullup > current. Wrong. > With a 4.7K ohm resistor and > 5v parts, you're talking about ~1ma, which isn't even close to being > in spec. Wrong again. > But the spec calls for a pullup current of between 3 and 12ma. Not any IIC spec I've seen. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

jim@jpes.com wrote: > No it isn't wrong. Read the spec. I have, and what you said is wrong and certainly bad advice. The spec even shows a graph of the minimum allowed pullup resistor versus supply voltage. The document I use from Phillips (the originators of IIC) is called "The IIC Bus and How to Use It". I have had it so long I don't remember exactly where on the Phillips site it came from, but I put a copy temporarily at http://www.embedinc.com/temp/iic.pdf. > For HS I2C comms, the min is 3ma > pullup current, and the max is 12ma pullup current. For *HS* mode, which is certainly not the default unless you explicitly say so. Using HS mode parameters with ordinary IIC devices (which the discussion was about and your statement referred to) is actually out of spec and can cause the bus not to work. Basically HS IIC is a different bus and requires different devices and electrical parameters to IIC. The general signalling method and the name are the same, but the electrical specs are incompatible. HS mode came much later. In fact, the addition of HS mode appears to be the main difference between the document I referenced above and yours. In any case, if you mean HS mode, you need to say so explicitly. Most devices out there are not HS mode compliant, and recommending up to 12mA without explaining this applies to HS mode only is wrong and will get people into trouble. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

Okay. Whatever. Regards, Jim {Quote hidden}> -------- Original Message -------- > Subject: Re: [PIC] I2C pullups? > From: "Olin Lathrop" <TakeThisOuTolin_piclistKILLspamspamembedinc.com> > Date: Fri, January 14, 2011 6:42 am > To: "Microcontroller discussion list - Public." <.....piclistRemoveMEmit.edu> > > > RemoveMEjimspamBeGonejpes.com wrote: > > No it isn't wrong. Read the spec. > > I have, and what you said is wrong and certainly bad advice. > > The spec even shows a graph of the minimum allowed pullup resistor versus > supply voltage. The document I use from Phillips (the originators of IIC) > is called "The IIC Bus and How to Use It". I have had it so long I don't > remember exactly where on the Phillips site it came from, but I put a copy > temporarily at http://www.embedinc.com/temp/iic.pdf. > > > For HS I2C comms, the min is 3ma > > pullup current, and the max is 12ma pullup current. > > For *HS* mode, which is certainly not the default unless you explicitly say > so. Using HS mode parameters with ordinary IIC devices (which the > discussion was about and your statement referred to) is actually out of spec > and can cause the bus not to work. Basically HS IIC is a different bus and > requires different devices and electrical parameters to IIC. The general > signalling method and the name are the same, but the electrical specs are > incompatible. > > HS mode came much later. In fact, the addition of HS mode appears to be the > main difference between the document I referenced above and yours. In any > case, if you mean HS mode, you need to say so explicitly. Most devices out > there are not HS mode compliant, and recommending up to 12mA without > explaining this applies to HS mode only is wrong and will get people into > trouble. > > > ******************************************************************** > Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products > (978) 742-9014. Gold level PIC consultants since 2000. > -

Okay. Whatever. But these are the specs I've come to know and use ocassionally. I have had no problems using the values I mentioned. I don't use them very often, but I when I do, these are the values I use. If they are wrong, then I guess they're wrong. But I have several projects out there that use these values, and they are still operating the same way they did when I first built them. And yes, they worked then as they were designed to. If you want to advise people to not use these values, then by all means go ahead. But I plan to keep on using these values in the future. I'm not going to change something when what I have works fine. It's one of those "if it ain't broke, don't fix it" sort of things for me. And if this seems to be bad engineering practice to you, then so be it. But it has proven to be fine to me, and that's what I'll go by. If in the future, something happens to change my mind, then I'll change. But until such a time comes, I'll go with what works. Regards, Jim > ---{Original Message removed}

jim@jpes.com wrote: > But these are the specs I've come to know and use > ocassionally. You mentioned different values. The pullup resistor values you said you used are actually in spec as they result in around 1mA required pulldown current. > I have had no problems using the values I mentioned. If you used the 1mA pullups, then you are in spec and it should work. Otherwise your test cases only failed to prove the design is bad, not prove that the design is good. > But I have several > projects out there that use these > values, and they are still operating the same way they did when I > first built them. Again, that's no proof of correctness, only proof of no blatant errors. A lot of IIC chips will successfully pull down with more than the minimum 3mA they are required to, so lower pullup resistors will likely work much of the time. However, that can change over temperature, from one manufacturing lot to another, after a die shrink, etc. > It's one of those "if it ain't broke, don't fix it" > sort of things for me. For you apparently. For others it is broken, just that the symptoms haven't manifested themselves yet. What you are doing (more than 3mA pulldown current required on a standard IIC bus) is bad design, plain and simple. Now you're just trying to save face by making it sound acceptable somehow. Unfortunately that may give some bystanders the impression it is OK. It's not. It's bad design. Don't do this folks. > And if this seems to be bad engineering practice to you, then so be > it. But it has proven to be fine to me, That is logically incorrect. You have only failed to prove it is bad. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

Spehro Pefhany wrote: > Here are some more actual specs: > > www.nxp.com/acrobat_download2/literature/9398/39340011.pdf > http://www.nxp.com/documents/user_manual/UM10204.pdf The second has a nice chart on page 36 that makes it quite clear. For both standard and fast mode 3mA current to ground must be able to bring a bus line to 400mV or less. In fast mode 6mA sink must also bring the bus to 600mV or less. Only in high speed mode (which that document calls "fast mode plus") is 20mA sink capability required, and in that case to the 400mV level. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

jim@jpes.com wrote: > Okay. But it works for me. That's what I'm saying here. Do what you want, but please stop making it sound somehow reasonable or a good practise to others. What you are doing is irresponsible and bad engineering. That's your business until you try to advise other to do it or leave the impression that it is acceptable. > And I'm not going to change just > because you say so. I'm not trying to convince you. If the datasheet can't, I have no chance. Besides I don't care what you do or think. I do care, however, when you advise others to follow your bad example. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

Sphero, thank you for that contribution. I did not know about that manual, specially second from NXP. I like it, is very well explained and, think, is easy to understand. Greetings. 2011/1/14 Spehro Pefhany <TakeThisOuTspeffspaminterlog.com> {Quote hidden}> At 10:31 AM 14/01/2011, you wrote: > > > Okay. Whatever. But these are the specs I've come to know and use > >ocassionally. > > <many words snipped> > > Here are some more actual specs: > > www.nxp.com/acrobat_download2/literature/9398/39340011.pdf > http://www.nxp.com/documents/user_manual/UM10204.pdf > > > > >Best regards, > > Spehro Pefhany --"it's the network..." "The Journey is the > reward" > speffEraseMEinterlog.com Info for manufacturers: > http://www.trexon.com > Embedded software/hardware/analog Info for designers: > http://www.speff.com >

Back. I did some checking, testing, etc, and reailzed I failed with my original question -- I do need SCL pullups, but the reason I did not have it in the 16F877A circuit was that I forgot that I had bit-banged that (~6 years ago) on two regular I/O pins. The SCL line went to logic high or low (never floating). On that, the SDA line had a 3.9k pullup, and I frankly don't remember how I calculated it. That controlled a single serial EEPROM at a very low speed. Ran a quick test using the actual MSSP module now, and used a very high 10Mohm pull-down (to verify whether I really needed a pullup up or not, by ensuring that if it floats, it would get pulled to ground), and it did not work. Adding a 3.9k the pullup solved it. The spec is great, and answers my question. Thanks. Cheers, -Neil. Quoting Vicent Colomar Prats <RemoveMEvicentecolomarEraseMEspam_OUTgmail.com>: {Quote hidden}> Sphero, thank you for that contribution. > > I did not know about that manual, specially second from NXP. I like it, is > very well explained and, think, is easy to understand. > > Greetings. > > > 2011/1/14 Spehro Pefhany <@spam@speffRemoveMEEraseMEinterlog.com> > >> At 10:31 AM 14/01/2011, you wrote: >> >> > Okay. Whatever. But these are the specs I've come to know and use >> >ocassionally. >> >> <many words snipped> >> >> Here are some more actual specs: >> >> www.nxp.com/acrobat_download2/literature/9398/39340011.pdf >> www.nxp.com/documents/user_manual/UM10204.pdf >> >> >> >> >Best regards, >> >> Spehro Pefhany --"it's the network..." "The Journey is the >> reward" >> EraseMEspeff@spam@interlog.com Info for manufacturers: >> http://www.trexon.com >> Embedded software/hardware/analog Info for designers: >> http://www.speff.com >> >> >

PICdude wrote: > The SCL line went to logic high or low (never floating). That's a bad idea in general. You can get away with it if you're not using multi-master and you're really sure none of the slave devices on the bus do clock stretching. You can still do it right easily enough with bit banging (in fact I usually do, due to so many problems with the MSSP in IIC mode), just bang the TRIS bit while keeping the port bit 0, and of course add a pullup. You can use a pin with a internal pullup if you slow the clock enough to compensate for the slow rise times. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000

Quoting Olin Lathrop <@spam@olin_piclistspam_OUT.....embedinc.com>: > PICdude wrote: >> The SCL line went to logic high or low (never floating). > > That's a bad idea in general. You can get away with it if you're not using > multi-master and you're really sure none of the slave devices on the bus do > clock stretching. Correct. > You can still do it right easily enough with bit banging (in fact I usually > do, due to so many problems with the MSSP in IIC mode), just bang the TRIS > bit while keeping the port bit 0, and of course add a pullup. You can use a > pin with a internal pullup if you slow the clock enough to compensate for > the slow rise times. That's what's I was doing on the SDA line, but had no need for it on the SCL line. Will be doing this for a newer use, where I'll be running I2C faster, and clock-stretching will be possible. Cheers, -Neil.