View previous topic :: View next topic |
Author |
Message |
theasus
Joined: 31 May 2009 Posts: 79
|
an EEPROM question |
Posted: Mon Jan 18, 2010 1:29 pm |
|
|
I will use eeprom 24c08. I don't have any problem read or write operation. I will record some date to eeprom when my operation has completed. And I don't want to lose any data. When I energized the circuit, it will start from 0.address to record. The data will be recorded to 0.address. After that when I energized the circuit it will lose the last address that I have recorded and it will start to record 0.address again. But I want to write this data to 1.address. How can I solve this problem?
Thanks... |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Jan 18, 2010 2:12 pm |
|
|
You could use 2 eeprom bytes to save the "next free address".
These 2 bytes could be initialized with a #rom statement in
your program, so they point to the first free address.
When the PIC is programmed by the ICD, the "next free address"
bytes would be set to the initial value. After that, when your
program runs, it would update the "next free address" every
time it writes new data to the eeprom.
You could also include an extra checksum byte for the "next free address"
bytes. Then you would also have to invent a strategy of what to do
if the checksum on the pointer bytes is incorrect. |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Thu Jan 21, 2010 6:03 pm |
|
|
I already do what pcm programmer suggests
for up to 65532 bytes eeprom.
Address 0,1 holds an unsigned int16 pointer to the next offset to write data to.
Address 2,3 holds a checksum which is 0xC5C5 added to the pointer.
Address 4 is the first useable byte
I don't even bother to pre init the eeprom - instead when the address pointer value is read from eeprom - if the checksum fails - then the address variable (unsigned int16) is set to 4 - ie -the initialized state ready for first use. I have never had a report of this approach failing - even tho there is a 1 in 65536 chance that it can.
Further this method is very amenable for writing strings and other RLL type data too. |
|
![](templates/subSilver/images/spacer.gif) |
|