Actually I *don't* want to run a form of Linux.

I suggested running a Linux variant because it would simplify porting code. Most HAL code only uses a few system calls so you could emulate those calls. IMHO rewriting everything to run on dedicated hardware is a bad idea. Not having compatibility with the main LinuxCNC code base will mean you have to maintain all of the code by yourself. That is a lot of work.

Since it's dedicated
HW, the tasks can be hardcoded for bare metal and stored in flash and
directly load the STEP/DIR pins with SPI data which does precise,
synchronized step-outs.. This is leaner, simpler, more reliable and
the latency can be very low and consistent (although LinuxCNC on
Preempt-RT is already all of that for my machine).

If you are just concerned with accurate steps then just move step generation to external hardware. The trajectory planning etc is done at a relatively low speed (usually 1ms intervals) and even a few hundred microseconds of jitter isn't a big deal so there is nothing much to gain in moving this to dedicated hardware. The Ethernet Mesa boards work this way. They use hardware step generation that is updated every 1ms over Ethernet.

This would require somewhat extensive modification of code.
Microcontrollers typically use C and cannot handle C++'s OOP nor
dynamic memory allocation.

This is a myth. Even the lowly 8 bit ATMEGA series is fine running OOP C++. Look at Arduino. The majority of that code is C++. Several years ago I wrote a preemptive+cooperative multi tasking real time OS in C++ and it ran well on an ATMEGA. On more memory restricted parts you need to be careful with dynamic memory allocation but it still works as long as you don't go overboard. If you're considering moving emcmot etc to another processor you're gonna need something with considerably more grunt than an ATMEGA anyway.


Emc-users mailing list

Reply via email to