Grbl Ported To The ESP32

If you’re building a CNC or laser, there’s an excellent chance you’ll be using Grbl to get moving. It’s also a pretty safe bet you’d end up running it on some variation of the Arduino sitting in a motor controller breakout board. It’s cheap, easy to setup and use, and effectively the “industry” standard for DIY machines so there’s no shortage of information out there. What’s not to love?

Well, quite a few things in fact. As [bdring] explains, Grbl pushes the capability of the Arduino to the very limit; making it something of a dead-end for future development. Plus the Arduino needs to be plugged into the host computer via USB to function, a rather quaint idea to many in 2018. These were just some of the reasons he decided to port Grbl to the ESP32 board.

Price wise the Arduino and ESP32 are around the same, but the ESP does have the advantage of being much more powerful than the 8-bit Italian Stallion. Its got way more flash and RAM as well, and perhaps most importantly, includes Wi-Fi and Bluetooth out of the box. It still needs to be plugged into a board to hold the motor drivers like the Arduino, but beyond that [bdring] opines the ESP32 is about as close to the perfect Grbl platform as you can get.

[bdring] reports that porting the code over to the ESP32 wasn’t terrible, but it wasn’t exactly a walk in the park either. The bulk of the code went by without too much trouble, but when it came to the parts that needed precise timing things got tricky. The ESP32 makes use of a Real Time Operating System (RTOS) that’s not too happy about giving up control of the hardware. Turning off the RTOS was an option, but that would nuke Bluetooth and Wi-Fi so obviously not an ideal solution. Eventually he figured out how to get interrupts more or less playing nicely with the RTOS, but mentions there’s still some more work to be done before he’s ready to release the firmware to the public.

If you’ve been browsing Hackaday for a while you may remember [bdring]. He’s got a real knack for making things move, and has created a number of fantastic little CNC machines recently which have definitely caught our eye.

[Thanks to Jon and Craig for the tip.]

32 thoughts on “Grbl Ported To The ESP32

      1. This reminds me, is there any effort underway to port/write 3D printer firmware for the ESP32?
        After all, software wise a 3D printer controller is functionally quite similar to a CNC controller.

          1. I’d vager any low or medium speed I/O could be handled with shift registers.
            And display could technically be omitted in favor for the machine hosting a web page with the same info you’d find on a display.

          2. As someone said, it can be made with Shift registers. I made a plotter with the esp12 (esp8266) and almost everything was conected via shift registers. It had a display, servo control, and could be controlled via wifi. Pin number wasnt the problem. The esp32 has more pinout than the esp12, and has double core with would solve some problems i had with the esp12

        1. You need no shift registers, also the I2S in 16-bit synchronous parallel mode port would allow you to output directly without extra logic. It would be better performance across the board with pin control down to 25ns. Not sure why no one’s messed with it.

    1. porting GRBL to ARM is easy, the new version of GRBL sounds to be a lot more than a port with lots of improved features and hardware abstraction to make it easier to port to other processors

    1. Even TI uses FreeRTOS for their driver ecosystem. I like to run without it whenever I can, because an OS gets in the way when you don’t need one, but when you do need one FreeRTOS is usually the right one.

      The problem isn’t even just knowing how to “properly” code an RTOS; the problem is in their conception of the application. WIFI is timing-sensitive. The ESP32 has very limited resources. The application developer isn’t writing their own wifi drivers. Therefore, if you use wifi you don’t have a realtime application. You can reduce the cases where it bites you with lots of fiddling, of course.

      Personally, I don’t mind running two ICs, one for the wifi and GUI, and one for the machine control. And then since the machine control is only doing the one thing, it doesn’t even need an OS. But if I really wanted it on the same chip, I’d probably just shut off the wifi while commands are run, and then turn it back on. The actual start/stop buttons should be hardware buttons anyways for safety.

      1. THIS!
        Try to generate a clean 2 MHZ signal on any ESP32 pin – now try with 8 MHz or more – way within the ESP32’s speed. Just fractions – but contrary to the Arduino you will have a bad time…

  1. My solution was to use an esp32 and an arduino. The esp is used to upload and manage the gcode file. The arduino directly runs the motor controllers. So esp will take the gcode, decode a large section of it, and create a large buffer of moves that it communicates to the arduino via a few pins. The arduino will execute the commands according to the timing given to it. It also communicates back via a buffer of moves it has completed, so the esp32 can display where the CNC is. The dual buffers mean the two do not need to be in sync to operate. They simply “talk” when they get a chance.

  2. “Eventually he figured out how to get interrupts more or less playing nicely with the RTOS, but mentions there’s still some more work to be done before he’s ready to release the firmware to the public.”

    Why not put it on a git and open it up for others to help?

  3. Id rather have the GRBL port to ARM instead. The esp is nice and all and pleasantly inexpensive but in the end ARM processors have a whole lot more grunt and could potentially disrupt the commercial CNC market. Given that there are many different kinds of controllers with different subsets of commands (G-code is standard but each manufacturer extends it with their own subset of special commands), having a controller that is open source could potentially lead to the unification of G-code special commands. This would be amazing and cut down on the total number of posts that are needed as well as the support side of the equation thus adding extra efficency in the manufacturing of any product that requires CNC machining

    1. “Having a controller that is open-source”

      You mean like linuxCNC/EMC2/Machinekit which is err, 18 years old?
      There will be no unification, grbl hobby machines are a tiny fraction of installed CNC base.

      1. “There will be no unification”

        hey can you tell me the lottery numbers for next week? oh you cant? i thought you could tell the future with your statement of certainty that there will be no unification… there might not be any unification as controller manufacturers add their secret sauce to make their controllers perform better but all it takes is an open source solution to provide equal or better performance for the CNC manufacturers to start using it. An arm based open source controller would have the potential to create a scenario for some unification, which has efficiency benefits throughout the entire process of commercial CNC manufacturing. But hey, maybe I’m just an idealist trying to figure out a solution that would benefit many people and solve a lot of headaches. Maybe i should have stated that having the RIGHT controller that is open sourced, but i didn’t expect someone to be so pedantic about my comment.

        After-all, if people never tried to improve or refine processes/products we wouldn’t have the world we have today or half of the chips we have today, the 486 would have been just fine, right?

  4. Using I2S would be a way better option for the ESP32. It will happily do 2 channels @ 32bit and 192khz per I2S port. Hook that up to a 32bit shift register and you can drive 16 steppers at 384khz and no jitter if you keep the buffers full. I’ve done something similar using the ESP32 to drive an I2S DAC to do motion control for laser galvos. The ESP doesn’t break a sweat without any tweaking at all.

    Similar project on the 8266 here –

  5. I don’t understand why this is a difficult problem. The ESP 32 has two separate CPUs, designed with user real time tasking in mind from its onset. Couldn’t he just put all of his real time code on one of the CPUs and let the other one do the Wi-Fi?

    Years ago, before the ESP was even a twinkle in anyone’s eye, I Built a trapezoidal motion controller with PID encoder feedback to drive 3 phase BLDC all in hardware, in an FPGA. Unfortunately I did it for money and I can’t rightfully open source it without permission of the company I did it for. If there is any interest I could redevelop project and put it out there… But with today’s cheap and powerful CPUs it is probably not a sensible way to go anymore.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.