Hey !
Thanks for dropping by.
I was indeed comparing the “old” tinyG, not G2, to Smoothie, a year ago. I haven’t read G2’s code yet.
I was also comparing the Smoothieboard hardware your XMega board from the time.
And I did admit I’m not a TinyG specialist, I just looked at the hardware specs, and read most of the code.
Obviously you can run TinyG on more than one board, and with more than one type of driver, same with Smoothie.
About the code by the way, I found it much harder to read and understand than GRBL’s. It’s obviously in part because you are doing much more complex work there, and it also looks very optimized, but in GRBL there is a very obvious attempt at making it -extremely- readable ( which we try to emulate in Smoothie ), which I found to be lacking.
That’s been limiting how much of TinyG’s neatness we’ve been able to port into Smoothie.
For example recently Jim Morris has been implementing per-step acceleration and time-based acceleration math into Smoothie. It was a great opportunity to implement S-curve too, but we didn’t find TinyG’s code helpful enough there. Doing all that work from scratch instead of emulating what you do, is obviously much more work, so it’s been put aside for now.
We are also finding limitations with the GRBL concept of junction_deviation, and I’m pretty sure what you do is better there, so again it’d be great if it was easier to port things over.
Smoothie firmware is all about the modular stuff, being able to do many things with one firmware, and making it as easy as possible for people to contribute. Aside for that key thing, there is nothing in the code which I’m really attached to, so anything that’s better than what we have now, we want to come in.
I have not read G2 yet, I hope I’ll have time soon. I hope it’ll be easier to read, but if it’s not, my personal wish is you’d make it so. I’ve found that documentation, both of the code and of the usage, are really key to making this kind of project go forward.
There are some pretty awesome projects around ( my eyes turn to MachineKit/LinuxCNC ) that really suffer a lot from lacking documentation.
I think we make Open-Source code specifically so that people can use it to make awesomer things than what we originally did, and making it easy for code to cross-polinate across projects would in my opinion make for generally increased awesomess for everybody 
We code things in a different fashion, so I don’t think we’d port TinyG code directly to Smoothie, or that you’d do the opposite, but code is documentation, and well commented code makes it much easier to implement things in a different firmware.
That was my tiny rant, after reading the TinyG code, I had a strong wish that it’d be easier to understand I know coding with understandability in mind is slower and is more work, and is often done at the expense of optimisation, so if you are not ready to do that, I’d also be glad to chat with you about your code, maybe you can help me understand it better ( maybe I’m just missing a few key things. GRBL was great at explaining key things ).
I don’t actually code Smoothie anymore, we have awesome people doing that much better than I did, now I’m mostly helping people get familiar with the codebase so that it’s easier for them to contribute. So if I understood what TinyG does better, I’d probably be able to help some people implement your ideas into Smoothie.
Cheers