So G Code is dumb, luckily FlatCAM outputs G Code that makes sense to me. Instead of having a whole line of commands, that need to be interpretted in a different order then the order recieved, it just sends one command at a time which is easy to interpret on an Arduino, dont need to worry about loading the entire line, and then picking through and running stuff in different orders.

The firmware is real simple, theres a 128 byte line buffer that reads in until it gets a carriage return or line feed, once it hits that, it goes to an interpret routine which runs through and if it sees what I call a word (X,Y,Z,F,P) it will read in a real number, and store that in its associated variable. If it sees a G, it will read in an integer, then read for words, and then execute that command. If it sees an M, then it currently just ignores it and continues interpreting the line. If it sees an error, then it will update an error flag variable, and then output "error: <description here>", to let the operator know whats up. If it doesnt see an error, after interpreting it will output "ready" telling the sending program it can send the next line.

I implemented an actual bresenham line algorithm using longs instead of floats to make the routine quicker and easier to implement fairly accurate feed rates. The only real issue is when the Z axis is the dominant axis since it has 400 steps per mm versus the X/Y which only has 80 steps per mm. With that, if the Z axis has to step 400 times, and the X axis has to step 400 times, the X axis would need a longer minimum delay time between steps then the Z axis or else the motor will stall, words suck and I dont want to put in the effort to make my brain thoughts into them.

So far it supports G0, G1, G4, G20, G21, G90, G91, G93, G94. It'll read the M commands and just ignores them, but the only M commands I find that flatcam outputs is like spindle on and shit like that, and since Im using a manually operated dremel, thats no issue.

For developing, I've made all the locals static to get a better idea of how much RAM I'm using, which is only 429 bytes out of 2048, which leaves plenty on the stack for parameters and return addresses. And its only using 30% of the program memory, so I still got plenty of space for adding other shit to it.

Ima make the program that sends g code files to the controller a little fancier and then do some test cuts. I'm pretty happy with it so far.

EDIT: I did a quick tape-a-pen-to-the-dremel-carriage-and-tape-a-notepad-to-the-y-carriage test, and it looks pretty good. I stopped it during the drill hole phase and sent it back to 0,0,0, hence the line through it all.

versus the flatcam expected