Closed bazmonk closed 2 years ago
As I mentioned before, I suggest using the eeprom clear code as a step before updating to avoid any potential clashes…it’s always good practice to start with a freshly clear slate..I’ve used this on several occasions when installing our beta and test codes for the digi development
This gives an option upon startup (only that screen, not the mid-play pause screen) to clear eeprom before eeprom is accessed.
Should hopefully fix these EEPROM-related bugs.
Also defined and made available a set of four save "slots" in EEPROM, and screens to use them.
Turns out using Adruino's byte
object sucks. Using integers (even though they are at least 2 bytes, not one byte) works fine as long as I pinkie-swear not to store a value over 255 with it.
Will add some documentation and then I'll call this closed.
I've added clearing the EEPROM to the README. Closing this.
Two different issues were ultimately solved by clearing the EEPROM:
https://github.com/bazmonk/digigurdy-baz/issues/23 https://github.com/bazmonk/digigurdy-baz/issues/21
I don't know exactly where this is causing problems, but it's clear that it's doing something. I am using the EEPROM to store different values than John did, but I thought that mine would simply overwrite them, and that they wouldn't lead to these bizarre things.
I think I could fix the actual problem of funky EEPROM messing up digigurdy-baz, but at the same I noticed two other issues:
int
to EEPROM. These are 16-bit values. They should be bytes, 8-bit values. Gotta fix that, and it could be part of this whole issue.I'm going to create an
eeprom.h
header and a rough structure to hold several sets of tunings, in anticipation of supporting multiple saved tunings.In addition, I'm going to re-work the save scheme to support it, and support tuning without saving.
And finally, I'm going to create an option to clear the EEPROM--which fixed things in both these cases.