Recently I discovered a relatively new system on a chip ESP32. It has 2 cores up to 240 MHz each. It also has more then 40 available GPIO pins. And its cheap! and it has WiFi!!!
Ever since I’m thinking if it’s feasible to implemented a 3d printer controller on this chip. It should be pretty straightforward to implement all system and low priority tasks on one core and hard realtime motor control on the second core.
It even should be pretty easy to adapt some RAPMS-type boards to work with the ESP32.
Do you think the chip has enough raw horsepower to control a delta-type printer?
If the device has good support for being programmed as a bare-metal device I would say yes.
A lot of SoC devices are targeted at running an operating system like Android or GNU/Linux. This can lose a lot of realtime performance in the interests of convenience.
There are lots of ARM devices with similar specifications in terms of cores, speed and I/O (the NXP LPC4355 is one example) which might be a better choice for a 3D printer controller.
@Neil_Darlow
Thanks for your comment. No doubt there are chips that suit a printer much better.
The interesting part about ESP32 is that it is less then 10$ for the ready to use board. Just hook up sensors and motor drivers and that’s all.
In case of LPC4355 you have to develop the board yourself. It’s far too complex for non-professionals like me.
I’ve used the precursor device to the ESP32, the ESP8266. In fact, I’ve installed FreeRTOS on it - check out the ESP8266 community, there are a lot of people doing cool things with it. The ESP8266 can be bought as a module for only $1.70 including shipping…
@Philip_Money_Mongoos
The problem with esp8266 is it’s single core. You won’t get hard realtime if you want to use FreeRTOS, WiFi and that sort of things. At least it would be not as easy as on a double-core when you can have full control over one of the cores. That is the very point that made me write the post
I wonder if smoothie could be ported to it…
@Anatoly_Makarevich : I was just pointing to the ESP8266 so that you can look at the resources as there is a lot more information and resources on this chip than the ESP32 which is still under development.
@Philip_Money_Mongoos
That is a good point. That means the ESP32 is being developed as successor to the already successful ESP8266 chip.
PS. I mean there is already a solid community behind these chips.
The problem isn’t necessarily the chip. Even if you have the IC to do the processing, you still need all the peripherals. It’s far from hooking up pins to each pad on the ESP. An LPC1768 at 100mhz can be had for around $5 but you need a ton of parts to get it to actually function. I have been wanting to see an implementation of using the ESP12E in conjunction with the current Smoothieware compatible electronics with a nice polished web interface. Those are $1.7. That’s similar to how duet does it.
@Griffin_Paquette
My idea is to get ESP32 board and wire it up to a RAMPS board (or something) which are dirt cheap.
That’s virtually all you need on the electornics side. Of cource you also need the software but this is another story.
I’m not familiar with RAMPS and don’t know how many IOs you need. The main limitation on the ESP chips are the number of available IO pins
@Neil_Darlow you can program them easily writing in C and using a GCC compiler
@Philip_Money_Mongoos
I may be wrong. Wild guess is we definitely need 2 pins per stepper motor (step + dir). Plus pins for reading temperature, starting fans and heaters. Say 20 pins in total. This is what ESP provides out of the box.
And you always have an option for GPIO pin extender.
Is there anything obviously wrong in the above?
@David_Sherwood
Good board indeed.
Although it is 1GHz its single core. Consequently you won’t have real time capabilities. Again at least not in an easy way
Porting bare-metal firmware and programming two cores to split realtime and non-realtime tasks isn’t exactly a trivial programming task here. 3D printer motion control code is complex… even with all the different firmwares out there today, practically everyone is running essentially the same GRBL-derived core motion algorithms, because it’s insanely difficult to work on.
Realtime code has been done on single core processors for something like 50+ years now, on far slower CPUs. Not really a problem