> Fortunately 3D printers seem to be transitioning towards hardware that's less insanely limited.
If you use some of these more powerful CPU'd printers, you find a problem...
Typically the powerful CPU's run an OS (eg. FreeRTOS), and have multiple processes doing different things.
However, the Marlin software which is common in the 3d printer world is designed to run bare metal. When you put it into an OS thread, it stutters and misses steps on the motors when moving fast. There are places in the code which are timing critical - eg. "this loop must complete in 168 clock cycles or fewer for correct operation".
Modern CPU's might be far faster, but they aren't good at microsecond accurate timing. Rewriting marlin to not rely on being able to rely on such low latency stuff would be a lot of work.
Marlin barely fits on the Arduino anymore, and that's why recent releases also target ARM and ESP32.
In any case, my point is that the Atmel Arduino architecture is old and limited, and imposes a number of design constraints. There's hardware that's both better and cheaper out there now.
You're talking about AVR8, which is the ATMega328p and its children and siblings. There exists, though less popular, a complete rebuild of the AVR architecture in 32-bits called AVR32. The instruction set is different, the peripheral IO is different, but the design is similar. The AVR32 was powerful enough for quite some time to run a full fat Linux, though this was dropped for a handful of reasons.
Another solution that in my experience seems to work pretty well is what mainsail does. The motion planner runs on a raspberry pi. Theoretically this needs to be a realtime thing, but in practice the RPi is fast enough to where it's never a bottleneck. The actual stepping of the motors is handled by a more traditional microcontroller board with some very basic firmware. As far as I understand the RPi is sending it (step count, direction, rate) commands.
This solves a lot of issues since the microcontroller is doing some really basic things it's well suited for, and the RPi is freed from having hard realtime responsibilities.
Modern CPUs can do microsecond accurate timing just fine. You do need to design the software correctly, however, not just shove something into an RTOS thread.
If you use some of these more powerful CPU'd printers, you find a problem...
Typically the powerful CPU's run an OS (eg. FreeRTOS), and have multiple processes doing different things.
However, the Marlin software which is common in the 3d printer world is designed to run bare metal. When you put it into an OS thread, it stutters and misses steps on the motors when moving fast. There are places in the code which are timing critical - eg. "this loop must complete in 168 clock cycles or fewer for correct operation".
Modern CPU's might be far faster, but they aren't good at microsecond accurate timing. Rewriting marlin to not rely on being able to rely on such low latency stuff would be a lot of work.