I recently joined Tom and Stefan on "The Meltzone" to talk about the state of #opensource and @marlinfirmware. It was a great conversation and it was a lot of fun to hang out with two guys who really know and love this technology. #3Dprinting #RepRap https://youtu.be/4aMo5IyVeu0
The man behind Marlin: How an open source project works! - The Meltzone Podcast Ep 70

YouTube

@thinkyhead @marlinfirmware I guess a future development for MarlinFirmware would be to take a leaf from Klipper's book and introduce some code partitioning.

You could e.g. make a split into marlin-driver and marlin-manager where the former handles the machine-specific parts and the latter the higher-level details. The interface between the two parts could be SPI (for co-resident) or USB (for separate) implementations.

This would also permit divergence in implementations in the future with the machine-specific parts being written in an efficient embedded language while the higher-level detail could be re-engineered using whatever is appropriate to the (changing) technology it runs on e.g. Rust or Zig.

@neil The paradigm of @marlinfirmware is to produce an efficient and tailored firmware binary that runs on a single board, so a complete rearchitecting in the style of Klipper is beyond the scope of the project. And boards are getting more powerful all the time. That said, Marlin does have a “Direct Stepping” feature which allows a “stepdaemon” running externally to do the motion calculations.

@thinkyhead @marlinfirmware That's fine, in principle, but consider that single board controllers with multiple microcontrollers or mixed microcontroller/SoC setups become the standard (primarily driven by Klipper).

It might be wise to adopt the "never say never" philosophy rather than stick with the original project goals which could lead to stagnation of the project.