I have to agree, The entire point of moving al real time functions to hardware is so that a real-time OS is no longer required.
The only reason Linux is even needed is that it is an easy way to get a real-time OS. If not for the RT requirement you could use a Mac or Windows or even an iPad or any cell phone. If the machine controler could run on a me=aintstream OS (like Windows 10) and on a normal notebook PC it would be orders of magnitude more popular and widly used "EMC" as it was called (then later Linux CNC and then MK) was a great idea: Use existing, low cost off the shelf hardware to control a CNC machine. This is still a good a very idea but today the existing low-cost hardware looks like an STM32 chip and cost about $5. These chips have "compute power" roughly the same as the old PCs EMC was developed with. These little chips are nice to use not just because of the price but because there typically come with an RT operating system (based on CMSIS) that has much better RT performance than any RT-Linux. There is nothing special about Linux other than it provided a cheap and easy to get RT OS. The CMSIS based RTOSes on STM32 are better. I have some experience with both ways and believe by moving to the smaller RT system is nearly Arduino-like simplicity and ease of use. I'm using it for robotic motion control now. On Thu, Apr 11, 2019 at 3:32 AM Les Newell <les.new...@fastmail.co.uk> wrote: > > > 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 > -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
