This project has been on hold for a bit, as I've been dedicating my time to a project to enable this one (and others).

---

(Update 7-11-16: We Have PIC32 Functionality!

Next step--since I don't have stepper-drivers with Step/Dir inputs--to implement microstepped PWM-output directly, as a compilation-option)

---

The original #sdramThing4.5 "Logic Analyzer" was built on perf-board with point-to-point wiring to enable easy modification during the various prototyping phases. That worked well for that project, but now that its concepts are well-established (and to be used in this project), that point-to-point wiring is a bit of a hindrance. The noise and delays associated with that ratsnest is surely largely responsible for the speed-limitations of the original sdramThing.

Thus, it's time for PCBs, and I've been working on my implementation of #Mini PCB printer in the meantime. As supplies are lacking, I've opted, in the process, to port grbl--the widely-known/used G-Code-receiving CNC-machine controller designed around AVRs--to the architecture I have available (PIC32), and in-so-doing am completely abstracting grbl's hardware-interfacing code such that it should be comparatively easy to then port it to nearly any other architecture with minimal (if any) impact on speed (e.g. not using functions like digital_write() which would slow pin-toggling dramatically).

So far all hardware-related code has been abstracted, excluding the eeprom-storage which is used for storing constant-data such as the steps/inch ratios (which really don't change so often, so might be easy-enough to just hard-code). Completed hardware-abstractions include Serial I/O, step/dir (and other) pin-toggling, timer-interrupts, pwm, limit-switches, control-panel buttons, etc. But, again, the intent was to keep grbl's functional-code's interface with these peripherals as true to the original as possible. (grbl is well-established at this point, no sense in risking introducing new bugs!).

So far, (again, the only exclusion to the completion of its abstraction being the eeprom) the result is that grbl still compiles byte-for-byte identical to the original (when chosen to compile for the original atmega328p), meaning, of course, that there has been zero effect on the functionality (most-importantly *speed*) of the system, while, still, completely abstracting the core functionality's source-code from its hardware-implementation.

My search-fu apparently failed before starting this endeavor, as I've recently come across another's similar work, porting grbl to a TI chip, but attempting to (as I am dedicating this endeavor to) make all those changes architecture-agnostic--again, for the sake of making it easier for others to port to different systems/architectures. In the process, I've also added the ability to choose your target-architecture in the Makefile, and it automatically handles inclusion/compilation of the appropriate architecture-specific code.

https://github.com/grbl/grbl/issues/1030

---------

So, as always, my projects seem to feed into each other... one's put on hold to develop another "tool" to enable it, which becomes a project in and of itself, but once that tool is functional, generally, a return to the project which inspired it.