Marlin

There is _a lot_ wrong with Marlin. It is a complex codebase, full with ancient artefacts, litterred with preprocessor ifdefs every 2-3 lines of code, dynamic includes in the middle of CPP files, etc[1]. It's about as unreadable as C++ code gets--well, I guess it's not template metaprogramming. Klipper by contrast is a breeze to read through[2]. I am very grateful for Marlin, for all of reprap, and everyone who has contributed to it. But saying there is nothing wrong with it is straight up misguided. [1]: https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/M... [2]: https://github.com/Klipper3d/klipper/blob/master/src/lcd_hd4...

In fact many embedded requirements are not as complicated as a 3D printer and essentially consist of basic logic and state, sensors and effectors, potentially with some external communication. It may surprise you but 8 bit micros are absolutely fine for this and can serve HTTP at well over a hundred requests per second without breaking a sweat. If you read the Stepper code for Marlin @ https://github.com/MarlinFirmware/Marlin/blob/1.1.x/Marlin/s... you will see it's nontrivial... bunch of PhDs implementing nontrivial maths in a highly constrained environment. That's cute but not demonstrative of real world concerns. In such cases, you would absolutely throw more hardware at the problem, eg. for motion systems maybe dedicating one 'dumb' MCU per axis and outsourcing planning to a more rational/powerful environment.

This is cool. It reminds me of 3D printers, but just in two dimensions and with a paintbrush and paint instead of a hot-end/nozzle/filament. You could look at the firmware used to control the stepper motors/end stops that much of the reprap community is using at https://github.com/MarlinFirmware/Marlin. This uses GCODE as well, and deals with acceleration around turns.