Sync with the 32-bit side.
The ReportingRAII does not handle recursion.
Fixes an issue with the multiple calls to
BeginReport() and EndReport()
Change in memory:
Flash: +14 bytes
SRAM: 0 bytes
If the protocol reports and error and give errorCode
a value. When the error is resolved, errorCode is not reset to OK.
If the MMU is not in an error state I would expect errorCode to reflect that.
This fixes MMUCurrentErrorCode()
Change in memory:
Flash: +12 bytes
SRAM: 0 bytes
Restores 3.12 sequence which was working well before.
M600 "L" parameter now works like M702 "U" parameter.
Removed a lot of the unused parameters which were copied
from Marlin 2.
Change in memory:
Flash: +96 bytes
Code size increases a bit but keep in mind the PR
that broke the behavior "saved" 182 bytes:
https://github.com/prusa3d/Prusa-Firmware/pull/4063
So I think this code size increase is OK
Change in memory:
Flash: +84 bytes
SRAM: 0 bytes
The new code did not take into account the minus sign.
The template for menu_draw_P is removed since there is no benefit in
uint8_t version of this function since the value
is converted to two bytes anyway by lcd_printf_P.
Change in memory:
Flash: -92 bytes
SRAM: 0 bytes
If MMU slot is outside of range, then we rather the printer
not do anything. Currently it would accidentally assume
the MMU is disabled. This may have undesireable results.
No change in memory
If the remaining print time is more than 10.9 hours at 100%
then increasing the feedrate multiplier
to 101% or more will yield an unrealistic time due to overflow occuring.
Change in memory:
Flash +2 bytes
SRAM: 0 bytes
Guard the feedmultiply code with
lcd_encoder.
if lcd_encoder = 0, then there is no need to check if
feedmultiply should be updated.
Also set lcd_encoder to zero in one line to consume the rotation event.
Change in memory:
Flash: -40 bytes
SRAM: 0 bytes
Shouldn't make a difference since the array is already defined as 8B long, but I just found it weird and surprising when I noticed only 7 lines were defined
Guard the lcd_display_message_fullscreen_P call by blocks_queued(). If there are no planned moves, there is no need to render this message, it creates a weird LCD draw noticable by the user.
Change in memory:
Flash: +10 bytes
SRAM: 0 bytes