ESP32/S2/S3 LinuxCNC Controller (6 axis hardware step gen), USB plug-and-play

Goal was to create a project that almost anyone can develop or contribute to and keep it open.
As that is a core requirement and for development speed I decided to use the Arduino frameworks.

Plenty of bare metal programming experience and as well as using idf SDK but that would cause headaches for some and I know LinuxCNC is full of tinkerers!

Arduino framework has certainly presented some challenges too but knowing that it's possible to rapidly develop something that is reliable, performs and is multi-platform in two-three weeks as a single contributor - it pretty much had to be Arduino.

It's somewhat rough round the edges so far, developed very iteratively but it does work. There's a few bugs that I have recently fixed and will be pushed soon.
Prefer to work in smaller increments but I have limited time and many distractions at the moment so it's easier to release in a more offline sprint style, at least for now.

Overall presentation, setup guides, contribution docs and setup will be updated in time.
Ultimately it's board agnostic firmware and configurable at runtime.

Initial USB release for S2 is coming soon. S3 is WIP.
USB requires Arduino as a component in IDF for the custom USB Net driver. Will likely port ESP32 over to that too to allow for sdkconfig specific optimisations to LWIP for lower latencies.

There are plenty of improvements that can and should be done longer term to maximise available resources for any future features, as usual.

github.com/wezhunter/ESP32_LinuxCNC_MotionController_RealTime

Interesting. I had a whole different vision for linuxcnc, and it doesn't include 'thinkers' and other bugineers (no offence to the makers). I was under the impression (hopeful?) that you were planning to maintain a professionally engineered solution of which exploits the core capabilities of espressif's. This unfortunately involves bare metal... just can't see it happening using the thick APIs tbh. Unless ofc you are trying to re-do what many already did...

Arduino; aw come on now man. I'm already having a hard time picturing folks running their several thousand dollar worth machine-tools on some crappy random linuxboxes and all sort of fpgas, please don't make it worst. The espressif Arduino SDK is for flashing LEDs and driving buttons...

An attribute that stands out worlds better than any other I've seen so far is... your attitude. Skills also, judging from the code base I've quickly seen on your g'hub. On the positive side! Be you I'd own the project entirely and toss out the whatever tinkers out of it..... ..... .... And engineer a LINUXCNC proper package, which is what the community needs. (my 2c)

I hear you completely and thanks for the kind words.

Nothing says I'm not going to be moving over to idf only at some point in the future, if required. Dev of this has been about speed to prove it's possible.

Arduino libs can be fine just as long as you know them intimately and all their edge cases which takes experience. They get a bad rap, for justified reasons.

I know once I've done with optimisations and have a controlled build environment I think you'll be surprised.

Take a look at the Tasmota project - based on Arduino. I've 30 of them dotted around and they are absolutely rock solid. Yes use-case matters but I've completed low latency work for other critical applications (that I can't share) and performs excellently (even compared to a raw IDF project) - key part is knowing the libs, being very very selective and optimise. It saves a lot of time and effort.

EDIT: mixing IDF and Arduino is the key part. Arduino framework can run as a native IDF component which gives the best of all options. Bare metal access, IDF optimisations, selected Arduino libs. Ease of codebase management
 

Not that I have much experience with the SDKs myself, and so take what I say with a grain. All I know for certain is the applications that I had to rig for myself (and/or few commercial) all required the tech doc and lowlevel for timings to 'sort of' checkout. Let alone half-data-integrity using those closed source ICs. No f'kin way I've ever managed to accomplish half-precision using those thick layers. By any means call me a noob, or maybe me oscope's gone bad or need calibration, dunno... 

Regardless. You took it to the next level from what I've seen. Respect for that. Subscribed! 
 

Yeah your absolutely right, it's just that things really have evolved so much over the years which I've been fortunate enough to have been able to stay up-to-date with intimately.

Really can mix everything together now but approach and execution is what's crucial.

Just as an example, take a look at FastAccellStepper library - uses RMT peripheral registers directly but it's wrapped in a nice Arduino lib but uses IDF.
It performs very very well. Can likely be improved further to eek out higher pps than 200khz total via RMT. Which may explore in future if it's actually required...

Using Arduino frameworks to take care of the non-time-critical aspects such as config, setup, webui and logging and go deep on the raw time critical components such as motion, IO interrupts and networking/USB. All of those can be drivers or components as a modular architecture within the build system.

Firmware flash sizes can be reduced by removing lots of unnessecary components.

Designing a solution that's both feature rich and reliable would take a very very long time otherwise (10x at least). If used pure IDF then the codebase becomes an abstract nightmare for future maintainers and also requires specific skillsets, sure, little knowledge is dangerous but if rationale is documented in code properly then helps mitigate that risk somewhat.

Longer term, reliable, well documented is important.

Once it's at a state where people see it running on a machine with torture tests and the full feature-set then I think it'll convince you

I will be designing and selling professional EMI complaint boards in the future.
Can't do everything for free.

I've developed a UHF RFID (EPC GEN2) solution using ESP32-S3 via some proprietary asics and RF frontends and so forth so EMI isn't going to be an issue!
Rick Hartley is a board design legend and recommend his lectures to anyone

I'm already convinced, don't get me wrong. Seen it running and scoped at 40'ish khertzies on your vid. Blew my mind half in fact (a ten bucks IC, imagine). Also fully aware you are at the proof of concept phase and seeking advice on how to take it to the next level - a low cost, widely available and effective solution that is.

Knowing all that I can't help but to stick to what I've advised already; leave the thinkers aside. They'll slow both you and the project all together. Don't ask how I know...

"Optimization" Love that word!! Sounds so good, not sure why.