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.

Re:Amazing Field of Work

[Quirk]

Not my bailiwick, but isn't ITRON meant to be the best embedded systems OS?

Linux.

[Anonymous Coward]

This is Linux: ooooh look at ME! I can guarantee multiple-microsecond interrupt times! La dee da!

Re:Linux.

[Roliverio]

....Theo?

I tought you never had used linux.... xD

Re:what about a complete embedded linux distributi

[Jerry Coffin]

what about a complete embedded linux distribution for x86. Just think how much faster your system would become.

This has already been modded as a troll, but giving you the benefit of the doubt, do you mean something different from things like Monta Vista or Lynuxworks ?

Of course, it's also worth mentioning that "real time" doesn't necessarily mean "fast." In fact, rather the opposite is typically true: a real-time system must (by nature) make the worst case predictable -- but often compromises the average performance to do so.

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

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.

not really key area for linux

[Keruo]

Embedded devices aren't really focus market for linux. Even with being stripped to bare minimum, the kernel will take over 500kb to operate.
Embedded systems usually don't have need to carry that much memory. Task specific operating systems like TRON and its variations take only few kilobytes, and are extremely efficient and reliable in what they do.
What linux provides, is interesting approach, but it also rises the price tag with hardware specs higher than the cheapest alternatives.

Re:not really key area for linux

[MooUK]

And that's part of what some people forget. Linux is great. It can be used for just about anything you can think of, given some tweaking. But for some things, while it is CABAPLE of doing everything, it's not necessarily GOOD at it. In general terms, what's better for the gamer? Most games are only available on windows. Some notably excellent ones are available elsewhere, but most aren't. Yet. For an older/smaller/cheaper mobile phone, desktop-intended OS's aren't ideal. Symbian was designed to be fast and simple. An embedded system may need a custom-written system to give it speed or timing features it needs.

Re:not really key area for linux

[Short Circuit]

For an older/smaller/cheaper mobile phone, desktop-intended OS's aren't ideal.

I wouldn't say that Linux is a desktop-intended kernel. It certainly didn't start out that way, and wasn't intended to.

Many of the distributions are intended for the desktop. And many are intended to be run as servers. And a fair few are intended to be run in embedded systems.

The Linux kernel has a lot of developers working on making it suit their specific needs. In this way, it can be all things to most people and most things to (virtually) all people. Probably its greatest advantage is the portability of code that's written for it. A telnet daemon written to run on my K7 Athlon can be recompiled to run on someone's Linux-based PDA. Or an ethernet-enabled PlayStation 2. Or my brother's DSL router/modem. That's why cross-scale development of the Linux kernel is important.

Re:not really key area for linux

[Pseudonym]

For the umpteenth time: embedded != small

Sure, a digital camera is an embedded device, but so is an MRI scanner.

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.

Re:not really key area for linux

[gnalre]

The term embedded covers a large area from small devices to devices with more power than desk top machines.

However in the latest ESP survey it was found 24% said they were using linux 17% said they were likely to use it soon and 33% said it was likiely they would use it. That shows that Nearly 75% with an interest in linux. Not bad fo a non focussed market.

ALso the biggest embedded OS provider(vxworks 22%) are pushing linux hard as a complementry solution to there flagship product.

So I would say linux has a big future in the embedded world

Real-time java? Talk about your oxymorons

[ClosedSource]

Real-time software isn't even necessarily processor speed-independent, let alone platform dependent.

In the worst case, you have to know exactly how many time (accurate to the length of a CPU cycle) it will take for a section of code to be executed or know exactly how long it will take an interrupt to vector to your interrupt handler.

I'll be Java timing isn't even consistent from one JVM release to the next for the same code running on the same computer.

Re:Real-time java? Talk about your oxymorons

[Hast]

How about if you try to look into facts before shooting your mouth off?

While Java and real-time may seem like hard to integrate it is possible and it has been done (successfully). Eg I've seen demonstrations of RT systems runnning on industrial robots which balanced inverted pendulums without a problem.

Now naturally timing may differ between architectures, that's to be expected. What's important is that if you have a specific architecture you need to know, exactly, what delays occur and that they have upper bounds. The same would be true with a Asm or C RT system.

The main reason you'd want to run Java RT is because first off, it's faster to write correctly. It also makes it possible to have eg dynamic reprogramming on a factory floor. (To the point where new control data is updated while the welder robot switches between weld spots.)

Re:Real-time java? Talk about your oxymorons

[ClosedSource]

"How about if you try to look into facts before shooting your mouth off?"

I'm not an expert in RT java, but I've written code with required timing accuracy to 1 cpu cycle which I think qualifies me quite well to comment on RT issues.

"What's important is that if you have a specific architecture you need to know, exactly, what delays occur and that they have upper bounds."

The issue isn't speed, it's accuracy. Hard RT systems have lower bounds as well as upper bounds. Being early is no better than being late.

"The same would be true with a Asm or C RT system"

Sure, but the difference is that in Java you have another layer to deal with so determining the timing is more complex.

"The main reason you'd want to run Java RT is because first off, it's faster to write correctly."

This is a matter of opinion even for conventional programs. For a RT system, I think you have the burden of proof for this claim.

Re:Why Linux?

[Lifewish]

Because those better alternatives provide more freedom for Microsoft to take the code, repackage it, hack it about as they wish and sell it to the masses, giving fuck-all back to the community. This would likely bother a few of the developers in question.

Re:Why Linux?

[MooUK]

It mostly comes down to whether you want to have the freedom to stop anyone else using your modifications, or you want to stop anyone denying anyone else that freedom. (One of) The main thing(s) that stops most companies forking proprietary versions off BSD-licensed code is that they then have to repeat any patching, fixing, and improving done on the trunk. (Or repeatedly re-fork, as Firefox has done - and yes, that's not a closed-source project, but it's still a good example for this point.) If you're using a BSD distribution, I'm not sure it can be directly compared to using individual GNU/Linux/etc packages. Maybe it should be compared to one of the linux distros, where again you can go to that project's devs and community for assistance if you need it, rather than going direct to the individual programs and projects.

Re:Why Linux?

[Klivian]

Why do embedded developers continue to imprison themselves in the GPL trap by using Linux,

Because Linux has a much bigger developer comunity and you can get commercial support targeted at embedded development from several vendors. Giving better freedom getting developer resources.

And the GPL "trap" as you call it, does not really matter even in embedded development. The interesting part of the product, or the part you may want not to GPL, will reside in userspace anyway making the GPL of the kernel irrelevant.

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.

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?

[Lifewish]

That's a rather negative view of the GPL. I'd point out, for example, that helping companies like Microsoft by supplying them with good code allows them to become yet more powerful and do even more damage to the rest of the computing world. In my recent job I had to use Win2K for compatibility reasons. This is due to Windows' massive predominance within the business world, which in turn is partly the fault of, for example, the people who produced the Berkeley TCP/IP stack, as they helped Windows to achieve (moderate) network stability and thus compete more effectively, greasing the tracks of MS's meteoric rise to monopoly.

I'm aware that this is an extremely bad example as BSDing protocols is generally a good thing for uniform adoption. My point is that using the GPL is often an indication of a desire to protect the community of developers rather than of "irrational possessiveness" - possessiveness maybe, but hardly irrational. In this particular case, the "loss of control along with a lessened responsibility" of which you speak includes an increased ability of the more evil proprietary software companies to undermine your developer community - thus there's no short-term incentive for them to play nice. I personally am not quite advanced enough along the Zen path to take this with a smile and a nod and carry on helping it happen.

Re:Good Books on the Subject

[Doppler00]

Not only did you not recommend any books you didn't even spell embedded right.

For the most part I think you'll learn the most just reading through the databooks and application notes that come with the particular embedded platform that you are working on. Stay FAR away from any hobby-type embedded systems books that focus on PIC processors if you are doing anything serious. I've found a lot of the code in those types of books to be poorly written and counter productive. Since most embedded systems are programmed in C you'll want to pick up a book on that.

Re:Wow, I'm Impressed?

[Jerry Coffin]

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.

I suppose I'll get modded as troll (again) for saying so, but from what you've said, I'd guess you're one of the people who's not an RT programmer.

Real-time programs do need to react in real time. A typical example is that the program needs to react within X microseconds of an interrupt happening. A hard real-time requirement is exactly that -- no "seem that they do" about it. For example, a navigation system for an aircraft must react within the right amount of time to input from the pilot, radars, etc. A late reaction carries the possibility of killing hundreds of people (conceivably even thousands with particularly bad luck about where it lands).

ABS systems are not allowed to have delay, mail servers are.

Every system has some delay -- the questions are 1) how much?, and 2) how much does it matter if it misses its window by some small amount? A hard real-time system is one where you have an absolute maximum delay, and you must never miss it. A soft real-time system is one where you may be able to get away with slightly greater delays on rare occasion -- the "softness" of the real time being determined largely by how large the delay can be, and how often it can happen. The situations above with brakes or aircraft navigation are about as hard of real-time as you can get -- excessive delay is likely to cause deaths. A router or mail server has substantially softer requirements. If it misses receiving part of a packet very often, it won't work well -- but as long as it's not very often, it's probably not a problem, and endangering lives is pretty far-fetched even at worst.

Also note that real-time does not necessarily mean much about being fast. Years ago, I worked on some software to control some of the operations in a sewage plant. In most cases, the computers' requirements on the reaction times were measured in entire seconds and sometimes even minutes -- but if it missed a deadline, millions of dollars in damage could be expected, and endangering lives was possible as well. Ridiculously slow by most standards, but hard real-time nonetheless.

So -- the essence of real-time is not about "high speed" it's about "dependable and predictable speed". Real-time requirements are specified not only in terms of "How fast?", but "How serious is too slow a reaction?" -- and the latter is often what really dominates.

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

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:Wow, I'm Impressed?

[Animats]

AFAIK, device drivers are in kernel space in QNX

No, device drivers in QNX are in 100% in user space. I've written one, for FireWire cameras. Manual page here.

QNX device drivers can have the privilege of mapping device memory into their address space, but they're still user-level programs. I've developed hardware drivers on a running QNX system without rebooting.

Re:Wow, I'm Impressed?

[Mindjiver]

"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."

I though the traditional definition of a real-time was a system that had temporal requirements as well as functional requirements. That is, it should perform the operation as specified and at the right time.

Also, real-time system does not need to be small. There are real-time systems that run Pentium processors with several GHz, it's all about the temporal requirements!

You are wrong

[Mindjiver]

When you say that real-time software is a dying art you are totally wrong. The move is from specialized hardware and/or mechanics to software-based solutions where the time-to-market for adding a new feature is smaller than for specialized hardware. If real-time software was a dying thing why does a modern car contain so many micro-processors running real-time software?