LinuxCNC EMC Port to FreeRTOS? Curious...

Just curious from any LinuxCNC maintainers that are more experienced...

Has anyone ever dug deep enough or explored the possibility of porting EMC2 over to FreeRTOS OS that doesn't run Linux? Native embedded.

Yeah I know it'd be a monster, in all likely hood quite impossible given Linux dependencies, but I'd still be very interested to know if anyone has tried or performed a detailed analysis in the past?

Not much comes up searching around.

In all likelihood, at a guess, it'll be time vs benefit and slow MCUs and so on. But... I am still curious though.

Things are evolving in the hardware space and will continue to do so.

Flash sizes, ram sizes (256mb+) all growing.I'm aware anything that would be developed would likely be a vendor specific hardware implementation which goes entirely against the ethos of the project but still... it's a valid question, at least from a technical perspective?

I know EMC2 was ported to Solaris...

80-90% of the hal components wouldn’t work unless they were ported too to become equivalent versions of them to support embedded hardware (wrappers etc) which makes it kind of a pointless exercise.

Having something that runs natively on a high end MCU with sufficient memory coupled with direct access to its hardware peripherals - that would be incredible, it if performed and remained flexible.Remote GUI on a standard Linux machine or even possibly embedded too on a separate MCU driving HDMI display (MicroPython LVGL etc).

I’ve seen Risc-V Linux RT_PREMPT patches and the milk-v Duo/Duo-S too – that’d be interesting to see someone get a headless emc running on that (with its ethernet port) and to see the RTAI stats….

EDIT: Formatting

Thanks Tom! Really do appreciate it.
I'll certainly have a look at the distros you've suggested always good to learn!

Yeah reckon you're right. Risc-V is worth it - part of reason why I'm asking too - both for milk-v and other archs since it's only going to become more accessible over time. A fully embedded version of EMC2/LCNC core running on say the new Risc-V ESP32-P4 that takes advantage of the hardware - I think, would be truly amazing. Just flash a firmware on a board and you pretty much have a "lite" version of LCNC running.

Yeah yeah I know ESP32 again! But... please bear with me...

After all DMA tweaks and perf optimisations thus far on the S3 (Xtensa core) it's peaks 3% load (including hardware timers and interrupts) running all tasks at 400khz across 4 axis.
I'm genuinely floored.

So based on all that - I believe (could change) once the P4 is launched there may be a real possibility of port of LCNC that runs entirely embedded. I've done a bit of a brief analysis around memory usage and RTAI, whilst it's a big big effort to port, if its kept open source and free to all then I (hopefully) don't see a reason why it can't be done (don't detract from the project and feedback to improve and so forth).

Open to all and any feedback though!

Thanks
 

FreeRTos is a gimmick, but hey it's free! Great toy none the less...

Inviting you to the world of far superior and robust parallel multitask computing. Look no further than:

#include <pthread.h>

I think you might be mistaken.
POSIX support and more specifically pthread on Espressif specifically is provided by the RTOS as wrappers by default.

docs.espressif.com/projects/esp-idf/en/l.../system/pthread.html

FreeRTOS helps with portability across architectures and provides numerous APIs for queuing, buffers, IPC and much more. Agnostic to the underlying hardware.

Why would you say it's a gimmick?

Doesn't always have to be hardcore low level engineering, use the features that are available to you for each use-case. Afterall, everything is built on the shoulders of others great work and findings...


EDIT: You will find that with any microcontroller there is an RTOS for POSIX APIs underneath (pthread). Still needs a scheduler to function!
PS: www.eevblog.com/forum/microcontrollers/freertos-vs-pthread/
An analogy, think of the RTOS as the Linux equivalent of the Kernels scheduler. Without it, there's no POSIX threads (pthread)

Hope it helps clear things up!

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.