Optimal approach to store a word on a byte_wide EEPROM

I've written programs for which I've had to store byte variables into 24LCxxx type EEPROMS successfully. A piece of cake, as those EEPROMS are organized into bytes.

Now I've the need to do so but storing word variables.

I've read the endianess requirements, and feel that for a novice like me the little endian approach would be far easier to remember.

Therefore to sequentially write, a continuous string of words I would have to do the following (assuming I'm using W0):

main_save:
i2cslave %10100010, i2cslow, i2cword
writei2c address,(b0)
address = address + 1
writei2c address,(b1)
inc address

pause 20
readadc10 C.1, w0
goto main_save

Am I correct in my understanding?

Hi,

hippy may give a definitive answer, but as your title is "Optimal approach ...", I think a few improvements can be made.

Firstly, Manual 2 in the writei2c section says: "This command is deprecated, please consider using the hi2cout command instead". Note that in the hi2csetup command, the PICaxe declares itself as a master, to the slave EEPROM.

Secondly, more than one byte can be used as data and will probably reduce the number of page erase/write cycles. Interestingly, the PE doesn't reject using a word in the data field(s), but I suspect that only the low byte is transmitted. Therefore, I think the following is perhaps "more optimal", but not tested:

Cheers, Alan.

Don't you have to write a page at a time? I don't know the page size of your eeprom, but when I used a small eeprom for a project I had to write 16 bytes at a time, though I could read individual bytes. As I recall that was using SPI but I don't suppose that makes much difference. Worth checking. It is not the same as writing to the embedded PIC eeprom (presumably because Rev-Ed have hidden the page write code, though I didn't check the datasheet).

Hi,

No, I don't think so, but you must not cross a page boundary (hence the even address comment in my example).

However, if you were writing data every 20 ms for very long periods of time, it might be wise to write more bytes (perhaps using @bptr or @bptrinc variables) to increase the time before the EEPROM "wears out".

Cheers, Alan.

geoff07 said:

Don't you have to write a page at a time?

Click to expand...

No, you can write from 1 byte up to a page size at a time.

However as Allycat stated, the multibyte write cannot across a page boundary.
If you do try then the bytes that would “overflow” the page are written starting at byte 0 within the current page which will likely overwite earlier saved information.

the 24LCxxx series EEPROMs have a "Byte" write and a Page (multi-byte) write mode.

From the datasheet for Page Write mode - in this case for the 24LC256 EEPROM:

The write control byte, word address and the first data byte are transmitted to the 24XX256 in much the same
way as in a byte write. The exception is that instead of generating a Stop condition, the master transmits up to
63 additional bytes, which are temporarily stored in the on-chip page buffer, and will be written into memory
once the master has transmitted a Stop condition.

Click to expand...

and

If
a Page Write command attempts to write across a physical page boundary, the result is that the data wraps around to the
beginning of the current page (overwriting data previously stored there), instead of being written to the next page, as might be
expected. It is, therefore, necessary for the application software to prevent page write operations that would attempt to
cross a page boundary.

Click to expand...

finally again page size is from 24LC256 datasheet with 64 byte page size:

When doing a write of less than 64 bytes the data in the rest of the page is refreshed along with the data bytes being
written. This will force the entire page to endure a write cycle, for this reason endurance is specified per page.

Click to expand...

Thanks, Alan, that was precisely the info I was looking for!!!
Westy; good info about the page write. Although I won't be writing the EEPROM enough for premature wearout, I can see if I optimize my software to ensure that I write a full page (or at least half).