power_on should not be modifying
EEPROM_MMU_ENABLED. The code is never
executed unless it's already been set.
Only disable EEPROM_MMU_ENABLED through Buttons::DisableMMU
Change in memory:
Flash: -18 bytes
SRAM: 0 bytes
The status line code is not nice, but we need to work around it
so the status line rendering works correctly
This commit mostly reapplies the code
from 3.13.2
Also fixes compiler warnings
- Rename "Idler" to "Sensitivity"
- Implement ReadRegisterInner() as a way to read register in blocking contexts such as manage_response()
This allows us to show the current EEPROM value on the printer's LCD
Add a 'Tune' option to HOMING_IDLER_FAILED error
This will open a menu which allows
the user to change the stallguard threshold
from the MMU error screen
Change in memory:
Flash: +334 bytes
SRAM: +1 byte
Proposal to fix some of the issues with the initial implementation
it is safer to use the status line code to print the message so
there aren't any conflicts in the LCD cursor position.
Allow inserting a byte into any position in the LCD status message
Also, add a variable to control from which index in the array
should the message start printing. This is very useful for progress
bars and messages which continually update. I think we can save some
memory by applying this to Mesh Bed Leveling later.
Change in memory:
Flash: +106 bytes
SRAM: +1 byte
We should let EndReport set the custom message type state to Status
This will ensure the SD file name is shown correctly AFTER we've shown
the visualisation
Currently the visualisation is cut off in the middle by ReportProgressHook
Change in memory:
Flash: -6 bytes
SRAM: 0 bytes
This fixes the spurious feedback when rotating the knob
because lcd_update is called much often than the interval
at which the lcd rendering is updated
Change in memory
Flash: -88 bytes
SRAM: -9 bytes
This commit adds the ability for firmware to make sounds when the
knob is clicked or rotated, when LCD updates are disabled.
The improvement here is the sound is being made with one line of code
whether or not LCD updates are enabled or disabled.
Change in memory:
Flash: -24 bytes
SRAM: 0 bytes
Noticed this when exploring another optimisation
By specification exactly which overloaded function to use
we save some memory
Seems to have something to do with doing arithmetic in the function argument
Change in memory:
Flash: -156 bytes
SRAM: 0 bytes
In case we are running a retry, the firmware
should clear the old rendering before
starting on a new one
Change in memory:
Flash: +6 bytes
SRAM: 0 bytes
The general idea is to keep platform specific implementation away from the MMU state machines as much as we can.
That would enable unit testing the top level MMU state machine and integration into other project as well (if needed).
Guðni Már Gilbert
Alex Voinea
D.R.racer
3d-gussner