Michael Buesch wrote: >On Tuesday 17 February 2009 00:21:15 Alex Joni wrote: > > >>I don't think linux-rt will get to the point where it replaces RTAI. They >>are different things, with different goals. >>But nonetheless linux-rt can be something usefull to run a servo system for >>example. >> >> > >Yeah well. Currently it's not possible to do software step generation with it, >as the latencies are too high. >But Ingo says that latency can possibly be brought below 10uS. He already did >13uS with >some hacks. So this is where it gets interesting for software stepgen. > > Interesting. The best numbers I had seen for the -rt kernels were in the 20-25 us range I think. This is in the realm needed by step generation, so that's good.
>I see that linux-rt and RTAI have different goals, but I'm just wondering if >linux-rt >simply isn't just enough for most of the EMC2 uses (in the future when >linux-rt fixed >their latency issues). >So my basic idea is that lots of people could get a working EMC setup >(possibly with >software stepgen) without installing RTAI. > > Most people using servo systems or hardware for low level stuff (step generation, PWM, encoder counting) should be able to use it. I'm not sure what timing guarantees there are though. Note that using kernel modules does another nice thing for us though - it links our modules at load time. This can be done in userspace too, as it's done in the simulator build. >Of course this is all future foobar, as we're still probably years away from a >full >linux-rt merge into mainline kernels. So for the time being it wouldn't make a >difference >if users need to install RTAI or linux-rt. > > I was thinking that too. Now there is a community-maintained -rt kernel for Ubuntu, and maybe for debian as well. Just depending on that instead of packaging our own could be a nice thing. As you say though, this is future stuff, so I think we'll be supplying an RTAI kernel for a while. >Another big advantage is, of course, that we can use the linux APIs in RT code >and get rid of some duplicated stuff (PCI device handling etc...). > How many of the Linux APIs (a) are really useful to the machine control kernel-based stuff and (b) are also realtime? I can think of one great thing for category a - file access. It would be great to be able to load screw comp files directly, for example. The trouble with syscalls is that they are usually scheduling points also. We never ever want a realtime thread to sleep. Ever. Being able to use the normal user APIs might be good, but it also could screw things totally. I guess I'm in agreement that it's good to monitor this. In fact, one idea is to just make a POSIX.1b-based RTAPI layer. That would be the most portable, and would "automagically" use whatever timing accuracy is available on a particular kernel (possibly even without recompiling, but I could be wrong about that). - Steve ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
