Post by thread:[EE] Serial EEPROM questions...

On 9/20/05, PicDude <spam_OUTpicdude2TakeThisOuTnarwani.org> wrote: > Hi all, > > About to write some code to interface a serial EEPROM with a PIC, but I'm > going thru the datasheet and can't get a clear answer on a couple things. > I'm planning on doing this manually (not using an I2C/MSSP module for this). > Hoping someone here might know. > > I'm using the datasheet for Microchip's 24C65 Smart serial EEPROM, since I > have one of there here. [ Sorry I can't attach a datasheet right now -- I'm > getting a timeout from Microchip's site when I click on the datasheet link. ] > > My questions... > (1) 2 modes are mentioned -- 100khz (Std.) and 400khz (Fast). Different > timings are specified for each mode. How are modes switched/selected? Usually a 400KHz I2C will work at 100KHz as well. So there is no selection need like in the hardware SSP PIC module. There are I2C devices running at 1MHz or 1.7MHz (maybe other frequencies too but I did't seen) but all works at 100KHz without any selection, only when switching to high speed they need a bit to be configured. cheers, Vasile {Quote hidden}> expect that it would need to be selected, since 2 different values are > specified for parameter "Taa" (Output valid from clock, max times=3500 and > 900ns). This tells me that the device will have it's output valid after a > maximum of so much time, and it's based on the mode. > > (2) What exactly does that Taa mean -- I interpret it to mean that after the > specified time, the EEPROM's return data will definitely be valid. But is > there a limit on this, or does the data stay on the line as long as there is > no additional changes to the SCL line? > > (3) Most parameters don't have a maximum time. Does this mean my code can > write some bits in the middle of a transaction, run off and do other things > and come back a minute later and pick up where it left off and all will be > hunky-dory? > > Cheers, > -Neil. > > > > -

PicDude writes about doing a software I2C master: ... > My questions... > (1) 2 modes are mentioned -- 100khz (Std.) and 400khz (Fast). Different > timings are specified for each mode. How are modes switched/selected? I > expect that it would need to be selected, since 2 different values are > specified for parameter "Taa" (Output valid from clock, max times=3500 and > 900ns). This tells me that the device will have it's output valid after a > maximum of so much time, and it's based on the mode. I'm responding without looking at the data sheet first, so take this for what it is worth. "Standard" and "Fast" are terms from the I2C spec. (The spec is worth reading. Phillips provides a PDF version on their website somewhere.) These are levels of performance for manufacturers of slave devices to advertise that their parts meet. An interface can be run "fast" only if there are no devices on the bus that are only guaranteed to meet the "standard" timing parameters. Part of the charm of I2C is that slaves are not required to do any timing (W.R.T. the bus), they are only required to be at least as fast as the numbers in the spec. So far as I know, devices don't have modes. They are available in versions, e.g.; 24LC512, 24AA512, 24FC512, some of which may not meet "fast" timing, and some of which do (all must meet or exceed "standard" timing or they're not officially I2C devices). Whether a particular version is guaranteed to meet "fast" timing may depend on supply voltage, or upon temperature, so if you're system Vcc is less than, for example, 2.5V, you may be forced to use "standard" timing. > > (2) What exactly does that Taa mean -- I interpret it to mean that after the > specified time, the EEPROM's return data will definitely be valid. But is > there a limit on this, or does the data stay on the line as long as there is > no additional changes to the SCL line? No limit. From the slave's point of view, the interface is static. It will make no further change on its own. SCL must change to move its state forward. > (3) Most parameters don't have a maximum time. Does this mean my code can > write some bits in the middle of a transaction, run off and do other things > and come back a minute later and pick up where it left off and all will be > hunky-dory? Yup. Parameters that are limits on the master generally only have minimums, except Fclk, which has a maximum, but that's really a minimum limit on clock period. The slave is responsible for being able to deal with things that are that fast. You can even look at TAA as a minimum for the master: the minimum time that it should wait before sampling the data (beginning of setup time of the master's input latch that will be clocked on rising SCL, if that's how you choose to do it - a software implementation should simply sample with SCL high and let clock low time requirements govern). The exception is Tr and Tf, which apply to both master and slave, and also the system design (bus wiring capacitance, pull up choice, driver capabilities). Note that for a single master system you can use totem pole drive for SCL. I hope this helps. Bill

On Tuesday 20 September 2005 07:58 am, Bill Freeman scribbled: > "Standard" and "Fast" are terms from the I2C spec. (The spec > is worth reading. Phillips provides a PDF version on their website Got it. Need to read it. {Quote hidden}> somewhere.) These are levels of performance for manufacturers of > slave devices to advertise that their parts meet. An interface can be > run "fast" only if there are no devices on the bus that are only > guaranteed to meet the "standard" timing parameters. Part of the > charm of I2C is that slaves are not required to do any timing > (W.R.T. the bus), they are only required to be at least as fast as the > numbers in the spec. > > So far as I know, devices don't have modes. They are > available in versions, e.g.; 24LC512, 24AA512, 24FC512, some of which > may not meet "fast" timing, and some of which do (all must meet or > exceed "standard" timing or they're not officially I2C devices). Okay, but some devices (looking at Digikey's search tool) are specified as "100khz", some as "400khz" and yet others as "100khz & 400khz". Seems odd as if it met the 400khz specs, it would automatically handle the 100khz timing. More odd is that the Taa parameter shows how fast the slave EEPROM will have its data ready during a read -- and that number is smaller for the fast mode. Seems like the device would have the data valid in maximum so many seconds, regardless of the mode, if there is no way to select/switch modes. Or are you saying that these numbers are from the spec as what the device is required to meet to be compliant in any mode, and it should just be accepted that it does? > Whether a particular version is guaranteed to meet "fast" timing may > depend on supply voltage, or upon temperature, so if you're system Vcc > is less than, for example, 2.5V, you may be forced to use "standard" > timing. Yep. There is also a note near the end of the datasheet about pull-up resistors -- smaller values for the fast mode, which is probably so it can achieve the required slew rate. > No limit. From the slave's point of view, the interface is > static. It will make no further change on its own. SCL must change > to move its state forward. Gotcha. Only possible exception to that is a small note near the end of the datasheet (section 7.3) that indicates that for power reduction, the eeprom will power down automatically after a transaction. It can also do this during error conditions or timeouts, so too long of a delay between changes on the lines may possibly be interpreted as a timeout. I'll check the spec to see for sure. > ... You can even look at TAA > as a minimum for the master: the minimum time that it should wait > before sampling the data (beginning of setup time of the master's > input latch that will be clocked on rising SCL, if that's how you > choose to do it - a software implementation should simply sample with > SCL high and let clock low time requirements govern). "clocked on rising SCL" ? Let me clarify this -- Master sends SDA HI (to free that line), then sends SCL HI, then back LO, then wait Taa, then the master reads the SDA line. ... right? > The exception is Tr and Tf, which apply to both master and > slave, and also the system design (bus wiring capacitance, pull up > choice, driver capabilities). Note that for a single master system > you can use totem pole drive for SCL. > > I hope this helps. > > Bill Definitely does. Thanks. Cheers, -Neil.

>From PicDude: > On Tuesday 20 September 2005 07:58 am, Bill Freeman scribbled: > > "Standard" and "Fast" are terms from the I2C spec. (The spec > > is worth reading. Phillips provides a PDF version on their website > > Got it. Need to read it. > So do I. ;-) > Okay, but some devices (looking at Digikey's search tool) are specified as > "100khz", some as "400khz" and yet others as "100khz & 400khz". Seems odd as > if it met the 400khz specs, it would automatically handle the 100khz timing. That's pretty much how I understand it to work. I don't know of any devices that need to be "configured" to operate at either speed. It's all in how fast you operate the clock. There are also duty cycle requirements on the clock as well. IOW, it wants a 50% duty cycle or a reasonable facsimile. > More odd is that the Taa parameter shows how fast the slave EEPROM will have > its data ready during a read -- and that number is smaller for the fast mode. > Seems like the device would have the data valid in maximum so many seconds, > regardless of the mode, if there is no way to select/switch modes. Or are > you saying that these numbers are from the spec as what the device is > required to meet to be compliant in any mode, and it should just be accepted > that it does? I think you are worrying too much about Taa. It's not important to you if you as long as you: 1) use a 50% duty cycle 2) don't violate setup and hold times Taa is an arbitrary delay that the chip may insert to keep other devices from being confused and misdetecting the operation as a Start or Stop condition. AIUI Taa only applies during the time the clock is low and it's always over by the time the clock is high again. You only read SDA when the clock is high anyway, so nothing to worry about. Here this should make it easier to get going: #define SCLPIN 0 #define SDAPIN 1 #define SCL INDF, SCLPIN ;On PORTA simulating open collector outputs #define SDA INDF, SDAPIN ; ditto ;------------------------------------------------------ ; ; EEPROM routines ; ;------------------------------------------------------ ; ; write_eeprom - Write the data in W to the currently selected slot (eedevice-2, eepointerH-8, eepointerL-8) ; write_eeprom movwf eevalue movlw TRISA ;so we can easily point to TRISA movwf FSR call I2C_Start clrc rlf eedevice, W ; shift the mess over one bit iorlw b'10100000' ; I2C /Write command to page x of eeprom call I2C_WriteByte call I2C_Ack movfw eepointerH ; Set address to slot number call I2C_WriteByte call I2C_Ack movfw eepointerL ; Set address to slot number call I2C_WriteByte call I2C_Ack movfw eevalue ; get data to write call I2C_WriteByte ; and write it call I2C_Ack call I2C_Stop Wait 10 Millisecs, 0 ; wait worst case time for now return ; ; read_eeprom - read currently selected location in W and eevalue ; read_eeprom movlw TRISA ;so we can easily point to TRISA movwf FSR ; To read the eeprom, we have to set the address by pretending to do a write. Once ; we set the address, we abort the write by doing a STOP instead of transferring a ; byte to be written. ; Set address by starting a write procedure and then aborting it call I2C_Start clrc rlf eedevice, W ; shift the mess over one bit iorlw b'10100000' ; I2C /Write command to page x of eeprom call I2C_WriteByte call I2C_Ack movfw eepointerH ; Set address to slot number call I2C_WriteByte call I2C_Ack movfw eepointerL ; Set address to slot number call I2C_WriteByte call I2C_Ack call I2C_Stop ; Abort the write after setting address pointer ; Now read from current address call I2C_Start clrc rlf eedevice, W ; shift the mess over one bit iorlw b'10100001' ; I2C Read command call I2C_WriteByte call I2C_Ack call I2C_ReadByte ; Read in a byte movwf eevalue ; and save it call I2C_SendNAck call I2C_Stop ; Done movfw eevalue return ;--------------------------------------------------- ; ; I2C Routines ; ;--------------------------------------------------- I2C_Start Wait 5 Microsecs, 0 ; Tsu:start bcf SDA ; bring data low Wait 4 Microsecs, 0 ; Thold:start bcf SCL ; followed by bring clock low return I2C_Stop bcf SDA ; make sure data is low Wait 1 Microsecs, 0 ; Tsu:data bsf SCL ; bring clock high Wait 4 Microsecs, 0 ; Tsu:stop bsf SDA ; then data high = STOP return I2C_Ack bsf SCL ; pull clock up Wait 5 Microsecs, 0 ; Thigh bcf SCL ; bring clock low again Wait 5 Microsecs, 0 ; Tlow return I2C_SendAck bcf SDA ; pull data low for ACK Wait 5 Microsecs, 0 ; Thigh bsf SCL ; pull clock up Wait 5 Microsecs, 0 ; Thigh bcf SCL ; bring clock low again Wait 5 Microsecs, 0 ; Tlow return I2C_SendNAck bsf SDA ; set data line high for NACK Wait 5 Microsecs, 0 ; Thigh bsf SCL ; pull clock up Wait 5 Microsecs, 0 ; Thigh bcf SCL ; bring clock low again Wait 5 Microsecs, 0 ; Tlow return I2C_WriteByte movwf i2ctemp movlw d'8' movwf count _i2cwritenextbit bcf SDA ; make low by default rlf i2ctemp, F ; get a bit into CARRY btfsc STATUS, C ; output the CARRY value bsf SDA Wait 5 Microsecs, 0 ; settle - Tsu bsf SCL ; bring clock high Wait 5 Microsecs, 0 ; settle - Thigh bcf SCL ; and bring it low to clock out the data Wait 5 Microsecs, 0 ; settle - Tlow decfsz count, F ; see if any more to do goto _i2cwritenextbit return I2C_ReadByte clrf i2ctemp movlw d'8' movwf count bsf SDA ; make SDA an input (release data line for slave to control) Wait 5 Microsecs, 0 ; give it time to float high _i2creadnextbit bsf SCL ; bring clock high Wait 5 Microsecs, 0 ; Thigh clrc ; assume low by default btfsc PORTA, SDAPIN ; check SDA setc rlf i2ctemp, F ; pull in the bit bcf SCL Wait 5 Microsecs, 0 ; let data settle decfsz count, F goto _i2creadnextbit movfw i2ctemp return Obviously these routines aren't optimized for speed. If I was worried about speed, I would have used the built in module. I just wanted to so if I could get it to work and hopefully learn something. > > Whether a particular version is guaranteed to meet "fast" timing may > > depend on supply voltage, or upon temperature, so if you're system Vcc > > is less than, for example, 2.5V, you may be forced to use "standard" > > timing. > > Yep. There is also a note near the end of the datasheet about pull-up > resistors -- smaller values for the fast mode, which is probably so it can > achieve the required slew rate. Yep, this little gem can really screw you up. My advice is to use stiff resistors (1K or so) until you get it all working then raise the values and take note as to how real reality is. ;-) I've been fairly lucky with my tinkerings using I2C and I haven't had problems with stuck buses and the like. Of course I haven't implemented anything I'd call real world with it either. > > No limit. From the slave's point of view, the interface is > > static. It will make no further change on its own. SCL must change > > to move its state forward. > > Gotcha. Only possible exception to that is a small note near the end of the > datasheet (section 7.3) that indicates that for power reduction, the eeprom > will power down automatically after a transaction. It can also do this > during error conditions or timeouts, so too long of a delay between changes > on the lines may possibly be interpreted as a timeout. I'll check the spec > to see for sure. Hmm, I'd expect it to not matter. It should just "power up" in the same state it went to sleep in. > > ... You can even look at TAA > > as a minimum for the master: the minimum time that it should wait > > before sampling the data (beginning of setup time of the master's > > input latch that will be clocked on rising SCL, if that's how you > > choose to do it - a software implementation should simply sample with > > SCL high and let clock low time requirements govern). > > "clocked on rising SCL" ? > Let me clarify this -- Master sends SDA HI (to free that line), then sends SCL > HI, then back LO, then wait Taa, then the master reads the SDA line. ... > right? No, you read SDA when the clock is high. You never have to wait Taa time AFAIK. Look at my code, it works. It's for large EEPROMS so it uses the longish addressing scheme. {Quote hidden}> > The exception is Tr and Tf, which apply to both master and > > slave, and also the system design (bus wiring capacitance, pull up > > choice, driver capabilities). Note that for a single master system > > you can use totem pole drive for SCL. > > > > I hope this helps. > > > > Bill > > Definitely does. Thanks. > > Cheers, > -Neil. > > > > > --

PicDude writes: > On Tuesday 20 September 2005 07:58 am, Bill Freeman scribbled: > Okay, but some devices (looking at Digikey's search tool) are specified as > "100khz", some as "400khz" and yet others as "100khz & 400khz". Seems odd as > if it met the 400khz specs, it would automatically handle the 100khz timing. Yea, well, I don't think that the copy writers at Digikey spend a lot of time understanding the datasheets. They probably just extract the title, or even a line item from a product brief. It would be nice if you could get competitive information summarized for you like that, but there's no substitute for research. I'd be very surprised to learn that any slave only fast rated device failed at standard speed. (There might be system level considerations for long buses in which fast mode capable drivers have too small a Tf and make the bus ring excessively, but hooking an EEPROM to the adjacent PIC isn't going to be a problem.) > More odd is that the Taa parameter shows how fast the slave EEPROM will have > its data ready during a read -- and that number is smaller for the fast mode. > Seems like the device would have the data valid in maximum so many seconds, > regardless of the mode, if there is no way to select/switch modes. Or are > you saying that these numbers are from the spec as what the device is > required to meet to be compliant in any mode, and it should just be accepted > that it does? Again, I think that if you look closely, the two (or more) values for Taa for a given part are ratings for different supply ranges. At low Vcc the gates are slower. (Never mind that at low Vcc you could actually build faster gates. They have sized the transistors to not fry at high Vcc, and they don't switch to others when Vcc changes.) Note, too, that Taa isn't the memory access time, it's a parameter of the serial interface. For example, acknowledging the command byte with the acknowledge bit at the end of the byte is done in Taa. The ROM itself accesses, at least partially (row select may already be done before the whole command and/or command and address info is clocked in) in the times that it takes to send the last acknowledge. Taa applies to the interface shift register plus the clock receiver plus the data driver. > Gotcha. Only possible exception to that is a small note near the end of the > datasheet (section 7.3) that indicates that for power reduction, the eeprom > will power down automatically after a transaction. It can also do this > during error conditions or timeouts, so too long of a delay between changes > on the lines may possibly be interpreted as a timeout. I'll check the spec > to see for sure. Still, the interface portion of the chip stays powered (CMOS static logic, really low power anyway), since it has to recognize the next command directed at it. Note that these are pretty slow speeds for modern PROMs (e.g.; flash), and I'll bet that the sum of the power up time and the ROM access time is well less than the acknowledge bit time. Taa is still just an serial interface parameter (which, since it stays powered up, is worth keeping low power and thus as slow as meeting the I2C spec over temperature and voltage allows). Oh, there's probably some scaling of the ROM to not be much faster than needed, but that first bit still has to make it out as fast as all of the others, and has to pass through the same final shift register flip flop (or MUX) and driver as subsequent ones, so I'll bet that the design has the read ready by the end of the acknowledge. Of course, the manufacturer can implement the chip any way that they like, so long as it meets the appropriate I2C spec. > "clocked on rising SCL" ? > Let me clarify this -- Master sends SDA HI (to free that line), then sends SCL > HI, then back LO, then wait Taa, then the master reads the SDA line. ... > right? Can do, I'm sure. I generally take the tact of reading SDL during the subsequent SCL high time, or, if doing it in hardware on the rising SCL edge of that clock high time. You have plenty of time. The slave is guaranteed to keep driving the same SDL value until it sees the falling SCL edge of that subsequent SCL high time. That way I can just obey the SCL low minimum, and read the data at my leisure while I delay to satisfy the SCL high minimum of that subsequent clock pulse. But if you absolutely need that bit at the earliest possible nanosecond... Remember, for normal bit transfers (the only time that slaves drive SDL), data is guaranteed to be stable while SCL is high. And your master implementation had better make the same guarantee for data (including acknowledge bits), except when you are sending start or stop (ore re-start) conditions, explicitly defined as SDL changes while SCL is high. Let me try one other description. If you are building an interface in hardware, you might use a D flip flop or latch clocked or latched on the rising edge of SCL to sample SDL. That device will have a minimum stable data to SCL high requirement. Adding Taa to that setup time will tell you if you have to stretch SCL low minimum. Conversely, subtracting Taa from SCL low minimum will tell you how slow a flip flop you can get away with, or whether you have to feed a delayed version of SCL to the flip flop, etc. Otherwise SCL low minimum governs, and you don't care about Taa (especially for the master, who doesn't have to lower SCL again until it has sampled SDL). Bill

Michael, Sorry for the late response, but been tough to get to my email since I'm dual-booting with this machine to get to another OS. Thanks for the code. I did write some code of my own a few days ago and comparing some of the differences. - I kept my timing/spacing at 6us for now. - I notice you don't actually check for the ACK. Why not? - Also, you've mentioned 50% duty-cycle requirement. I've been thru some of the I2C specification doc (v2.1), but didn't see anything w.r.t. a duty-cycle requirement. - BTW, your comments for the read_eeprom routine state that you use a STOP in the middle of the routine. It should actually be a START, which you are doing correctly. - I also created a routine to check if the bus is free (both lines HI). - I am planning to check for clock stretching. FWIW, I have not been able to get the EEPROM working yet with my code -- need to do some debugging, which would be much simplified, so I'm considering building a simple logic analyzer. Cheers, -Neil. On Tuesday 20 September 2005 04:25 pm, michael brown scribbled: {Quote hidden}> #define SCLPIN 0 > #define SDAPIN 1 > #define SCL INDF, SCLPIN ;On PORTA simulating open > collector outputs > #define SDA INDF, SDAPIN ; ditto > > ;------------------------------------------------------ > ; > ; EEPROM routines > ; > ;------------------------------------------------------ > > ; > ; write_eeprom - Write the data in W to the currently selected slot > (eedevice-2, eepointerH-8, eepointerL-8) > ; > > write_eeprom > > movwf eevalue > movlw TRISA ;so we can easily point to > TRISA > movwf FSR > > call I2C_Start > > clrc > rlf eedevice, W ; shift the mess over one > bit > iorlw b'10100000' ; I2C /Write command to > page x of eeprom > call I2C_WriteByte > call I2C_Ack > > movfw eepointerH ; Set address to slot > number > call I2C_WriteByte > call I2C_Ack > > movfw eepointerL ; Set address to slot > number > call I2C_WriteByte > call I2C_Ack > > movfw eevalue ; get data to write > call I2C_WriteByte ; and write it > call I2C_Ack > > call I2C_Stop > > Wait 10 Millisecs, 0 ; wait worst case time > for now > > return > ; > ; read_eeprom - read currently selected location in W and eevalue > ; > > read_eeprom > > movlw TRISA ;so we can easily point to > TRISA > movwf FSR > > ; To read the eeprom, we have to set the address by pretending to do a > write. Once > ; we set the address, we abort the write by doing a STOP instead of > transferring a > ; byte to be written. > > ; Set address by starting a write procedure and then aborting it > > call I2C_Start > > clrc > rlf eedevice, W ; shift the mess over one > bit > iorlw b'10100000' ; I2C /Write command to > page x of eeprom > call I2C_WriteByte > call I2C_Ack > > movfw eepointerH ; Set address to slot > number > call I2C_WriteByte > call I2C_Ack > > movfw eepointerL ; Set address to slot > number > call I2C_WriteByte > call I2C_Ack > > call I2C_Stop ; Abort the write after > setting address pointer > > ; Now read from current address > > call I2C_Start > > clrc > rlf eedevice, W ; shift the mess over one > bit > iorlw b'10100001' ; I2C Read command > call I2C_WriteByte > call I2C_Ack > > call I2C_ReadByte ; Read in a byte > movwf eevalue ; and save it > > call I2C_SendNAck > > call I2C_Stop ; Done > > movfw eevalue > > return > > > > ;--------------------------------------------------- > ; > ; I2C Routines > ; > ;--------------------------------------------------- > > I2C_Start > Wait 5 Microsecs, 0 ; Tsu:start > bcf SDA ; bring data low > Wait 4 Microsecs, 0 ; Thold:start > bcf SCL ; followed by bring clock > low > return > I2C_Stop > bcf SDA ; make sure data is low > Wait 1 Microsecs, 0 ; Tsu:data > bsf SCL ; bring clock high > Wait 4 Microsecs, 0 ; Tsu:stop > bsf SDA ; then data high = STOP > return > I2C_Ack > bsf SCL ; pull clock up > Wait 5 Microsecs, 0 ; Thigh > bcf SCL ; bring clock low again > Wait 5 Microsecs, 0 ; Tlow > return > > I2C_SendAck > bcf SDA ; pull data low for ACK > Wait 5 Microsecs, 0 ; Thigh > bsf SCL ; pull clock up > Wait 5 Microsecs, 0 ; Thigh > bcf SCL ; bring clock low again > Wait 5 Microsecs, 0 ; Tlow > return > > I2C_SendNAck > bsf SDA ; set data line high for > NACK > Wait 5 Microsecs, 0 ; Thigh > bsf SCL ; pull clock up > Wait 5 Microsecs, 0 ; Thigh > bcf SCL ; bring clock low again > Wait 5 Microsecs, 0 ; Tlow > return > > I2C_WriteByte > movwf i2ctemp > movlw d'8' > movwf count > > _i2cwritenextbit > bcf SDA ; make low by default > rlf i2ctemp, F ; get a bit into CARRY > btfsc STATUS, C ; output the CARRY value > bsf SDA > Wait 5 Microsecs, 0 ; settle - Tsu > > bsf SCL ; bring clock high > Wait 5 Microsecs, 0 ; settle - Thigh > > bcf SCL ; and bring it low to > clock out the data > Wait 5 Microsecs, 0 ; settle - Tlow > > decfsz count, F ; see if any more to do > goto _i2cwritenextbit > return > > I2C_ReadByte > clrf i2ctemp > movlw d'8' > movwf count > > bsf SDA ; make SDA an input > (release data line for slave to control) > Wait 5 Microsecs, 0 ; give it time to float > high > > _i2creadnextbit > bsf SCL ; bring clock high > Wait 5 Microsecs, 0 ; Thigh > > clrc ; assume low by default > btfsc PORTA, SDAPIN ; check SDA > setc > rlf i2ctemp, F ; pull in the bit > > bcf SCL > Wait 5 Microsecs, 0 ; let data settle > > decfsz count, F > goto _i2creadnextbit > movfw i2ctemp > return > > > Obviously these routines aren't optimized for speed. If I was worried > about speed, I would have used the built in module. I just wanted to so > if I could get it to work and hopefully learn something. > > > > Whether a particular version is guaranteed to meet "fast" timing may > > > depend on supply voltage, or upon temperature, so if you're system > > Vcc > > > > is less than, for example, 2.5V, you may be forced to use "standard" > > > timing. > > > > Yep. There is also a note near the end of the datasheet about pull-up > > resistors -- smaller values for the fast mode, which is probably so it > > can > > > achieve the required slew rate. > > Yep, this little gem can really screw you up. My advice is to use stiff > resistors (1K or so) until you get it all working then raise the values > and take note as to how real reality is. ;-) > > I've been fairly lucky with my tinkerings using I2C and I haven't had > problems with stuck buses and the like. Of course I haven't implemented > anything I'd call real world with it either. > > > > No limit. From the slave's point of view, the interface is > > > static. It will make no further change on its own. SCL must change > > > to move its state forward. > > > > Gotcha. Only possible exception to that is a small note near the end > > of the > > > datasheet (section 7.3) that indicates that for power reduction, the > > eeprom > > > will power down automatically after a transaction. It can also do > > this > > > during error conditions or timeouts, so too long of a delay between > > changes > > > on the lines may possibly be interpreted as a timeout. I'll check the > > spec > > > to see for sure. > > Hmm, I'd expect it to not matter. It should just "power up" in the same > state it went to sleep in. > > > > ... You can even look at TAA > > > as a minimum for the master: the minimum time that it should wait > > > before sampling the data (beginning of setup time of the master's > > > input latch that will be clocked on rising SCL, if that's how you > > > choose to do it - a software implementation should simply sample > > with > > > > SCL high and let clock low time requirements govern). > > > > "clocked on rising SCL" ? > > Let me clarify this -- Master sends SDA HI (to free that line), then > > sends SCL > > > HI, then back LO, then wait Taa, then the master reads the SDA line. > > ... > > > right? > > No, you read SDA when the clock is high. You never have to wait Taa > time AFAIK. Look at my code, it works. It's for large EEPROMS so it > uses the longish addressing scheme. > > > > The exception is Tr and Tf, which apply to both master and > > > slave, and also the system design (bus wiring capacitance, pull up > > > choice, driver capabilities). Note that for a single master system > > > you can use totem pole drive for SCL. > > > > > > I hope this helps. > > > > > > Bill > > > > Definitely does. Thanks. > > > > Cheers, > > -Neil. > > > > > > > > > > --

----- Original Message ----- From: "PicDude" <.....picdude2KILLspam.....narwani.org> To: "Microcontroller discussion list - Public." <EraseMEpiclistspam_OUTTakeThisOuTmit.edu> Sent: Saturday, September 24, 2005 10:59 AM Subject: Re: [EE] Serial EEPROM questions... > Michael, > > Sorry for the late response, but been tough to get to my email since I'm > dual-booting with this machine to get to another OS. > > Thanks for the code. I did write some code of my own a few days ago and > comparing some of the differences. > - I kept my timing/spacing at 6us for now. > - I notice you don't actually check for the ACK. Why not? I didn't care to as it was just for experimentation. The code isn't intended to be a perfect implementation, just something that worked. > - Also, you've mentioned 50% duty-cycle requirement. I've been thru some of > the I2C specification doc (v2.1), but didn't see anything w.r.t. a duty-cycle > requirement. It's not that there is a 50% requirement, it's just that there are minimum clock high and low times. It's kinda between the lines that it becomes a 50% requirement when operating at or near max speed. > - BTW, your comments for the read_eeprom routine state that you use a STOP in > the middle of the routine. It should actually be a START, which you are > doing correctly. Ok, I'll fix my comments then. :-) > - I also created a routine to check if the bus is free (both lines HI). That's sounds like the right way to do it for a real world project. > - I am planning to check for clock stretching. Same as above. > FWIW, I have not been able to get the EEPROM working yet with my code -- need > to do some debugging, which would be much simplified, so I'm considering > building a simple logic analyzer. That's why I mentioned using the stiff pull-ups. Do everything you can to be sure that when it doesn't work that it's a logic problem and not an actual electrical one (slow rise times or whatever). I wish I had a logic analyzer or even a DSO would be really nice. I got mine working with a couple of serial EEPROMs and a Dallas RTC on the same bus built up on a solderless breadboard. I had some trouble with rise times, but I'd already experienced odd behavior of a shift register when the rise time was too slow. It wasn't like I immediately recognized the symptoms (cause they were different), but previous experience had left me with one more thing to try.

Well, I got my code working properly now. Your NACK routine helped me figure it out. Thanks again. I wrote page-write code for specific Mchip and Atmel Serial EEPROM's which both work properly with 4.7k pullups (@ ~100khz), though I expect in an actual project, I'll use some smaller values. Absolutely agree about the logic analyzer -- I would've given yet another arm and leg for one while debugging, but I ended up using a very very primitive logic analyzer -- I changed the oscillator to external RC osc and slowed it down to about 20 hz (yep -- Hz, not khz). Add a couple buffered LED's to the SDA and SCL lines, a pencil and paper in hand, and I got a true logic analyzer plot! :-) BTW, I found out that MPLAB SIM has a logic analyzer plot, but it's not very effective when trying to measure what's happening on a line that gets pulled-up/down by various external components, and temporarily changing the code to high or low outputs can only indicate so much without changing the timing. Rather than getting a large desktop analyzer off ebay or so, I came up with an idea to build a simple logic analyzer, but haven't had the time to implement it yet -- that'll be another discussion later. Need to spend some time implementing the Serial EE code into an application first. Cheers, -Neil. On Monday 26 September 2005 09:28 am, michael brown scribbled: {Quote hidden}> ... > ... > ... > That's why I mentioned using the stiff pull-ups. Do everything you can > to be sure that when it doesn't work that it's a logic problem and not > an actual electrical one (slow rise times or whatever). I wish I had a > logic analyzer or even a DSO would be really nice. I got mine working > with a couple of serial EEPROMs and a Dallas RTC on the same bus built > up on a solderless breadboard. I had some trouble with rise times, but > I'd already experienced odd behavior of a shift register when the rise > time was too slow. It wasn't like I immediately recognized the symptoms > (cause they were different), but previous experience had left me with > one more thing to try.

From: "PicDude" > Well, I got my code working properly now. Your NACK routine helped me figure > it out. Thanks again. I wrote page-write code for specific Mchip and Atmel Is there much of difference between them? I haven't played with this stuff since early this spring so I'm a bit rusty on the details. > Serial EEPROM's which both work properly with 4.7k pullups (@ ~100khz), What clock speed are you using for the PIC? > though I expect in an actual project, I'll use some smaller values. > > Absolutely agree about the logic analyzer -- I would've given yet another arm > and leg for one while debugging, but I ended up using a very very primitive > logic analyzer -- I changed the oscillator to external RC osc and slowed it > down to about 20 hz (yep -- Hz, not khz). Add a couple buffered LED's to the > SDA and SCL lines, a pencil and paper in hand, and I got a true logic > analyzer plot! :-) Yep, the no minimum clock speed thingy is nice sometimes. When I was a lad, I clocked my COSMAC ELF (1802 processor) with a 555 timer circuit. With an LED to "see" the clock signal, I verified that a machine cycle really did take exactly 8 clock cycles. And it did every time, exactly! ;-) > BTW, I found out that MPLAB SIM has a logic analyzer plot, but it's not very > effective when trying to measure what's happening on a line that gets > pulled-up/down by various external components, and temporarily changing the > code to high or low outputs can only indicate so much without changing the > timing. I have to admit that I really don't use the simulator. It's just another big bunch of quirks to keep track of, so I don't bother. There's a simulator for Linux and I hear it's pretty good, but I don't personally know. I typically use an LCD display on my projects for debugging. Serial comms is also handy, but the most useful debugging aid is probably an LED. Well, after the scope anyway. > Rather than getting a large desktop analyzer off ebay or so, I came up with an > idea to build a simple logic analyzer, but haven't had the time to implement > it yet -- that'll be another discussion later. Need to spend some time > implementing the Serial EE code into an application first.

On Wednesday 28 September 2005 05:59 am, michael brown scribbled: > .... I wrote page-write code for specific Mchip and Atmel > > Is there much of difference between them? I haven't played with this > stuff since early this spring so I'm a bit rusty on the details. Actually I'll take that back -- after more research, it appears the differences were more about 16k vs 32k, rather than about the vendor. Atmel's 16k seems to be the same as Mchip's 16k, etc for the few devices I checked. > > Serial EEPROM's which both work properly with 4.7k pullups (@ > ~100khz), > > What clock speed are you using for the PIC? 20Mhz. > Yep, the no minimum clock speed thingy is nice sometimes. When I was a > lad, I clocked my COSMAC ELF (1802 processor) with a 555 timer circuit. > With an LED to "see" the clock signal, I verified that a machine cycle > really did take exactly 8 clock cycles. And it did every time, exactly! > ;-) Wow -- serious disbeliever, huh? > I have to admit that I really don't use the simulator. It's just > another big bunch of quirks to keep track of, so I don't bother. Agreed, and it's considerable setup (relative to the ease of all else), but at times it can be useful, and after a week of ripping my remaining hairs out, I welcome the simulator. > There's a simulator for Linux and I hear it's pretty good, but I don't > personally know. I typically use an LCD display on my projects for > debugging. Serial comms is also handy, but the most useful debugging > aid is probably an LED. Well, after the scope anyway. You probably mean gpsim. Although I use Linux 99% for my PIC development (with gpasm), I haven't tried the sim since I'm doing this under a non-GUI environment. Cheers, -Neil.