- currentValue must be initialised when entering the menu
- Consume lcd_encoder value when editing an item
Change in memory:
Flash: +40 bytes
SRAM: 0 bytes
Properly increment menu_item when the menu item is clicked so that you don't get multiple menu items clicked if in view (when the menu code is deduplicated to functions)
lcd_encoder was int32_t (4 bytes) because of the menu code
when editing through the menus, the menus only accept
int16_t so it doesnt make sense to use int32_t.
Change in memory:
Flash: -892 bytes
SRAM: -2 bytes
This change needs to be approved of course due to it affecting UI
The affect UI is only one menu
lcd_settings_linearity_correction_menu
I doubt many users are using this menu except very advanced users.
I propose we delete the variant of menu_draw_P which was used for
uint8_t but renders them as floats.
Instead treat
uint8_t same as int16_t i.e. just render integers.
Keeping it simple :) Solve our fanSpeed problem.
Change in memory:
Flash: -140 bytes
SRAM: -2 bytes
Used lcd_print_pad_P is some obvious places. We can probably use
this function in more places to further save flash memory
Change in memory:
Flash: -268 bytes
SRAM: 0 bytes
ON_MENU_ENTER runs code within the brackets only once
after a new menu is entered.
For the tool change menu, this allows us to display the data and
read from EEPROM only once.
Call this variable menu_block_mask instead. We don't need to know the
exact reason of why we're locking the menu.
We will be able to reuse this to prevent menu entry during more
activities in a cleaner way than testing for each condition as it's
currently done for both menu entry and longpress.
General fixes to the lcd_edit_off item and improved way to generate the toggles.
The old process is this: Write '>' if required -> print base -> pad everything before the last character with spaces -> write the eol character -> jump back and print the toggle over the blank characters. This resulted in noticeable flickering when the toggle was redrawn and was showing the same thing. Now the process is similar, except that everything happens in a "line buffer" (a char buffer that holds an entire line) and gets printed in one go, avoiding jump instructions for the lcd and prevents flickering since it doesn't write ' ' and the letters afterwards.
This should get even better when the lcd_buffer gets implemented since the line_buffer will get compared to the existing data on the screen and avoid overwriting what is on the lcd with the same thing.
Guðni Már Gilbert
Alex Voinea
D.R.racer
Yuri D'Elia
DRracer