Blindsided!
It’s not often that I’m blindsided by some changes to avr-libc or AVR-GCC – I often trawl the respective project’s mailing lists and documentation looking for new neat features and additions to take advantage of. However, tonight I found something that made my monocle pop out, my tea spill, and my fist thump to the sound of a startled “good heavens!”. Looking over the EEPROM documentation to get the ordering of one of the functions, I noticed some new additions like the following:
void eeprom_update_byte (uint8_t * __p, uint8_t __value)
The documentation for these functions are, let’s just say, less than helpful:
22.13.3.7 void eeprom_update_byte (uint8_t * __p, uint8_t __value)
Update a byte __value to EEPROM address __p.
Which doesn’t explain much – what does it mean to “update” the EEPROM? Is it a split-write primative? Does it only write the changed bytes? Who knows?
Looking online for a bit I found that exactly zero people seemed to have noticed or used these new update functions, so I knuckled down, bit the bullet and went hunting through the avr-libc project source code. That led me to this file here responsible for the byte version of these mysterious EEPROM update functions. Looks like my second guess was on the money – it only writes changed bytes to EEPROM, skipping over those whose value matches the source bytes. Why is this important? EEPROM lifespan is measured in a number of writes (typically 100,000) and even if a value is written back unchanged, this still counts towards the total lifespan on the EEPROM cell.
For years I’ve been doing this sort of check-before-write manually in my source code, right up until last month in fact. I’m a bit embarrassed that I missed this change – the patch notes say it was applied a YEAR ago – along with the float EEPROM read/write functions that seem to have snuck in at the same time as well. Chalk that up as another personal failure of mine due to not being observant enough. Vigilance is key!
Time to update my EEPROM tutorial, I think.
