Optimize and encapsulate Power-Loss Recovery

[thinkyhead]

The Power-Loss Recovery code as originally adapted was a more-or-less straight port of the version produced for the CR-10 by @Creality3DPrinting. Since that version was intended for the 1284 it could use SRAM with impunity. But this made the feature prohibitive for ATmega2560 and other chips with limited SRAM. This PR significantly reduces the SRAM usage, making the feature more accessible for RAMPS and derivatives.

• General cleanup of the power-loss recovery code. (Saves ~722 bytes of flash.)
• Replace the power-loss command queue with sub-command calls. (Saves ~1242 bytes of SRAM.)
• Encapsulate Power-Loss Recovery in a static singleton.
• Add a (hidden) G-code M1000 to run power-loss-recovery in the command context.
• Add M143 to enable/disable power-loss recovery.
• Add a menu item to the Configuration to enable/disable "outage" recovery.

[MagoKimbra]

Do not let Z rise to the right height, only on the first layer change ...

dtostrf(info.current_position[Z_AXIS] + RECOVERY_ZRAISE, 1, 3, str_1);
..
sprintf_P(cmd, PSTR("G92.0 Z%s E%s"), str_1, str_2);
gcode.process_subcommands_now(cmd);

Now Z is at current position + RECOVERY_ZRAISE, it's ok but you must add command G1 Z info.current position

dtostrf(info.current_position[Z_AXIS], 1, 3, str_1);
sprintf_P(cmd, PSTR("G1 Z%s"), str_1);
gcode.process_subcommands_now(cmd);

[ejtagle]

You can easily save 7 bytes of SRAM by compacting all those static bools into bitfields!

[thinkyhead]

Do not let Z rise to the right height, only on the first layer change ...

Thanks! I thought that was already in there, for some reason.

[thinkyhead]

You can easily save 7 bytes of SRAM by compacting all those static bools into bitfields!

The ones that are convenient to combine save 5 bytes of SRAM but cost 42 bytes of program memory. So, maybe worth it, maybe not. 5 bytes of SRAM isn't much in the big picture. Maybe there are some algorithms that can be optimized for more significant savings.

[ejtagle]

You can easily save 7 bytes of SRAM by compacting all those static bools into bitfields!

The ones that are convenient to combine save 5 bytes of SRAM but cost 42 bytes of program memory. So, maybe worth it, maybe not. 5 bytes of SRAM isn't much in the big picture. Maybe there are some algorithms that can be optimized for more significant savings.

Yes, but on embedded devices, usually SRAM is the most valuable resource:
AVR has 8192 bytes, so 5 bytes are 0.06% of total RAM. Not a huge amount.
42 bytes of FLASH of a total of 262144 bytes is 0.016%- So, basically, releasing 5 bytes of SRAM is porcentually releasing more resources than the extra consumed by the extra bytes of FLASH.
I do agree that on the big picture, it is not something to worry about, but i always tend to worry more on SRAM. There are some very basic things that can save the 42bytes of FLASH...

And i also agree with your idea of trying to reduce statics at the expense of local variables. That is also a win

The only places where this can´t be done is on the stepper ISR, where we prioritize execution speed and atomic access over SRAM consumption - And on AVR there is even a possibility to improve the stepper, by decreasing the size of the accumulator, when the number of steps is small .. It can yield HUGE savings on execution time on AVR (on ARM there is no advantage at all, quite in fact, reducing accumulator size incurs a penalty in execution time)

[thinkyhead]

Yes, but on embedded devices, usually SRAM is the most valuable resource:

True… but ironically, the 1284 has 16K of SRAM, so it's twice as important to save program memory for the benefit of those devices than it is to save SRAM.

[ejtagle]

Yes, but on embedded devices, usually SRAM is the most valuable resource:

True… but ironically, the 1284 has 16K of SRAM, so it's twice as important to save program memory for the benefit of those devices than it is to save SRAM.

Perhaps we should do an audit to try to figure out what piece of code is taking the most part of FLASH, and optimize it ... I still think the LCD menus should be a finite state machine and the menus themselves should be defined by tables in FLASH

[thinkyhead]

Making the menus into data structures would be an interesting exercise. One effective optimization I did at one point was to move the scrolling code that was being repeated in every menu handler into a separate function. I also modified the menu item loop to only iterate over the visible items. The commonalities beyond that are harder to discern, as there are some menu items that should only appear under certain conditions, and there's a free mixture of back/cancel/function items, sub-menus for editing, static items, and so on. Probably some more of the logic currently embedded in menu macros can be split out to common functions.

My next task —now that power-loss recovery has been optimized to save loads of SRAM— is to reduce the amount of rendering on the graphical status screen by having a first-time render and then a change-only render on subsequent updates. This would allow for a more graphic display of the hotend and bed heating status, among other things. It should also allow a more free arrangement of heater icons, and should save a lot of flash by not requiring a full header for every fan animation frame.

Once I get through that work, I will revisit the menu items and see what other optimizations are possible.

[ejtagle]

@thinkyhead : What you want to achieve on the

is to reduce the amount of rendering on the graphical status screen by having a first-time render and then a change-only render on subsequent updates.

Is impossible if you use u8glib. u8glib ALWAYS requires a full render.
I know because i am still working on a "partial render" idea, and the first thing i had to do was to drop u8glib
The display itself CAN be partially rendered, but u8glib still insists on rendering the whole screen ...

[thinkyhead]

@ejtagle — Yep, I can confirm there's no facility in u8glib to reduce the amount of data it sends over to the display — it always sends a full page. The only flash-usage optimization I would be able achieve is to break up the status bitmap into smaller units, with best performance by maintaining them on byte boundaries. The drawing of bitmaps is reasonably fast, especially unshifted, and this all occurs prior to the transmission over SPI, so I'm going to keep experimenting with the graphics in the top 20 display lines and take some time measurements to see how much performance is actually affected by splitting up the graphics into smaller pieces.

[ejtagle]

@thinkyhead ; Right now there is no FLASH usage strategy as far as I can tell. Bitmaps are small, fonts are "small" ... We could compress them and decompress them on the fly, and that could save maybe 50% of the font size or even more (i have played with that idea previously, i did an implementation and i know that it works very well)
But, it all depends:
-If you want flash reduction, table driven menues, font compression, maybe plaintext compression. All those combined could easily save 5kbytes of FLASH
-If you want to speed optimize the blitting of graphics, the way u8glib works is the bottleneck. You need a different library that is able to do partial reconstruction and partial blitting of the framebuffer, based on the idea of dirty rectangles. u8g will not work for that.

[AnHardt]

Some time ago we did not switch to u8g2-lib because we couldn't get the same speed as u8g-lib on the ST7920 based displays. Mainly because of the slower transfer rate. Since some days (weeks?) u8g2 seems to support refreshing of dirty rectangles. If the speed winn by that is big enough, we could start another try.
U7g2 also already has a builtin font-compression.

[ejtagle]

Dirty rectangles technique is a big win, if the amount of screen area that is actually changing is small compared with the total screen area.
Assume only numbers change: That is less than 25% of the screen, so big savings can be achieved!

[thinkyhead]

what piece of code is taking the most part of FLASH

• The kernel of Marlin uses about 56K of flash.
• The LCD code —especially the graphical LCD— uses up quite a bit depending on how many menus are enabled.
• The SD Card support code is one of the more costly features.
• EEPROM_CHITCHAT is probably the next most expensive option after that.
• Then the bed leveling features are probably the next most expensive group.
• When multiple extruders are enabled, the code becomes more complex, so just EXTRUDERS 2 is likely to be one of the more expensive features.

[ejtagle]

@thinkyhead : Something that should be taken into account is the price of FORCE_INLINE. I do agree that if speed is the utmost important thing, FORCE_INLINE is a win situation.
I also agree that for simple functions, using FORCE_INLINE also reduces code size, as the overhead of the call setup is greater than then implementation.
I also agree that when function parameters are all constant, using FORCE_INLINE allows GCC to use constant folding and essentially reduce to a compile time computation the function, thus reducing code size.
But, under the following conditions, FORCE_INLINE is not a good thing:

1. Algorithm is not time critical (for example UI)
2. Function is used more than once
3. Parameter functions are not constant
4. Function is not trivial, for example, contains ?: or if or loops of any kind, or switch statements or more than 1 line of code. On those situations, FORCE_INLINE is expading the size of Marlin without any significant gain.

So, that is something we can also play with.

[thinkyhead]

Yes, as you can see from 471f403 I've been doing testing along those lines.