In a SBC it is hard to do real-time stuff but there is access to the much faster processor and far more advanced cores and arithmetic logic units. This makes it possible to add more shaping into the input for directions. So each axis can move very quickly near the limits of how fast the physical hardware is capable. The calculations are made to ramp the speed up and down in ways that a little 8/16 bit microcontroller is incapable of achieving. This is also why printers with a 32 bit micro are a little faster as well. The microcontrollers used are like 16-72 MHz but there is no overhead like with an operating system. However, they are also running the PID control algorithms for the bed and hotend. You need both a SBC and a microcontroller unless you get into super niche setups. OS kernel configurations have issues with real-time tasks due to some of the ways kernel space is abstracted in an OS and how the CPU scheduler juggles running process threads and interrupts in the OS and hardware. People do not typically mess with a SBC on this level like adding core isolation with a dedicated thread with the CPU scheduler set to real time. There are other potential factors like core spin up, temperature, and power management that need addressing in the kernel too for RT. This is as far as I understand it, as this is a curiosity I’ve barely scratched the surface of a few times. Hopefully this abstract overview kinda helps.

Think of a microcontroller like a simplified computer from the late 1980s. It is about like an original Nintendo Gameboy but all the extras like memory and RAM are built into a single little chip and the architecture is simplified a little bit. Something like a Rπ SBC is about the same class as a 10yo smartphone. It is actually a TV set top box tuner chip with all the set top box stuff ignored and undocumented.

Marlin is like Arduino firmware. It is just a project that is well organized and setup with an extensive configuration menu about like configuring the Linux kernel. You are prompted with options and you select what is relevant. This is then compiled in a Makefile and you upload the binary to the microcontroller just like an Arduino. The software is setup to make it easy to add similar hardware and maximize entry points so that you can try novel stuff. Unfortunately, Prusa does not run Marlin like this. They are on their own branch of Marlin that specifically makes it difficult to configure and make changes. It also makes cloning a Prusa impossible in practice because they can make changes that will break compatibility. This is the underlying reason the real hobby hacker community that originated around RepRap and the MKx name moved to projects like Voron. The limitations and changes to Marlin were due to Prusa not wanting to break upgrade compatibility and sticking with the AVR microcontroller all the way up to the MK4. They pushed the micro really hard to do both the printer and multi material stuff along with all the fine tuning. So that is kinda the legacy reason for how things evolved.

Personally, I don’t care that my printer is a slow MK3S+. It works well without ever doing a calibration any more and I can print PLA, PETG, TPU, PC, and PA/ABS/ASA with a few caveats. I don’t run my printer 24/7 or even daily, so I am slower than the machine.

I got a little Kingroon KP3S to mess around with Klipper and see if I wanted to build a Voron. I decided not to. Running Klipper means you must setup and dial in all the fine tuning details that Prusa is doing for you with the original firmware. You lose the it just works factor. That is totally fine if your priorities align with this methodology. The KP3S is capable of running Klipper on the original board after just adding the Rπ and loading the firmware. That is probably the cheapest half decent way to mess around with a project printer in Klipper. I never use the thing though.