[dfasdfasd]

No, on most CNC machines the controller actually handles much of the motion planning.

The slicer will generate a command that says go from point (x1, y1, z1) to point (x2, y2, z2) with speed f, but it doesn't say anything about acceleration, or how to transition into the next move. A very simplistic controller will use a trapezoidal ramp profile where it will ramp up to the programmed feed rate at a fixed acceleration, then stay at the programmed feed, then ramp down in time to reach the end point. However, if the move was a very short line or arc as part of a large surface, the machine doesn't need to reach 0 speed before starting the next move. A smarter controller will 'look ahead' to predict the next few move and plan the motion of the machine to eliminate jerkiness or stopping.

The slicer may tell the machine what acceleration to use, but that's really just setting a parameter in the machine controller, and isn't settable per-move.

This isn't as critical for 3D printers as it is for big, heavy milling machines. Nevertheless, you can do clever things like trying to compensate for vibration, or speeding up or slowing down the extruder motor based on the pressure of the plastic in the nozzle.

This isn't to say Prusa is switching just to do better motion planning, it sounds like that isn't a primary goal, but I'm trying to illustrate there is a lot more room for intelligence than 'just wiggling some IO'.

[dual_basis]

I see.

I can see some benefit to motion planning on the device if, for example, decisions are being made based on real-time data. For example, if there is a pressure sensor for the nozzle then the board could use this this realtime data to adjust it's motion.

If there's no realtime data being input then everything is simply a deterministic function of the gcode, and all of these aspects related to acceleration and jerk can be precomputed on your powerful multi-core desktop and "rolled into" the gcode.

[dfasdfasd]

It can't be "rolled into" the gcode though. Gcode is sadly extremely limited, and while you could build some pretty complex extensions, there is no reason to avoid switching to a (cheaper) more powerful microcontroller to avoid building gcode hacks.

Regardless, I was just pointing out one place where a bit of extra power could help with printing. However, that's not really the point. It's not that the core _needs_ to be 32 bit, it's that most modern microcontrollers are 32 bit. The Atmega is more expensive, has less memory, no JTAG, no DMA, poor debugging support, and mediocre peripherals. The extra power to run more advanced motion control is just a bonus when you switch to a modern Cortex-M.

The real usefulness of power is the possibly to add other features not directly related to printing like built-in ethernet/wifi, or a larger screen (it drives me nuts that I can't see longer file names on my Prusa screen).