LinuxCNC EMC Port to FreeRTOS? Curious...

Just woken up. You meant having a Linuxcnc implementation for the xtensa and/or risc-v? Should have picked this up since you're all-in mcu... my bad. Regardless, methink this imply renaming the project, something like EspressifCNC™

ps don't forget that mandatory 10ms delay in that freeRTos task loop ~watchdog

FreeRTOS is targeted for embedded systems only, simulators exist for Linux so as the post states "FreeRTOS port" there would be no reason to suggest I was thinking of running it on anything other than an MCU...?

Yeah maybe a rename might be in order but its a massive effort nonetheless...

I know I've not done a great job at explaining the benefits it would likely bring, realistically one "advantage" is it would in essence be industrialising a version LCNC core since it then runs of proprietary hardware with tuned peripherals.

Is it needed, no. Does it improve setup and arguably stability in set environments, yes. Reduces hardware cost. I've seen projects be done just for fun, let alone cost reductions.

I might have a stab at wrapping the RTAPIs into FreeRTOS equivalents at some point...

Tom: Mechanix mentioned in the other thread from an Espressif account manager that, I believe, general availability of the P4 will be June this year...

EDIT: Mechanix - the 10ms delay isn't mandatory and watchdogs can be changed. You can go as low as you want. Even the core 1khz tick frequency can be changed to be much faster (or slower) if it's needed. Hardware ISRs exist for a reason too - literally as fast as you want. All in the design detail and applied experience of which to use and when.
 

It seems to me despite having a lot of respect Expessif, and like how FreeRTOS exposes multiple cores, the project seems to be unlikely to suceed.
There is simply no need for it given a plethora of Industrial ARM and AMD64 PC's available on the market today. There are even touch panels with embedded PC's in them that can run Linuxcnc.

OK, here we go again:
wiki.fluidnc.com/en/hardware/official/6x_CNC_Controller
It is magnificent what those small cheap controllers can do with some clean code.
It is a nice idea, an even better exercise, and if it works properly....who knows, maybe it changes the machine controller industry! This last i really wish, i was sick and tired of dealing with windows running machines that cr@p out and go on hiatus every 10 minutes, had the joy of gutting a fully functional 2.5 ton plasma machine last year just because it was utterly useless despite everything working. Probably will do that twice more this year.
NO windows on anything, ever!
-
Off topic, but sparked by some replies to this topic:
To put it simply, not helping by complaining and pointing out obvious stuff we all know, and also not at all polite.
I do not tell people NOT to use RPI for machine control, it is very cr@ppy (till 5 came out) and more expensive than a used PC with much more processing power. And for all intents and purposes, using a very small PC on a very big machine makes no logical sense.
That is my opinion from extensive experience, but i refrain from slapping it all over the place. Although i probably did, occasionally, so if i did, i am sorry.
-
Back on topic:
Was some version of RTOS based on windows something or another?

For an application that requires serious timing integrity, let's just say that freeRTos ain't exactly your best friend. So errant it even has its own catchupticks() api if I recall correctly. Top of its class to fire up lcd panels, BLE scans and connections and/or flash christmas lights though... and everything else that isn't highly dependent of a precision tick...

Have your crystals temperature calibrated upfront for sure! ~Watchdog

RPI5 is decent, such an improvement. Fully agree though. Running a dedicated lowish-cost x86/x64 machine is better and they are everywhere. I used a RPI4 as a showcase demo as prior quick example simply because it was setup and ready to roll, that is all.

The xTaskCatchUpTicks it's quite a specific use-case generally implemented for when interrupts are disabled for extended periods, such as, during extended writes to flash. It's a specific use-case. TCXOs all the way.

Shall we not bother getting into the weeds around timing of an RTOS - is there really any point?

What's there to gain other than having a pissing match? I didn't come into here saying "FreeRTOS is a gimmick". It's just impolite and outright rude to gain a rise.

rodw - thank you I appreciate your feedback!

EDIT: tommylight - IIRC there's been a couple few RTOS's for windows. RTX springs to mind - long time ago. Is it still going? Currently from MS there's Azure RTOS ThreadX. There's even ports for FreeRTOS for windows but aimed at development.