Had forgotten to redraw adjust menu after normal update, it was only redrawn when the sensor pixels were to be updated.
As a bonus I cleaned up some code.
Had to change how the values where stored in RAM from singed to unsigned to be able to use the generic menu features. Also had to add the MenuEntrySub as a parameter to the menu callback functions to be able fo display and store the correct values.
Did some major cleanup now that the special case of rotator menu is gone together with all uses of the old version of the sub menu struct.
This is a big one where I can finally reap what I sown. Sub menu entries now provide two functions, one to get the text for the current value and one to apply changes aka save to EEPROM. With this I can replace so much code in the menu() function that handles input, but was _almost_ identical. The process of converting the old menus are not completed, and I can probably remove about 200 lines more code.
The question is still what to do with less general menus like the rotator and fast patch menu.
One problem with the current implementation is that it is RAM heavy. It seems the const MenuEntry structs are placed in ram, because there is a pointer to RAM that I assume is allocated during execution and therefore the address cannot be stored in ROM.
My plan has been to put all the configuration fields (that are stored in EEPROM) into a struct or an array. When that is implemented, I can instead store the offset into the array in the const struct, which should be available at compile time and therefore can reside completely in ROM.
* Moved menu titles and option names into data structures.
* Unified select menu option code
* Also unified handling of menu selection, although main and rotator menus are still handled the old way.
* Moved struct definitions to numenu.h
* Grouped functions and variables together based on usage.
Some major refactoring has been going on.
Added simple structs of data containing info about what action to take when a menu item is selected.
Finally removed all but one call to display.display() in menu-function. There might still be more than one call to it on a frame though, since some functions still calls it internally.
Moved functions around to have a better overview of draw function. This will make it easier for me to continue with the next part, which probably will be a more generic handling of menus.
* Broke up the code into more general functions instead of duplicating code
* Made stuff const and removed variables no longer used
* Use defines for menu button values
* Changed the order or things to avoid forward declarations
* Use array lookup instead of switch-case on some menu options
* Adjust menu functionification
* Cleaned up sensor rendering
This bug would probably never happen in real life, and could be fix by holding down menu and enter buttons at startup. But a bug is a bug.
The only reason I found this bug is that the simulator didn’t initialise EEPROM to 0xff, and even after I did that it crashed, because a version of 0xffff wasn't handled.
A bug in the current NuEVI.ino does not write all default values to EEPROM on the first boot, unless menu + enter buttons are pressed. I added a workaround to the simulator that fakes that the buttons are pressed when calling the setup function.
* Press W in simulator to activate (pretty slow shit, do avoid unless compiling with optimisations)
* Tiny improvement of the EEPROM simulation.
* Fixed type typo for millis and micros
