Questions about Basic_I2C_Driver

william chan

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

stevenmess2004

Not sure about any of these. Have you had a look at this object? http://forums.parallax.com/showthread.php?p=617192

carbon

Hi William,

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)

deSilva

... and wrt 4.) This is a nonsense question

william chan

Hi Carbon,

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

LoopyByteloose

Since it is the 'boot' address, I believe the EEPROM defaults to one and only one address, possibly the $A0. I'd have to dig to verify value. Writing to other address possiblities will be ignored by that particular chip.

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?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

william chan

Kramer,

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

Mike Green

From the comments at the beginning of the I/O driver:

'' To read from or write to an EEPROM on pins 28/29 like the boot EEPROM:

'' CON
''   eepromAddress = $7000

'' VAR
''   byte buffer[noparse][[/noparse]32]

'' OBJ
''   i2c : "Basic_I2C_Driver"

'' PRI readIt
''   if i2c.ReadPage(i2c#BootPin, i2c#EEPROM, eepromAddress, @buffer, 32)
''     abort ' an error occurred during the read

'' PRI writeIt | startTime
''   if i2c.WritePage(i2c#BootPin, i2c#EEPROM, eepromAddress, @buffer, 32)
''     abort ' an error occured during the write
''   startTime := cnt ' prepare to check for a timeout
''   repeat while i2c.WriteWait(i2c#BootPin, i2c#EEPROM, eepromAddress)
''     if cnt - startTime > clkfreq / 10
''       abort ' waited more than a 1/10 second for the write to finish

"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.

Ron Sutcliffe

@Mike
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

william chan

Thanks mike.
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

Mike Green

The "i2c#" notation is used for cross object constant references. Just like "i2c.readbyte" refers to the "readbyte" method in the object declared as "i2c", "i2c#BootPin" refers to the "BootPin" constant in the object declared as "i2c".

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).

william chan

Thanks Mike and everyone else, it is working now !.

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

LoopyByteloose

BTW, even some new EEPROMs need mutiple re-writes to get operational. I have a very nice little board that I had to cycle numerous times [noparse][[/noparse]like 15X] to reload the EEPROM with good results.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:

Do you want a quickly operational black box solution or the knowledge included therein?······

···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

tekochip

Kramer;

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.

Mike Green

1) WriteByte, etc. return true if there's a failure mostly because a failure is not expected and typically you'd have "IF writeByte, ABORT" or some such.

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).