Questions about Basic_I2C_Driver
![william chan](https://forums.parallax.com/uploads/userpics/RBTCEMRWP85K/nQFR9OII9OM33.jpg)
Hi,
I am having difficulties reading and writing to the EEPROM that comes with PropRPM
1. Is the constant "EEPROM device address" always should be EEPROM = $A0?
2. In the method ReadByte(SCL, devSel, addrReg), what should be the value of devSel? Zero?
3. If I want to write to the last byte on the eeprom, should I set addrReg to $7FFF?
4. What happens when we ReadLong or WriteLong and it hits a page boundary?
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
I am having difficulties reading and writing to the EEPROM that comes with PropRPM
1. Is the constant "EEPROM device address" always should be EEPROM = $A0?
2. In the method ReadByte(SCL, devSel, addrReg), what should be the value of devSel? Zero?
3. If I want to write to the last byte on the eeprom, should I set addrReg to $7FFF?
4. What happens when we ReadLong or WriteLong and it hits a page boundary?
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
Comments
the used EEPROM is this here:
http://ww1.microchip.com/downloads/en/DeviceDoc/21203P.pdf
In the Datasheet you will find all the information.
1.) The EEPROM device Adress is selected by the pins A0-A2, in the scematic (here: http://elmicro.com/files/manuals/proprpmv10_schema.pdf) are this pins
connected to GND -> the device Adress is on the PropRPM always $A0
2.) look into the Example
3.) The EEPROM has 32K*8 (Datasheet)
Where is the example?
DeSilva,
If I remember correctly, EEPROM PageWrite and PageRead can only read about 32 bytes of the same page at one time, it cannot cross page boundaries.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
Have you considered the possiblity that the EEPROM has prematurely worn out or defective? They do have a limited number of cycles of R/W.
I presume that the Propeller IDE does a checksum or CRC of the EEPROM after a write cycle that would indicate status. Is there a failure message? Just one bad byte and the chip is no good. It would be easier to swap it out to verify than to try to first run down a software bug that may not be there.
Even a bent address pin on the EEPROM dip would give you a failure.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
I tried WriteLong and ReadLong, both returned success but what I read back wasn't what I wrote in.
Then I tried WriteByte and ReadByte, both also returned sucess, but same problem.
I am sure the eeprom is not exhausted, the board is very new.
I still don't understand what should be the value of the second parameter.
The comments on the object source file is not clear enough.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
"eepromAddress" should be the address in the EEPROM that you want to use. If you want to write to the last location in a 32K EEPROM, it should be $7FFF.
The "devSel" parameter normally is indeed $A0 which is the normal device select code for EEPROMs. Bits 3-1 can contain a select code which may be determined by pins on the EEPROM chip. The routines use part of "eepromAddress" to construct the device select code since that's also used for addressing in EEPROMs larger than 64K bytes.
When you use WriteLong to write across a page boundary, it writes some of the bytes in the "wrong place" wrapping around to the beginning of the page as described in the datasheets for the EEPROMs. Don't use WriteWord or WriteLong across a page boundary. ReadWord and ReadLong will work across a page boundary, but not across a chip boundary.
You have to supply a write delay as shown in the example. It can take up to 5ms for the EEPROM to complete a write cycle and it won't respond to reads or writes until that's done.
If you wire the EEPROM properly or use the existing Propeller program EEPROM, these routines will work as described. If you're having difficulty, you'll have to post your code and a description of your setup.
Maybe thats is what William wanted to do.
Questions are not always what they seem to be here.
Mind you, that applies to the replies too.
Ron
That is roughly what I needed.
I assume that your i2c#bootpin's value is 28.
But what is the value of i2c#eeprom that you use?
Why is there a "#" in this variable?
Thanks again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
I believe "BootPin" is defined as 28 (the clock line for the boot EEPROM) and "EEPROM" is defined as $A0 (the device select value for most EEPROMs).
I am now able to save and retrieve back the same data.
Meanwhile....
1. Why does WriteByte and WriteLong return False when successful? Isn't that opposite of convention?
2. If I use an address of a variable to save into the eeprom (using @varname ), isn't it dangerous because it may hit a page boundary?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
I have not seen a problem with multiple rewrites,·but EEPROMs do require 10mS or more to complete a write cycle.· This time varies from part to part, so check the spec. sheet.· What you'll want to do is perform acknowledge polling, this is where you perform the write, and then attempt to read the data back.· The chip will not acknowledge the request while it is busy completing the write cycle, so by repeating the request you'll know when the write is complete.
2) Yes, if you're saving a variable value to EEPROM to be restored on restarting, you might have a problem with page boundaries. That's an uncommon usage and I didn't want to burden these routines with the additional overhead to sort all that out (and page sizes vary depending on the EEPROM model). They are "basic" routines. You can easily write your own wrapper that checks for an address that would cross the smallest likely page boundary (64 bytes) and splits the write operation into two parts as needed. The alternative is to store your data in the last few locations of the EEPROM and your initialization routine reads the values in.
3) Kramer, the example in the comments in these routines shows how to do acknowledge polling (WriteIt).