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.
Les
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
