-
Notifications
You must be signed in to change notification settings - Fork 17
Reduce the number of EEPROM writes with a 'Save Settings' command or EEPROM.update #16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I wasn't aware that EEPROM.update() existed! That's neat. I disagree with your premise however. The number or EEPROM.writes is pretty limited to configuration changes. If the user issues the command to change UART speed, yes, we write to EEPROM and perhaps we could have saved a EEPROM write cycle using .update but I don't see us approaching the 100k datasheet limit or the 16M field limit of EEPROM ware. Don't get me wrong, I'll write better code next time, but I don't see this as an issue. There quite a few bounds checking writes like this one:
But these .writes will rarely get called (initial boot and rare edge cases). Is there a .write that you see as particularly bad? |
Just to put it in context for how I use it, I am connecting to a SerLCD module via UART. At reset, because I can't read what the current settings are I configure the SerLCD module as if it was the first time, which includes contrast, backlight, etc. The EEPROM.update change would largely get rid of this problem, but another firmware solution at least in my use case would be to read the current settings. I had considered just recording the last settings in my own EEPROM, but we have built 20 of these devices (8-channel audio recorders with LCD UI) and some of them have already had their LCD modules swapped out, which my firmware wouldn't have been aware of. Hope this clears up the intent at least. There may be a better way to do what I'm doing that I haven't come up with. It's certainly not a high-priority issue but considering it's most likely just a search/replace of EEPROM.write to EEPROM.update it is a fairly easy fix with hopefully some performance implications as well (when updating rapidly). I'd be more than happy to fork/change/test it and submit as a pull request if you were inclined to go down this path! |
Ah, yes that makes more sense to me now, thanks. Indeed, your update() recommendation is a much better way to go. I would be thrilled with a PR if you get that far. I plan to spend some time on the firmware early next week so please PR as far as you get and I can pickup where you leave off. |
Changes merged and tested by @nseidle! Closing this baby down. |
EEPROM.write is used all over the place to save settings on-the-fly (without an explicit 'save settings' command). Since sketches will mostly configure the SerLCD in setup(), this means that every time the sketch starts (at least) it is writing to the EEPROM a number of times for Backlight, Contrast, etc. It also dramatically slows the operation down.
Two solutions:
Option 2 is the more performant one, but Option 1 is probably preferred because of compatibility.
The text was updated successfully, but these errors were encountered: