Elias Bakken has been working on Recore 3D printer control board based on Allwinner A64 processor since 2019 and with revision “A5” of the PCB, Recore is now considered stable and will ship to customers.
But wait? Isn’t Allwinner A64 just a quad-core Cortex-A53 processor meant to run Linux? But 3D printer control boards require real-time I/O and that’s why many are designed with STM32, Arduino compatible Microchip MCU or other microcontrollers. The trick here is that Elias did not use the Cortex-A53 cores for real-time control, but instead the 300 MHz AR100 32-bit OpenRISC 1000 core found in Allwinner A64 SoC.
Recore specifications:
- SoC – Allwinner A64 quad-core Cortex-A53 processor running at 1 GHz, with AR100 32-bit core @ 300 MHz, Mali-400MP2 GPU
- System Memory – 1 GB DDR3 RAM
- Storage – 8 GB eMMC flash
- Video Output – HDMI output to connect a display
- Networking – Gigabit Ethernet
- 3D printer control
- 6x TMC2209 2A stepper motor drivers
- 3x heater outputs + high power heated bed up to 20A
- 4x thermistor/thermocouple inputs (software selectable)
- USB – 4x USB 2.0 ports
Of course, the Cortex-A53 cores are not just sitting here idles, and run Refactor Linux distribution for 3D printers based on Armbian Debian and pre-loaded with Klipper and OctoPrint.
That means Recore is an all-in-one 3D printer board handling real-time control, plus the human-machine interface through, for instance, a touchscreen display (HDMI + USB). The diagram above could also have added a USB webcam for remote monitoring and/or a USB WiFi dongle for wireless connectivity.
That makes it a more compact solution, and probably easier to set up than the typical 3D printer board plus external SBC or TV box with Octoprint. Recore is not 100% open-source hardware, but you can find the PDF schematics, Allwinner binaries, and other files on Github, as well as Refactor distribution on a separate repository. Documentation to get started can be found on the Wiki.
If you’d like to learn more about Elias’ work on AR100 core, check out his recent blog post where he explains how he used the real-time core to toggle the pins much faster and predictably than using Linux, setup UART communication between the Cortex-A53 cores and AR100, and challenges in setting up the timer. If you prefer the explanations in video format, watch the video below.
Recore Linux 3D printer control board is available now and sold for $149 ex VAT and without accessories.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
This board looks like a really good value if you own a good quality printer and want to update its driver.
re: application processor and Linux vs MCU and RTOS:
Using an MCU with fully deterministic clocks per op and counting your clocks to build signals is only necessary when you need extremely low IRQ latency, or extremely low signal response latency. Driving steppers doesn’t require that. OTOH, slicing models and estimating head movement physics so you can print both quickly and accurately, requires more horsepower than a typical MCU. Though there are some damn fast MCUs now.
Most application processors, including A53, are capable of real-time signalling via their DMA engines, and they’re capable of cycle-accurate timings by crafting code to operate entirely within the L1$, or by disabling caches entirely. That’s not a very efficient use of a quad-core application processor though lol. But for a 3D printer I’m sure they could have gotten away with using the DMA engine to generate the head movement signals, and I doubt the feedback signals require truly real-time processing.
Do all A64’s have this OpenRISC core?
Yes, it’s always been there, and on some other Allwinner processors including A31, H3 and all 64-bit processors. See linux-sunxi link in the post for more details.
Small fix – not all 64-bit Allwinner processors has OpenRISC core. H616 doesn’t have it and I think A63 has Cortex M coprocessor.
Wow, I’ve been using the A64 for years and never knew there was an extra core in there. I wonder if this works like the ULP in the ESP32? Can I put the main CPU into deep sleep and leave this core running? It would be useful to watch the radio for specific messages directed to this SOC and then only wake up on a match.
I don’t know about the A64 but for other SoCs the “power management mcu” is in the always on domain or can at least be told to stay on when the main cpu, dram etc are turned off. That way you can have the MCU listen for IR commands etc and then boot the system up. If the MCU has access to stuff like SPI you could have it run something like a LoRa stack and have it wake up the whole system only when action is needed.
Ok, I knew about this. It is full of an Allwinner proprietary blob and I simply ignored it after boot. It is the system management processor.
I believe that’s how the PinePhone operates. The phone wakes up when the real time core receives input from the cellular modem.
https://github.com/crust-firmware/crust
Not aware of this ar100 core. That means we can use things like Nanopi NEO air to control robot … deserve a deeper check !
Thanks for the info.
I’m very skeptical about this. PRUs are much better documented and understood, on top of being designed for tasks like this. They may be 3.3x slower on top step rate, but it’s consistent, proven and does not fall with number of attached devices. If I need to make a smallest board, I can get one of the OSD335x SiPs, If I run out of I/O capacity, there is AM57xx with 2 of the same PRUs and more resources for HMI. Either that or having separate HMI SoC and microcontroller.
PRUs are better documented and understood, but for the task of generating step/dir patterns, it’s not really necessary. It’s nice to have the option to do something similar with Allwinner chips as well.
Can you use this for a cnc router also when you use other software, for example linuxcnc?
LinuxCNC + Orange Pi ARISC driver
Thanks for the link, so linuxCNC also uses the RISC co-processor.
One of the HardKernel engineers, Kim Dongjin has designed the 3DPrinterShield that runs on an off-the-shelf SBC (Odorid-C4 or Odorid-N2+) which only uses the application processor and a RT kernel 5.10. It is the only application processor 3D printer control board that I’ve seen currently that relies on the application processor for everything, all the others have an embedded MCU I believe.
Here’s a link to his project thread. https://forum.odroid.com/viewtopic.php?f=55&t=41057
The new RK3566 SoC embedded a 32-bit RISC-V core 🙂
Originally we had pins so kids could learn wiring. But wires suck, so now we have plugs with pins. But as we know from AMD’s move to LGA, bend or break a pin and ur up a creek. So why would this not apply to this design as well? I think wiring and exposed pins are regressive unless they are instructional classroom tools.