# Porting grbl and upgraded non arduino micros **URL:** \ **Category:** Software\ **Tags:** firmware, 32-bit, maslow-micro\ **Created:** [February 2, 2020, 1:58am UTC](https://forums.maslowcnc.com/t/porting-grbl-and-upgraded-non-arduino-micros/12289 "2020-02-02T01:58:08Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Orob](https://yyz1.discourse-cdn.com/flex031/user_avatar/forums.maslowcnc.com/orob/32/16344_2.png) [@Orob](https://forums.maslowcnc.com/u/Orob)\ **Post date:** [February 2, 2020, 1:58am UTC](https://forums.maslowcnc.com/t/porting-grbl-and-upgraded-non-arduino-micros/12289/1 "2020-02-02T01:58:08Z")
I’ve been reading more… so addictive. With it being cold and my garage heater not quite good enough even with the insulation I added to the garage, I’m not cutting right now and this is just talk. With that in mind, I’ve been reading up on the arduino used to control the maslow. It sounds like an upgrade to a 32 bit processor would be a great thing. I’m thinking a 12-18 tooth sprocket on the motors would also be a great thing, but I’d settle for speed ramping first if only one was possible and that is straying from the software side of this anyway. To that end, I have read some posts about grbl compliance and such. I read @slomobile’s [posts](https://forums.maslowcnc.com/t/firmware-wishlist/4413/18) on commenting and rebuilding the source to help make it modular as well as the desire to upgrade from the mega. I have had success with using cypress psoc devices and I was wondering if anyone had considered porting to a psoc 5 (arm M3 80 MHz, with more flash and eeprom than the mega) or a psoc 6 (150 MHz). Upon thinking that, I found [someone who ported grbl 1.1 to a psoc 5](http://www.buildlog.net/blog/2017/02/psoc-5-port-of-the-grbl-1-1-cnc-controller/). Would the psoc be of interest for maslow or are we dedicated to arduino and the shield form factor? Psoc 5 has 12 bit DAC and ADC built in and you can put it on any pin as well as a host of digital and analog modules that can be place and arranged like an fpga to get the desire functionality. It certainly isn’t an arduino. For $15 a dev kit / proto kit (psoc5) comes with a USB/serial programmer and can be detached and deployed or the USB can be used similar to the arduino serial connection, though the USB serial is not speed limited to 115200 because it is a USB simulated serial port. The psoc6 kit is $20 and has native bluetooth, which could be used with a phone for calibration. This seems like a reasonable upgrade that could potentially host the calibration features onboard. The sparkfun freesock would be pin compatible, but is pricy, so it can be done. Now that I have finished most of those posts, it seems there is desire for modest improvements, but not major overhauls. I’m interested in more speed… without the $5000, but I guess I pay it in time or pay it in cash, either way it gets paid. ---
**Author:** ![bar](https://yyz1.discourse-cdn.com/flex031/user_avatar/forums.maslowcnc.com/bar/32/10_2.png) [@bar](https://forums.maslowcnc.com/u/bar)\ **Post date:** [February 2, 2020, 2:37am UTC](https://forums.maslowcnc.com/t/porting-grbl-and-upgraded-non-arduino-micros/12289/2 "2020-02-02T02:37:12Z")
This is absolutly something on my long term roadmap. I’m thinking the ESP32 is the ideal target. There is a port of GRBL [to the ESP32 here](https://github.com/bdring/Grbl_Esp32) which looks great and is actively maintained. The dream would be a modified version of Webcontrol running directly on the ESP32. I’ve been working on a redesigned controller board which you can read about here: > [@Thoughts on designing a new controller](https://forums.maslowcnc.com/t/thoughts-on-designing-a-new-controller/10453): > > I really like the idea of Web Ground Control and I absolutely think something like that is the future. I would like to start designing a controller specifically to work with Web Ground Control. CNCs using stepper motors are VERY sensitive to timing because the motors require precise and high frequency pulses to move. A closed loop system like ours should be a lot more forgiving about timing (especially if the processor is much faster than the motors) so I think we may be able to get rid of the … Progress is slow right now because Create is my main focus, but I would absolutely love any help that anyone can offer. ---
**Author:** ![dlang](https://yyz1.discourse-cdn.com/flex031/user_avatar/forums.maslowcnc.com/dlang/32/859_2.png) [@dlang](https://forums.maslowcnc.com/u/dlang)\ **Post date:** [February 2, 2020, 9:52am UTC](https://forums.maslowcnc.com/t/porting-grbl-and-upgraded-non-arduino-micros/12289/3 "2020-02-02T09:52:34Z")
workneeds to be done on grbl before it could manage a maslow 1. the maslow uses DC motors and encoders while grbl is built around steppers. Someone would need to create a varient that could handle the DC motor/encoder setup (which uses PID loops to adjust the speeds of the motors) This should be useful to non-maslow grbl users. 1. grbl does cartesian and corexy kinematics (motion models), the maslow has very different motion, so the calculations are significantly different. This can be done, there is a post of someone who has dont at least much of the work but it needs to be checked and see if it can get into the upstream grbl (as a compile time option, not a runtime option just due to space limits on the arduino) on a more powerful board, it should be possible to have both motor types as an option. David Lang ---
**Author:** ![madgrizzle](https://yyz1.discourse-cdn.com/flex031/user_avatar/forums.maslowcnc.com/madgrizzle/32/1372_2.png) [@madgrizzle](https://forums.maslowcnc.com/u/madgrizzle)\ **Post date:** [February 2, 2020, 4:39pm UTC](https://forums.maslowcnc.com/t/porting-grbl-and-upgraded-non-arduino-micros/12289/4 "2020-02-02T16:39:36Z")
There’s another cnc firmware that’s just recently posted about that’s more abstracted than grbl… seems to be designed to be flexible through hardware abstraction layers (HAL). It’s currently limited to stepper motors, so that’s a challenge that would have to be overcome… just like @ldocull did with grbl. Modular library based: - Independent hardware. All MCU/hardware operations are written in a single translation unit that acts like a standardized HAL interface, leaving the CNC controlling code independent of the MCU architecture has long has it has the necessary abilities to execute code and respond to interrupts in a predictable. Porting µCNC for a different MCU should be fairly straight forward. - Independent kinematics. Another dimension of the HAL is the possibility of defining how the translation between machine coordinates and the motions is translated back and forth. This should theoretically allow µCNC to be easily adaptable to several types of machines like cartesian, corexy, deltas and others. µCNC supports up to 6 axis. > **[Paciente8159/uCNC](https://github.com/Paciente8159/uCNC)** > > µCNC - A universal CNC firmware for microcontrollers - Paciente8159/uCNC .