Teacup_Firmware VS Smoothieware

Ooh another fun one you may be interested in is how I wrote Teacup's config handling - the user has to provide a config.h with various macros defining their machine setup, and then multiple separate parts of the codebase redefine those macros and re-include the file to build various structures and constants at compile-time

Since then I've made lots of things like audio amplifiers and effects, motor controllers, 3d printer controllers and firmware (and subsequently smoothieboard), muscle stimulators, bluetooth LED strip controllers, etc

Teacup can go pretty fast too, I think I've seen it clocked at 48k @ 20MHz although that may have been across 4 motors at once.

See here and here for an example from my ESC project, or this example from Teacup

https://www.airspayce.com/mikem/arduino/AccelStepper/classAccelStepper.html says "The fastest motor speed that can be reliably supported is about 4000 steps per second at a clock frequency of 16 MHz on Arduino" which is pretty poor - teacup can hit something like 10× that when controlling 4 steppers, and also comes with a non-blocking state machine based gcode parser ;)

Teacup had decent performance last time I checked, but it's more a complete firmware project rather than a library.

That's hard enough just with linear acceleration let alone complex functions - might be worth converting it to line segments host-side and just streaming basic gcode to a 3D printer firmware over the serial port.

Last time I checked, Teacup can do something like 40kHz on an atmega - might be worth having a play with that?

AccelStepper may interest you, and I think Teacup can go even faster.

The latest what? Teacup? Marlin? Aprinter? Repetier? GRBL? Something else?

I originally wrote Teacup because I was horrified at numerous aspects of the state of other 3d printer firmware codebases available, but after a few years I became far more interested in Smoothie and officially relinquished leadership of Teacup to Traumflug who'd been doing far more work on it than me at the time

Also, Windows' USB stack is a complete dumpster fire - in Linux your thing just needs to say "hi I've got camera interfaces" in the device descriptor and you're mostly good to go, but Windows needs actual driver development, or at least a magic text file to tell it to use its preinstalled drivers.

Fwiw I wrote the runtime descriptor construction code for smoothie which is how I know it's possible - and yet even after a decade, I don't see any other firmware libraries with similar descriptor construction mechanisms which is sad.

Smoothie has a dynamic device descriptor, and adding an extra serial port via config setting is a fairly reliable way to bluescreen windows.

There's a few forum threads around (eg this one regarding the Teensy arduino core), but I haven't seen any firmware stacks with the dynamic USB descriptor initialization and endpoint allocation you'd need for runtime custom USB function sets other than the one I wrote for Smoothie a decade ago.

PS: USB in a nutshell is a great read if you're planning to work with USB firmware stacks - was super helpful when I was massaging Smoothie's USB stack

Bizarrely however, you need a magic text file to convince windows to actually use it with a particular device - despite the fact that USB was specifically designed for this to be entirely unnecessary as devices must describe themselves to the host on connect and there are many standardized interface patterns.

I've been thinking of creating a 3D printer to print buildings or maybe a CNC machine for milling lumber out of these trees. I've got an upper-end Smoothieboard so I could do that.

I've been fairly happy with Smoothieware http://smoothieware.org