(Update: Adding this link: https://github.com/ericwazhung/grbl-abstracted/tree/master)

So, nowhere in these logs is information about using grbl...

Over the past countless weeks I've been working up to using grbl... Why so long? Well, for one I don't have any unused AVRs with enough pins/memory to load it on. So I've been working on porting it to my PIC32s.... And today I've accomplished motion, for the first time... more on that later.

If you don't know what grbl is, as, believe it or not, I didn't only a few months ago...

grbl is software you can run on a microcontroller to accept G-code (CNC commands) sent from a computer, and convert that into motion via stepper-motors.

As I recall, back in the day, using G-Code to control a CNC-machine meant running a Real-Time Operating-System (such as RT-Linux). So, I guess, what makes grbl special is that it offloads the realtime aspects of the motion-control to a microcontroller (usually an AVR), then the host-computer only needs to send high-level motion-commands (e.g. "move to a point") via serial-port whenever there's enough buffer-space on the receiver. No real-time stuff necessary... run it from any computer with a serial-port, or USB-to-serial converter.

The cool thing, I guess, is that it's *really well supported*. I mean, seriously, check out this page: https://github.com/grbl/grbl/wiki/Using-Grbl

OK, that's that.

There're some things I've learned along the way, the hard way, that I haven't seen explicitly-stated elsewhere... e.g. the limit-pins don't seem to have any effect unless you *enable* them, so if you don't [have the knowhow/patience/pins to] wire-'em-up, you can still get a system running likely without even having to modify the code...

So, notes like these, I wouldn't mind being written-up somewhere. (if someone knows a link, by all means, lemme know and save me the trouble!)

Alright, so I've been working on porting grbl to my PIC32s.... And today I've accomplished motion, for the first time.

So here's some big TODONEs:

Hardware-Abstraction

Everything other than the EEPROM has been abstracted to the point of macros and function-calls that can be written for nearly any architecture... I've obviously done it for PIC32, and the original AVR code has been moved to *_avr.c/h files. The architecture can now be selected in the Makefile, and it will include/compile the *_<architecture>.c/h files as appropriate.

EEPROM/No-EEPROM

The EEPROM stuff is, frankly, a bit excessive... It's easy to do on devices (like an AVR) with an EEPROM built-in, but many microcontrollers don't have it. One alternative is to implement it in FLASH (read/write an unused portion of program-memory). That's doable on most architectures these days, but it is *very* architecture-specific, and I didn't have the patience to do it for PIC32. Another alternative is to use I2C or SPI EEPROM chips... Again, pretty hardware-specific. Could easily be done, but wasn't within my patience-level. The Alternative I chose was to make an option for NO_EEPROM. In this case the system acts as though it's brand-new/unconfigured, thus using default/hard-coded values, each time it's booted. OMG... 'cause, frankly, most people probably don't change those settings anyhow. And, they can easily be changed in a source-file if necessary.

Byte-Identical!

Despite all the above hardware-abstraction functions/macros, it can still be configured to compile BYTE-FOR-BYTE identical to the original grbl-master compilation. This is KEY, as, as I understand, grbl has been *well* supported for quite some time. Doing all this hardware-abstraction results in *zero* changes to the original functionality... Even additional function-calls would result in changes in terms of context-switching, pushing/popping the stack, etc. This configuration-option shows that even despite *all* the hardware-abstraction, there's NO CHANGE to functionality, speed or otherwise. And, thus, it's easy to see what changes have been made, (when the Byte-Identical test is disabled) in order to debug, if necessary, when implementing new architectures.

NEW FUNCTIONALITY:

PHASE-OUTPUT:

Rather than outputting Step/Direction signals, those pins can now be used as PHASE-outputs, to directly-drive H-bridges which in turn directly-drive the stepper motors. This is a relatively minor change... If it weren't an add-on, it would probably require *less* resources than the step/dir outputs. But, in keeping with the knowledge that grbl has been known-functional for quite some time, it makes sense to add this as a sort of additional (software) "peripheral" atop the already-functional code.

PHASE-OUTPUT + MICROSTEPPING:

The next step, after that, is microstepping. If your microcontroller has enough PWM pins, it's only a small step to add direct control of H-Bridges WITH microstepping (via PWM). This is, obviously, implemented for PIC32.

So, as it stands, I've a PIC32MX170F256B, which has a sum-total of 28 pins... it's a bit short as far as running a Z-axis, but it's plenty for a 2-axis/laser/router system. And... it's running! With microstepping... and no "easy-steppers," just some old dual-H-bridge chips extracted from some floppy drives.

https://github.com/ericwazhung/grbl-abstracted/tree/master

More to come, I'm sure... It gets a bit wonky, as this "project" is relevant to so many others I'm working on, so notes might end up in those logs instead....