Part 2: RTLinux — the Present

Aug 12, 1997 — by Rick Lehrbaum — from the LinuxDevices Archive — views

Part 2: RTLinux — the Present

RL: I understand you're nearly ready to release version 3 of RTLinux, which is currently in beta. Could you briefly describe what's new in that release?

Yodaiken: We're closing in on a final version 3. There are a whole list of changes since version 2 . . .

RTLinux now runs on PowerPC and on Alpha as well as x86, and we are hoping to release a MIPS version too. We're getting amazing performance on PowerPC embedded systems and on the Alphas. We're impressed with those. We've seen better performance on PowerPC than on the Pentium systems, mainly because the interrupt controllers and timers on non-ISA systems are less intrusive than on the Pentium/PC motherboard designs.

We did the Alpha port because it was our most requested next chip. There are people who want to use the Alpha where they are very compute hungry — especially in things like engine control. In high end real-time where you need a lot of compute power, people are really pushing the limits of what's available in current processors.
We have some enhancements in SMP operation which allow you to dedicate processors to real-time event handling.
We have a new ability for real-time signal handlers in user tasks, where the user process makes an rtlinux_sigaction which will work like the POSIX sigaction, except the signal handlers run in realtime and there's an extension to allow us to catch periodic interrupts. As a result, the user process can designate a function to operate within hard real-time deadlines. And those functions run in the address space of that process, so they can share data with the process, and call functions libraries of the process.

For example, you run a user program, and that program may need to collect data from an A-to-D device every 200 microseconds. The two ways of doing that are: you can write an RTLinux thread that runs in kernel space and collects data from this device and dumps it through a pipe or via shared memory to the user space, or you the use process can install a rtlinux signal handler which reads data from the device into the process address space and that makes it a lot easier, especially for simpler data acquisition systems and for systems where you have complex user libraries.

One good example of this will be people who want to take OpenGL and other graphics libraries, and read data in and do some processing on the data in real time, they'll be able to use this facility. Our customer for this was the Jim Hanson Creature Shop — we did it for them but we're going to make it available generally.
Another thing is the use of the GDB [GNU debugger] with RTLinux threads. You can set up RTLinux threads so that when an RTLinux thread makes an arithmetic error (e.g. divide by zero) or reaches for the wrong memory address, it will trap and the whole RTLinux system will halt, while Linux itself continues, and on the same machine you can run GDB and inspect the state of everything and do single stepping. All the facilities of GDB are available on that same machine. Also, you can use all of the standard front ends of GDB, such as DDD. As far as GDB is concerned, it's debugging something that's on a remote machine — but it's actually on the local machine.

Continued . . .

Story navigation:
Part 1: RTLinux — the Past
Part 2: RTLinux — the Present
Part 3: RTLinux — the Future
Part 4: RTLinux and real-time standards
Part 5: “The Infamous RTLinux Patent”

Do you have questions or comments on this article? talkback here

This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.

Comments are closed.

Pages

Archives

Categories

Part 2: RTLinux — the Present

Related Posts: