Papers On Real-Time And Embedded Linux

An anonymous reader writes "LinuxDevices has once again published the proceedings of the annual Real-Time Linux Workshop. This one, the seventh, was held in France earlier this month, at the University for Science and Technology of Lille (USTL). The papers span a range of topics, from fundamental real-time technologies to applications, hardware, and tools. Enjoy!"

Comments

Amazing Field of Work

[JoeShmoe950]

I've always found the field of embedded operating system's somewhat intruiging. From the automatic welders, to the VCRs, etc. Anything involving robots, or extremely low power systems is somewhat interesting, and even if linux eventually fails on the desktop market (stops growing), it may be around us in our daily lives much longer.

Re:Amazing Field of Work

[ClosedSource]

I think as long as you're talking about the "new" embedded systems (i.e. no or easy real-time or a general purpose computer in a smaller form-factor) then OS's like Windows CE or Linux will be OK.

For traditional embedded systems (i.e extremely limited resources or true real-time software) these OS's will come up short. They are too bloated for low resources systems and their timing is to variable for serious real-time work.

Of course, most of today's microprocessors aren't appropriate for hard real-time software either. Once you add complicated prefetch schemes and caches to the mix, you can't really do anything that requires fine timing precision.

Fortunately for traditional OS's, real-time software is a dying art and most real-time work is done in specialized hardware rather than software these days. In addition, the resource issue is not really much of a problem these days.

Real time interpreted languages

[BlkItlStl]

What will really be interesting to see is the advancement in real-time interpreted languages like java. This should allow for portability of embedded applications on all kinds of embedded devices regardless of what OS is in use.
More info on real-time java https://rtsj.dev.java.net/

Re:Real time interpreted languages

[Jerry Coffin]

What will really be interesting to see is the advancement in real-time interpreted languages like java. This should allow for portability of embedded applications on all kinds of embedded devices regardless of what OS is in use.

Despite the claims of "Write Once Run Anywhere", my experience with Java has been rather the opposite -- that writing portable Java is (as a rule) even more difficult that writing portable C or C++. It's nice that the portable GUI library is part of the spec instad of an add-on like wxWidgets, but from a practical viewpoint has little real effect on portability. That may be mostly a matter of the kinds of code I write though -- some people certainly seem to find it a lot more useful than I have so far.

Warning: I hadn't previously looked at the RT Java spec (at least that I recall) so these comments are based on looking at it for no more than an hour or so.

In this case, it looks like portability may be even more difficult than usual -- for one thing, it allows raw access to physical memory. Though the functions involved allow the system to throw exceptions when/if this is abused, at least at first glance it looks like an obvious point of attack on such a system.

Maybe I'm reading it incorrectly, but the introduction section of the specification seems to imply that this is basically intended as a set of extensions to a normal (non-RT) Java environment, that would (in turn) normally be running on top of a non-RT OS. It appears that while it allows predictability of scheduling of one thread vs. another within the JVM, little or nothing is implied about the scheduling of the JVM vs. other processes on the system. From the looks of things, the system could be implemented on top of a non-RT OS, in which case the RT applications would run, but RT response would be more or less accidental. Given the nature of a JVM, that may be difficult (at best) to prevent though.

Finally, looking through the project web page, the only implementation I find mentioned is the reference -- this may imply that even though the spec is now over 4 years old, it has seen little or no real use. That isn't necessarily a major criticism, but it doesn't seem like a ringing endorsement either. Maybe I'm just getting old and cynical, but it strikes as being a bit like DPMI 1.0: a nice spec, but I'm not yet convinced it'll ever really mean a whole lot.

--
The universe is a figment of its own imagination.

Re:Why Linux?

[convolvatron]

dont forget the lowly event loop. alot of embedded
systems dont need anything like an os at all.

Re:Why Linux?

[patcito]

well as an industry player, the fact that I can reuse all the improvements for free and the fact that they will always be available and debuggable is a very good point to use linux, which makes it popular.

Wow, I'm Impressed?

[zappepcs]

It doesn't look like there are many RT programmers on /.?
RT applications are said to be so because of the requirement for them to react in *real time* even though that is not the actual case. It just needs to seem that they do.

Microprocessors and full fledged desktops or servers have different tasks, different design criteria. You may want to know as soon as an email arrives, but you damn sure want to know when your cars brakes are about to fail. There are differences in the meaning of 'real time' in these two (off the top of my head) examples. ABS systems are not allowed to have delay, mail servers are.

RT Linux does exist (QNX as example), but its not free. People who do the work to tweak the code to be able to react in real time want money for their work, and good for them. I don't think (I could be wrong) that you will find the military or NASA etc. using Windows for RT applications. Many RT systems are OS with tweaks for particular hardware that give 'good enough' RT results.

For microcontrollers, there are several options, and all of these make compromises here and there to fit the code in a very small space. The need for embedded real time OS's is totally dependent on the application. A mail server is not so picky, a space shuttle controller has a bit more requirement, and a washing machine yet a third set of requirements.

Embedded processing is very dependent on the requirements of the hardware and the system, as well as the hardware available. The funny part is that Linux is not targeted at hardware that is typically used in RT systems, no matter what that hardware is, so I agree, it is not the target market for Linux even though Linux has the ability to be a RTOS, and in fact, has been shown to work well in RT environments.

Re:Wow, I'm Impressed?

[Animats]

RT Linux does exist (QNX as example)

QNX isn't a Linux derivative. It's not even a UNIX derivative. It's a POSIX-compliant microkernel, with a totally different underlying architecture than Linux. Latency is much better than Linux, because the kernel just handles message passing, CPU dispatching, and timing - everything else, like file systems, drivers, and networking, is in user space and preemptable. Overall performance is slightly worse than Linux.

The newer real-time Linux variants based on the 2.6 kernel are getting to be decent. 2.6 finally got most of the long interrupt lockouts out of the kernel, and allowed preemption of some kernel tasks. Look at the MonteVista or BlueCat variants. You still have to be careful not to load any drivers that contain long interrupt lockouts, or real-time latency will go way up.

The original "RT Linux" was a hack which basically allowed running your real-time application as a loadable kernel module, like a driver. That's basically a dead end at this point in time.

QNX, unfortunately, was acquired by a larger company, which has changed the business strategy from opening up QNX to raising prices and cutting functionality of the base package. The main architect of QNX died a few years ago, and things really haven't been the same since. It's sad.

Re:Why Linux?

[tomstdenis]

And the FreeBSD ports system is far superior to the Gentoo equivalent.

O RLY?

Gentoo: emerge -UD gaim

FreeBSD: cd /usr/ports/whatthefuckdirisitin/gaim ; make install

Yeah that's SOOO superior.

Gentoo uses mirrors for fetching files. BSD apparently doesn't [I couldn't fetch mplayer because the primary server was down].

Gentoo uses bash, BSD uses csh [WHY!!! OH WHY!!!]

Try installing more complicated packages like latex, I installed all of the laTeX* packages and I still didn't have a "latex" command.

As for cpu scaling, it's an AMD XP-M laptop with ACPI based PST entries. with "cpufreq" loaded the cpu runs at the full speed of 1.8Ghz regardless of idle time. In Gentoo Linux [well just linux 2.6.x] scaling works and the cpu idles at 530Mhz.

Agreed I didn't use it for long but I just don't see the appeal OVER gentoo. I mean Gentoo can be a server OS just the same as BSD. In fact, I've built quite a few live HTTP, SMTP, POP, IMAP, NIS, DNS servers from it. I'm sure BSD is up there but it lacks polish. People bitch that gentoo is hard to use, how is BSD any better when it's even harder to use?

Gentoo ain't perfect [nor is the Linux Kernel] but for the most part it works a lot more than it fails [being that all of my computers run it]. I think it's good that BSD distros exist because it provides diversity in case for instance, Linux blows up.

All I'm saying is FreeBSD requires some serious userspace polishing.

Tom

Re:not really key area for linux

[Breakfast Pants]

"Also you probably have linux in your home router if you have one." I'd like you to substantiate that. It isn't true whatsoever. While linux is in some home routers (most notably early versions of the famous linksys WRT54G), it certainly isn't in most.