Use createChar_P to save SRAM in bootscreen

[thinkyhead]

The boot screen uses custom characters too, so using createChar_P allows it to give back 32 bytes of SRAM.

I'll continue to add to this PR as I look for other variables (instances of const static throughout the code) which can be moved to PROGMEM. We may be able to recover as much as 1K of SRAM with typical configurations.

• Recover 32 bytes of SRAM in bootscreen
• Recover 80 bytes of SRAM in pin_is_protected by putting sensitive_pins in PROGMEM.
• Recover 16 bytes of SRAM by moving homing_feedrate_mm_s to PROGMEM.
  (Costs 32 extra bytes of PROGMEM to access.)
• Recover 100 bytes of SRAM in pin_is_protected
• Recover 48 bytes of SRAM in get_homing_bump_feedrate
• Recover 48 bytes of SRAM in MarlinSettings::reset
• Recover 20 bytes of SRAM with DIGIPOTS_I2C. Also much PROGMEM.
• Recover 20 bytes of SRAM in UBL smart_fill_mesh

Total recovery so far: 364 bytes SRAM. Several K of PROGMEM, possibly.

[Roxy-3D]

Oh! I even knew those existed! I must have had a brain fart to not include those too.

[fiveangle]

I'm currently investigating a 1k hacky bootloader for the AT90USB to replace the Atmel 4k DFU bootloader (which apparently reserves 5.2k - wtf ???) just because Marlin has gotten so feature-rich, I want them all, so everylittle bit [sic] helps. 😉 Thanks !

[thinkyhead]

Excellent. Our main emphasis is definitely on recovering SRAM, as we have lots of PROGMEM to spare. Good luck!

[Roxy-3D]

I bet there is a bunch of RAM to be saved when we crawl through the Graphics LCD Panel code.

If that is true, would we be willing to have a Marlin version of it?

[thinkyhead]

We were talking to @olikraus about optimizing the u8g2 for our purposes. I think we already did an awful lot of optimization, but going forward we also need to think about 32-bit boards, touch-panels, and other considerations, so having a good optimal set of libraries would be ideal.

[fiveangle]

@thinkyhead speaking of optimizing, couldn't DAC_STEPPER_CURRENT be changed from uint16_t to uint8_t since drive percent is always 0-100 ?

Also, do we really need to see motor current percent as float ? I would think closest integer value is sufficient (seeing it reported as float while configuring my printer is what got me digging into it, which led me here).

I know you can take this too far, but same thing with PID Kp and Kd values, but everyone loves to believe that those 2 extra decimal digits that M303 spits out are significant ;)

[Roxy-3D]

That's a free byte.... Take it! And any conversion from float to int is 2 free bytes...

[fiveangle]

I just checked and with this change: fiveangle@3261024

I get:

Sketch uses 84748 bytes (65%) of program storage space. Maximum is 130048 bytes.
Global variables use 3263 bytes (39%) of dynamic memory, leaving 4929 bytes for local variables. Maximum is 8192 bytes.

Compared to:

Sketch uses 84742 bytes (65%) of program storage space. Maximum is 130048 bytes.
Global variables use 3259 bytes (39%) of dynamic memory, leaving 4933 bytes for local variables. Maximum is 8192 bytes.

Is Global variables the SRAM ? If not, how do you guys check that ?

[Roxy-3D]

Is Global variables the SRAM ? If not, how do you guys check that ?

Yes. The AVR parts we are using have 8KB of Static RAM inside them. The Global variables are always present. The space for them is 'hard allocated'. They can be accessed from any code that knows how to reach out and touch them.

The local variable space is what is left over out of the 8KB or RAM. The stack lives in that space. And any local variables defined at the start of a function live on the stack. They go away when the function exits. (Any static variable is an exception because it ends up in the global space even though it was declared at the start of a function.)