Library usage of EEPROM

Projects General Guidance
1

I've volunteered to add some TFT touch screen calibration persistence into a driver library (storing and reading calibration data to EEPROM) and I wanted to ask the more experienced people here what the best way is to do it. I've googled and checked the style guide and have found nothing relevant.

The calibration data takes about 32 bytes of data and my demo stores it starting at 0x0000. I probably don't want to store it there by default. Should I:

  • Pick a random location that this library will always use and always read from there and automatically load calibration data upon instantiation?
  • Have the user call a readCalibrationData function with the address as an argument?
  • Other suggestions?

As a developer, I'd probably prefer the second one, but I'd like some advice.

Thanks

2

ClintonKeith:
I've volunteered to add some TFT touch screen calibration persistence into a driver library (storing and reading calibration data to EEPROM) and I wanted to ask the more experienced people here what the best way is to do it. I've googled and checked the style guide and have found nothing relevant.

The calibration data takes about 32 bytes of data and my demo stores it starting at 0x0000. I probably don't want to store it there by default. Should I:

  • Pick a random location that this library will always use and always read from there and automatically load calibration data upon instantiation?
  • Have the user call a readCalibrationData function with the address as an argument?
  • Other suggestions?

As a developer, I'd probably prefer the second one, but I'd like some advice.

Thanks

I don't think it matters WHERE you put the calibration data in EEPROM. If you feel funny about plugging up the first 32 bytes, why not use the last 32 instead?

How I would do it is to have a "setCalData()" and "getCalData()" function that takes the EEPROM address (as well as anything else you may need) as arguments.

That way, you can just do a "#define cal_data 0xf0" or whatever and then use it in your code.

To change it, you only edit the one define, and it's "self documenting" (it makes sense what it does).

Lastly, I'm sure you know that EEPROM has a limited write life. You can READ it all you want, but don't STORE to it unless you have to. An occasional re-calibrate and storage of new data is OK, but if it happens at each startup, you will quickly wear out your EEPROM cells. OF course as I said, READING back cal data on startup is unlimited and OK.

Hope this helps.

3

That's great advice. Agree on the interface.

I "feel funny" about hardcoding any shared resource usage in a library, in general, because it increases the likelihood of collisions. I've seen this a number of times with libraries that assume to use the default hardware serial port for anything, especially without consideration of the platform, etc.

Hadn't heard about the limited write life of EEPROM. Looking it up, I see we're limited to "100,000 EEPROM writes over 20 years". I guess I won't be putting EEPROM writes in my core loops! :wink:

Thanks!