Good night, my friend. You really have the Flash of Genious!!! Thanx.
@Coding Badly
Thanx.
So, would I better be sending my data to the host and store it there??? That's what I'm doing now.
Buenas noches, Nick!
What the heck are you doing there, Nick? What time is it in the outback?, C'mon amigo, go to rest. You've helped us! Go to sleep and please ... be here for us!
You will always be my friend.
You might want to have a look at this experiment: Wear Leveling | Blinkenlight.
You might want to have a look at this experiment: Wear Leveling | Blinkenlight.
Interesting idea, thank you. 8)
@James C4S
Program code (outside of the bootloader partition) can't save to PROGMEM.
You are right, I had completely forgotten that 
, since I've never used PROGMEM at all. I had only read about it.
And it makes sense since PROGMEM is only updated when uploading the sketch. Or is it also updated at reset/power-up time?
Not good for run time variable data but for constant data. It is clear to me now.
Thank you, James! 
I just thought up another way, it would take a bit more coding but...
1st byte contains (0.255), you boot up, read the first byte (byte 1) of eeprom, this value represents how many times you've used that 4 bytes of memory (writing) everytime you do a write say bytes 2,3,4,5, read... Byte 1 becomes 2, etc etc.
When Byte 1 reaches 255;, leave the first 5 bytes of memory alone (so you read byte 1, is it at 255? if so, Seek 5 bytes into the EEPROM, this time, you you read it, 0 and the counter begins again, and start again, if the the next write value says 255, then read further until you find 0 . sequentially reading every 5 bytes of eeprom to find the starting memory address in which to safely write the new data.., the beauty of this is, when you've used 100 (X amount of segments eg divide 5 bytes into total eeprom memory) you can wipe every byte counter back to 0 and start again giving a nice even wear of memory to the eeprom, ie not maxing out it's life cycle for individual bytes leaving an average life left for device, even after using it for 3 years you could then sell it on knowing full well it's going to keep working for some time to come....
the first time the program runs you could format the memory, 1,5,10,15...... to the end of eeprom gets set to 0.
eeprom[1]=1;
write 2,3,4,5
eeprom[1]=2;///
if (eeprom[1]=255)
{
baseaddress=baseaddress+5;
}
int returnbaseaddress();
{
scan through each 5 bytes reading memory...
etc etc
}
That's pretty much what I was suggesting, except to use 2 bytes. The EEPROM can stand more than 255 writes.
255 is to keep it even... so you end up using all of the EEPROM memory then you reset it all back to 0 and start again..
so for example, you don't use bytes 1,2,3,4,5 10,0000 times rendering the memory almost dead and have the rest of memory in near perfect condition, you'd not be able to sell it.
doing a 255 cycle on it means you even it out so selling it on you'd not have to worry about wearing just a few bytes of memory out.
bibre:
And it makes sense since PROGMEM is only updated when uploading the sketch. Or is it also updated at reset/power-up time?
its only updated when you upload
Thank you, Osgeld.
Regards.
bibre:
So, would I better be sending my data to the host and store it there??? That's what I'm doing now.
Given what you said earlier...
Well, ideally every time I change the position of a turnout (switch or point in the UK) in my model railroad. I do not change the turnouts very often anyway.
I would use the EEPROM. One very effective thing you could do is compare the new value to the EEPROM value and only write to the EEPROM if the values are different.
Note: Nick, Udo, and cjdelphi are describing "EEPROM wear leveling" in case you'd like to search for potential algorithms. Atmel has a nice description here... http://www.atmel.com/Images/doc2526.pdf
Thanx, Coding Badly !
I'll study that .pdf in detail. Looks very interesting.
I just reviewed the Atmel Application Note, the flow diagrams are very clear. Thank you!