Custom Splash Screen

[AnHardt]

Custom Splash Screen for full graphic displays.
Too complicated for the hitachis without knowing what exactly to display.

Realisation of an idea from #3996

Used the big Marlin logo as an example.
Custom logo is displayed before the normal Marlin logo. No text. Text can be integrated into the graphic if needed.

[AnHardt]

Seems to be a problem with LIN_ADVANCE

The command "opt_set MOTHERBOARD BOARD_RUMBA" exited with 0.
0.01s$ opt_set EXTRUDERS 3
The command "opt_set EXTRUDERS 3" exited with 0.
0.01s$ opt_set TEMP_SENSOR_2 1
The command "opt_set TEMP_SENSOR_2 1" exited with 0.
0.01s$ opt_enable_adv LIN_ADVANCE
The command "opt_enable_adv LIN_ADVANCE" exited with 0.
7.62s$ build_marlin
Picked up JAVA_TOOL_OPTIONS: 
Loading configuration...
Xlib:  extension "RANDR" missing on display ":1.0".
Initializing packages...
Preparing boards...
Verifying...
sketch/stepper.cpp: In member function 'void Stepper::advance_M905()':
stepper.cpp:1127: error: 'code_value' was not declared in this scope
     if (code_seen('K')) extruder_advance_k = code_value();
                                                         ^
exit status 1
'code_value' was not declared in this scope
The command "build_marlin" exited with 1.

[thinkyhead]

Should be ok now. This PR is fine as it is.

[thinkyhead]

Could this perhaps be this instead…

#if ENABLED(CUSTOM_START_BMP)
  if (show_bootscreen) {
    u8g.firstPage();
    do {
      u8g.drawBitmapP((128-(CUSTOM_START_BMPWIDTH))/2, (64 - (CUSTOM_START_BMPHEIGHT))/2, CUSTOM_START_BMPBYTEWIDTH, CUSTOM_START_BMPHEIGHT, custom_start_bmp);
    } while (u8g.nextPage());
    delay(CUSTOM_START_BMP_DELAY);
  }
#endif

[AnHardt]

Of cause.

[thinkyhead]

Too quick!

[AnHardt]

Shouldn't all the parsing be done in Marlin_main.cpp?
That would result in better reusable functions and wouldn't spread the parser all over the files.

[thinkyhead]

all the parsing be done in Marlin_main.cpp

Yes. I tend to agree. This was a matter of style "experimentation" to encapsulate the gcode handler for that command in the class — a thought that we might want to try going that direction for better encapsulation of functionality.

Requiring all the GCode handlers to reside in the same file (or compilation unit) as the GCode parser makes Marlin_main.cpp awfully huge now. But I suppose we could split all the GCode handlers into their own .h files and include them en-masse in Marlin_main.cpp as a way of shrinking the file. It bothers some to have .cpp-style code in .h files, but it's not the worst thing.

It would be cleaner to rename GCode handling functions based on what they do, and then have them take arguments instead of using the GCode parsing functions. But then some of these functions (like the G29 handlers) would end up needing a lot of parameters.

I know we're all still thinking about ways to get the parser to perform better, using tricks like getting all the arguments in advance for each command so the string only ever gets scanned one time. I really like the Matt Roberts' Firmware approach, which should be faster. But it would be a minor overhaul.

[AnHardt]

@thinkyhead

Matt Roberts' Firmware

The A-Z-array will take its space - but i think it would be a good investment for the g-codes with a lot of arguments. G0/G1 will profit a lot. That's what we are looking for. The codes with no, or few, arguments will likely suffer a bit from resetting the big array (26 * 4 byte)

[thinkyhead]

likely suffer a bit from resetting the big array

I was thinking about that. It could just reset the indices that were found instead, but we'd have to store the found-argument indices in yet another little array.

[thinkyhead]

So #3996 should be altered to utilize this technique, or…? Not sure where we would set a flag to use his custom bootscreen, and we don't want to supplant this one. So… I guess, that PR should drop the custom boot screen and the custom code calculating the centering… and all that can exist in the Cartesio UI fork, not in the main Marlin.