Most electronics use micro-controllers like an AVR, but I'm seeing ARM chips in new electronics. ARM chips are said to be more powerful, but in what areas related to 3D printing could this help? What are the features that the AVR struggles with and where an ARM could be better?
High Speed movement? Delta printers? Graphic display?
And is the AVR really the limitation there?
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:
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.
Generally, AVR is in fact less powerful than many ARM cores used today. Most printers with AVRs don't have floating-point coprocessors, although a lot of the step and movement control can be done in integer-only math (except for G2/G3). Marlin can interrupt for step handling up to 10000 times per second on AVR, translating to 40000 steps per second. This isn't particularly useful without mechanical components that can move at those speeds and still print meaningful results (or are far more precise and have a far higher step-count-per-mm at a similar speed).
Graphic display isn't a particularly taxing thing to do at low speeds--high speeds or weird interfaces might require a bit more power or a dedicated interrupt.
The times when ARM might be important are for more math-heavy and especially floating-point-heavy setups such as delta, where every move requires many floating-point and trig operations, and navigation in menus on a 16MHz AVR (atmega2560) is described as "painfully slow", but Marlin does succeed in printing meaningful results on delta-style printers.
Clearly, an ARM core that is either faster at performing soft floating-point, or supports hardfloat (hardware that does floating point operations very efficiently) will see a benefit for such processes.
Generally, microcontrollers such as the AVR are single core / single threaded - so while working in a while loop to run the motor controller, you might be lacking resources to do anything else, like navigate a menu efficiently.
Many ARM processors now a days are multi core / multi threaded, meaning that you can have one thread working your print, while another is free for whatever else the user may want to do.
i.e. Any AVR processor running a local webserver to allow remote access to the printer would be painfully basic, where ARM would generally allow for much more flexibility.
AVR processor has sufficient performance for standard printing. But it lacks performance for
Comparison of technical specs should be self explaining. This particular ARM CPU is at least 10x faster opposite to ATmega2560:
AVR processors are 8 bit - thus they can only fetch data from memory 8 bits at a time - while an ARM is 32 bit and can fetch data 32 bits at a time. Position resolution requires a 24 bit value minimum - this means the AVR takes 3 data fetches for the position - whereas the ARM takes 1 data fetch.
Worse still, AVR processors internally divide the clock by 3, so that a 40 MHz AVR is running at 13.3 MHz typically, while an ARM is 1 clock cycle per bus transaction and instruction processing - this includes a 32 bit by 32 bit multiple in 1 clock cycle.
The memory map on ARM processors is 32 bit wide or 4 GB while 8 bit processors only have an address bus of 16 bits or 64 KB - which means that bank switching comes into play on any program over 64 KB - this takes instructions and time to be done - while with the ARM this is not an issue.
The cost aspects is about the same as AVRs - it just requires redesigned firmware.
As for FPGAs:
The result of adding a FPGA to a AVR will cost a lot more than going to a more powerful ARM processor.
