Slashdot Mirror

Is this thing going to replace https://www.rtai.org/ completely?

More importantly, can http://linuxcnc.org/ a CNC software, benefit from this extension?

Whether Linux is appropriate depends largely on the type of project you're doing. You're probably aware that tons of routers and assorted network gear runs Linux. It might be the best choice if that's what you're doing. But if you're trying to do hard realtime control with Linux... well, if your experience is anything like mine was, it'll be painful.

I did a project with a 266 MHz PII single-board computer once. I chose it because it had tons of on-board A/D and D/A, and when I ordered it I asked the company for their Linux drivers, etc, as well (which they advertised). They sent me a customized version of Redhat to be installed on the development machine, and a bunch of tools to set up a stripped down distro on the target as well, using the same libc libraries, etc.

There were numerous errors in what they sent me, including stupid things like configuration files having DOS instead of UNIX line endings. How this got out the door I do not know. But, I could fix all those dumb oversights, so that wasn't the problem.

The issue was that the distro they sent did not include any realtime extensions (a must for my application), so I endeavored to install RTAI on it. This was where I began to have real problems.

The kernel they were using was old -- 2.2.some-low-number. Assuming this is what their drivers would work with, I found the vanilla source from kernel.org for a nearby 2.2 version, slightly higher, compiled it, no problems. I then tried it with their extra A/D and D/A drivers compiled in: no problems. Then, I tried it with the RTAI extensions (without their extra drivers: Test one thing at a time!) It compiled, but when I tried to run RTAI diagnostic programs the machine would unceremoniously reboot. No good.

"Ok," I thought, "this is a pretty old version of RTAI. Let's try a newer version; maybe that's a little more mature." In order to do that, I needed to use either a 2.4 or a 2.6 kernel. So, I started by trying to build a 2.4 or a 2.6 kernel, again from kernel.org, first, without either RTAI or the extra drivers. First problem: gcc too old. Solution: Compiled on another machine (really, coLinux on my laptop, running Debian Sarge). But after putting the kernel images in the correct locations and reinstalling the boatloader with lilo as you'd expect, the machine would just reboot every time it'd start to execute the kernel. This happened for more permutations than I can remember of 2.4 and 2.6 kernel versions, and configuration options.

Unable to get RTAI working on an old kernel, and unable to get a new kernel to run, (and desperately needing realtime), I ended up putting DOS on the thing and writing code in 16-bit real mode. This gave me essentially unfettered access to the hardware, with fast interrupts, so that, even though people tend not to consider DOS an 'RTOS' per-se, it stayed out of my way enough that I was able to access the hardware directly and run with guaranteeable latencies.

DOS made lots of things harder -- networking and accessing extended memory in particular -- but solving each of those problems proved possible, since I was working with small enough atomic "pieces of the system" that they could be debugged. When I'd been trying to put together linux with RTAI with the given drivers, I was working with a big-monolithic-kernel... running-in-another-mini-kernel, and I could do little more than follow instructions, compile, and pray. If it'd worked, it'd've made my life much easier, but, when it didn't work, I was pretty much at a loss.

If you're on a tight time budget and you've never used embedded Linux before, as much as I love Linux, I've got to say: If you're doing a realtime project, just pay the money for a "real" RTOS.

** If anyone else has had different experiences, I'd be curious to hear them. Though it's too late now, I'd also be curious if anyone has some after-the-fact ideas about why the 2.4 and 2.6 kernels wouldn't execute.

It's free (as in freedom AND beer), and it works pretty well, especially with I/O cards that are supported by comedi drivers, which are designed with real-time use in mind.

We use them for our real-time HIL simulations at my department, and we're happy with the results.

Check out RTAI. Yes, you have to patch it, but those guys are doing an incredible job to make your linux kernel real-time.

The Real-Time Application Interface is a hard real-time extension to the Linux kernel, contributed in accordance with the Free Software guidelines. It provides the features of an industrial-grade RTOS, seamlessly accessible from the powerful and sophisticated GNU/Linux environment.

Greets,
Stefano

It depends on your requirements. We're using RTAI for a few applications and it gives us some 10 or 20 microsecond maximum interrupt jitter on a 100MHz PowerPC. For a lot of applications, this is OK. Why stick to a commercial RTOS if Linux solves the problem as well (at least if your RT requirements are not as tight).

Have you looked into RTAI? It's a kernel patch (even the 2.6 series) to get it real-time.

Greets,

Stefano

At the risk of sounding redundant, how is MontaVista's implementation significantly better or different from pre-existing real-time Linux interfaces, such as FSMLabs' RT Linux or DIAPM's RTAI?

There are two major projects whose purpose is to create a hard real-time kernel running on top of Linux -- RT Linux and RTAI.

There are also others, but they are a lot more immature than those two.

Considering that the patent is easily breakable in court, the FSF settled with Victor very easily. Why ? because RTlinux is irrelevant : RTAI is the way to go now. It provides all that RTlinux provides and much more, and it isn't encumbered by silly patents.

All in all, a much better move than it first appears by the FSF : they win on the PR front by making Victor change his license and they save money by not contesting a patent that isn't important anymore. Way to go guys !