3D printer controllers have to do a lot of stuff very, very fast. Performing kinematics and dynamics calculations while sending many thousands of precisely-synchronized step pulses per second is really, really hard. The 8bit AVR line of microcontrollers used in older 3D printer controllers is basically a late-1990s era Mr Coffee processor. They are completely, utterly maxed out on processor time just executing basic printing functions in simple (eg Cartesian) printers, and adding additional calculation load will bog them down and cause slowdowns, stuttering, pausing, and so on.

"But my 8bit printer works fine," you say. No, it doesn't. Your print performance is limited by it, whether you realize it or not. Slicers now automatically hide a lot of the firmware's performance shortcomings from you. For example, the standard practice of greatly slowing down print speeds on perimeters is largely a result of 8bit processors having inadequate resources for two things:

1. Performing centripetal acceleration calculations for curves
   across multiple gcode segments


2. Keeping up with gcode transmission/processing and motion planning for gcode with lots of very small segments, such as in organic models or smooth arcs

When presented with a series of very small segments in a smooth arc or complex curve, the 8bit firmware will likely choke on the required command processing rate and introduce stuttering to the print. These incredibly brief pauses allow residual pressure in the extruder to push out some extra plastic, making a little zit on the print. So most slicers automatically decimate curves and output gcode with reduced resolution to lighten the load on the firmware. Problem solved, right?

But there's another issue -- the GRBL motion control algorithms underlying all the major open source 3D printer controllers were designed with lots of shortcuts and hacks to allow 8bit processors to execute fast enough. For example, the basic algorithm only looks at the speed or velocity change at the corner between two segments, and uses that to decide when to decelerate/accelerate along the direction of motion. It does not calculate or consider centripetal/radial acceleration whatsoever. This is a really effective hack when printing boxy, low-res models, but it fails miserably on smooth curves with lots of little segments. The firmware does not detect any appreciable velocity change at the corner of any two nearly-linear segments within the faceted curve, and thus does not slow down for the curve. So complex geometry is effectively printed at constant velocity, with no acceleration.

Printing complex perimeters unaccelerated means the commanded feedrate must be very low to get good quality. Most printers are limited to about 40mm/s or less on complex perimeters, despite being able to run perhaps 80-120mm/s on low-complexity infill before hitting other speed limits.

Between the command processing rate limits and motion planner shortcomings required by low power processors, print speeds must be much lower in practice than is strictly required by the physics and printer hardware. This all comes from 8bit processors. The workarounds and best practices to deal with this problem are so deeply baked into the toolchains and ecosystem that very few people realize there is even a problem. But it's a real limit that can be overcome: a high-speed processor running a more rigorous motion planner could generate higher average print speeds with better print quality.

That said, the ARM-based firmwares are only slowly moving towards more advanced motion planners. This is a big development area right now that is actually driving an upcoming shift away from low-end ARMs like the Cortex M3 towards even faster processors. It's actually not all that hard to max out an 84 MHz Arduino Due by piling on a bunch of firmware features.

The use of 8bit processors also makes printers LOUDER. The biggest consumer of processor time in a typical 8bit printer is the stepper interrupt that fires the step pulses to make the motors move. It is quite typical for >60% of all clock cycles on an Atmega AVR to go to firing step pulses. Because this occurs as an interrupt, other processing tasks that the printer must perform -- like acceleration calculations and heater control -- get squeezed into the brief spaces between stepper interrupt events.

Without careful firmware design, the step pulses will completely "crowd out" other functionality like LCD display updates and acceleration calculations. In order to allow higher motion rates without using all the processor resources, 8bit firmwares have a mode called "step doubling" that fires two (or four, or eight) step pulses per stepper interrupt so that half (or a quarter, or an eighth) as many stepper interrupts can be used to produce the same motion speed. This practice de-bottlenecks the processor, but it causes rougher and louder motor motion because the step pulses are fired in bursts rather than a constant frequency. In effect, the microstepping level of the motor is functionally dropped to a coarser mode when the stepper interrupt fires double or quad steps. So the motors get louder, less precise, and in extreme cases may have problems with resonance.

An interesting side effect is that if you switch a Marlin-based printer from 1/16 microstepping to 1/32 microstepping, and keep the same print speeds, the firmware will simply start step-doubling, dropping your effective microstepping level right back down to 1/16.

ARM-based firmwares also use step doubling, but the allowable step rates are typically ~8 times higher before double/quad stepping is used. That can mean higher speeds and/or smoother motion.

Another issue with 8bit AVRs is the lack of hardware floating point and need to spend many clock cycles on high-precision calculations or handling very large numbers. Delta kinematics, auto-leveling functions, calculating moves with extremely high step counts for large printers, and other advanced functionality all take a lot of clock cycles on an 8bit processor. Poor firmware design or carelessly adding a feature that requires a few extra square roots and trig functions can completely bog down the processor. This kind of feature creep and code bloat has seriously impacted Marlin's performance over time as people ask more and more of the old AVR.

In comparison, a 32bit processor doesn't just have a faster clock and more clock cycles, it is also able to do much more complex math in fewer clock cycles, because it has dedicated hardware functionality that takes care of many of the steps an 8bit processor must do in software.

Do 8bit processors work? Sure, they work surprisingly well for what they are and what we ask of them. But they unquestionably limit the performance and features of modern 3D printers. Even today's current generation of 32bit processors is already being maxed out by high speed printers and math-heavy features. The 8bit processor is already two generations behind what would qualify as a "modern" 3D printer controller.