ultrasonic-poc VS Smoothieware

That's why I don't use them for anything fancy

Heh, ultrasonic phase offset can be done with an Arduino's analog comparator (NOT the ADC which is too slow) - here's one I prepared earlier

hackaday.com has a zillion links to examples; here's one two three four of mine and I've also got a laundry list of companies I've helped but whose technical details I can't legally publish (note that I've assisted many but not all of the companies in that link)

HC-SR04 can't, but the transducers on it can - here's a proof-of-concept I threw together a while ago to play with them, although you may want a capacitor in series with R6 if you want it to work over longer distances than ~10cm or so

PS: https://github.com/triffid/ultrasonic-poc may interest you ;)

If you're curious here's a couple of my AVR projects (not using Arduino libraries at all), and here's an NRF52 one

ChatGPT often gets stuff wrong and likely can't handle more advanced programming techniques (eg this sort of thing), so it's only going to be useful for basic stuff and shouldn't be used beyond your ability to critically analyze or debug code.

Does this proof of concept where I get absurd precision (at short range) from a couple ultrasonic transducers salvaged from a HC-SR04 and a few resistors count?

Here's a random proof-of-concept I threw together a while ago for super precise ultrasonic wind speed measurement (or very short distances) - it uses the analog comparator plugged into timer input compare for phase analysis, which is where the precision comes from.

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