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?

Re:Amazing Field of Work

[Anonymous Coward]

Linux has already failed on the desktop. Entire desktop GUIs have been created from scratch and achieved marketplace acceptance, and superior usability, in half the time it has taken Gnome and KDE to cobble together their present festival of mediocrity. Even the filthiest, hairiest basement dweller must now admit that as long as the for-profit world outpaces the "Open Sores" development model, the state of free software can only fall ever farther behind the mainstream, to say nothing of the cutting edge.

Re:Amazing Field of Work

[Anonymous Coward]

It's not a festival of mediocrity because it doesn't beat the user over the head with "user-friendliness" (read: dumbed down). I much prefer KDE to Windows or OS X and I have used both, especially Windows. And I, unlike other Linux zealots, actually liked Windows. I personally feel that KDE fits the way I want to use the computer. I don't feel like I'm fighting with it. And it doesn't insult my intelligence. That may not fly for your average user, but they can stick with Windows for all I care. It's a personal choice.

Re:Amazing Field of Work

[Anonymous Coward]

Hey, is there a 20721 crapflood bunker someplace?

Re:Amazing Field of Work

[Anonymous Coward]

It's right here.

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:Linux.

[Anonymous Coward]

Well, this is totally cool. No other OS i ever used was able to let me run realtime audio processing with a roundtrip latency of 64 sample (that's a buffersize of 32 samples) without any dropouts whatsoever while at the same time compiling a kernel, doing a dd if=/dev/hda1 of=/dev/hda2 and downloading large files via bittorrent (POSIX realtime scheduling classes and prioritizable IRQ handlers allow users to really finetune their system).

Ingo Molnar's realtime preemption patches make linux THE superiour OS for all kinds of timing critical media works. It's a crime that media production software vendors are not selling their stuff for linux.

For information's sake. Here's the typical setup for a linux audioworkstation these days:

- Install realtime-preemption kernel

- setup the realtime lsm or rtlimits so mere users can put tasks into realtime schedulnig classes

- make soundcard irq handler rt prio 90

- run jackd http://jackit.sf.net/ rt at prio 70

- leave all other irq handlers untouched at rt prios around 50

Whooops now all properly coded jack client apps i.e. ardour http://ardour.org/ run undisturbed by otherwise dropout producing hd or net activity. Or even normal processes' cpu load.

Have fun,
Florian Schmidt

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.

Re:High-quality Linux [adj]

[Anonymous Coward]

When the hell did Slashdot turn into Mad Libs for remedial ESL students?

Why Linux?

[Mancat]

Why do embedded developers continue to imprison themselves in the GPL trap by using Linux, when there are better available alternatives that provide more freedom for developers?

Re:Why Linux?

[MooUK]

Possibly because the user base and developer base of Linux and derivatives is considerably larger. There's very little difference in freedom, EXCEPT that someone who takes on a project involving GPL software cannot stop other people having exactly the same freedoms.

At least, that's the sole intention of the GPL, as far as I know.

Re:Why Linux?

[Anonymous Coward]

Thanks for pointing out another market that *BSD has failed in.

Re:Why Linux?

[Lisandro]

I think you mean the other alternatives...

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?

[Mancat]

True. I guess I came off as being a troll, but it was an honest question. The BSD projects provide a fully customisable code base where you can pick and choose exactly what pieces of sofware you want. Aside from the GPL'ed bits, developers are also largely free to do whatever they want with the code, without worrying about competitor X being able to use the code changes that they originally developed for themselves. Unless they want them to, of course. There are plenty of companies that release their modified BSD sources without being required to do so.

The majority of the code also comes from that same project, so there is less worrying about mysterious dependancies when you start taking away chunks of the code, and if there is a problem, you can go directly to the project for support. If you as a developer have a problem with busybox, you have to go to busybox devs for questions. If you have a problem with glibc, you go to that project's devs for questions, and so forth.

Re:Why Linux?

[tomstdenis]

OS wars...

I recently installed FreeBSD 6.0 on my laptop.

It sucks.

No cpu scaling in the kernel [even with cpufreq], the ports tools are shit compared to gentoo, etc.

I'm not saying Linux distros are perfect but Gentoo is way more functional and easier than FreeBSD. I don't know what the other distros are like but sucks to their asmar!

Tom

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?

[patcito]

because with linux, all improvements are available to all whereas with bsds they can be taken away and nobody will be able to takes advantage of it. That way all those improvements sum up and in the end provide a rock solid full featured product, in BSDs those improvements cant be taken away in closed/proprietary sources and sometimes lead to incompability. Thats why the industry prefer linux, cheaper to reuse available tech and much more popular too.

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?

[MooUK]

I'd say that you can't necessarily claim any of those as reasons why industries prefer Linux-based systems to BSD ones. Except one. I think that the main reason that Linux systems are more popular is that they are more popular.

Re:Why Linux?

[MooUK]

I personally put more weight on the views of people who use one system for quite a while, and then try another, and prefer the newer one, to people who use one, try another, and immediately dislike it. That way round, there's less bias from "it's not what I'm used to" and so on.

Re:Why Linux?

[pomo monster]

Some people are perfectly OK with other people benefiting from their work, and these tend to be BSD developers. Others are control freaks who fear that somebody else might use their code for private ends, and these are the people who prefer the GPL. Achieving Zen may not be for everybody, but an irrational possessiveness, it seems, is the source of much unhappiness in this world. The developers in question may find themselves happier by learning to surrender their ego. Accept impermanence; accept that the act of giving, nay, the very act of living, involves a loss of control along with a lessened responsibility. Only then can one understand the true beauty of BSD.

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?

[MooUK]

I'd pick at one point in there: AFAICT, the GPL allows modifications to be kept private as long as the modified software isn't distributed. So, if a company needs some internal software with certain secret features, that would be allowed. It's only distributing modifications without allowing others to modify them in turn that the GPL restricts, there.

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:Why Linux?

[QuantumG]

Because enlightened developers recognise that maximizing freedom for users is more productive than maximizing freedom for themselves.

Re:Why Linux?

[LittleBigScript]

Why not? Even criticism isn't free.

Re:Why Linux?

[tomstdenis]

I personally like distros with users :-)

I don't see a political reason why Gentoo is "teh evil" and it's technically very capable.

Therefore boo BSD, yeah gentoo.

Tom

Re:Why Linux?

[Anonymous Coward]

Don't pollute slashdot with your sensible and fair comments! This is the digital land of hyperbole.

Re:Why Linux?

[irc.goatse.cx troll]

If it wernt for microsoft computers wouldn't be nearly as popular as they are today, you wouldn't have the cheap equipment you have now, the mass amounts of internet based alternatives to boring real life tasks (banking, talking to your grandparents, etc), the hot chick you stalk on myspace, or half the porn you have today.

Just because they didn't contribute patches doesn't mean they didn't contribute. Just the warm feeling of knowing what you wrote became something so much more is nice in itself.

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:Why Linux?

[CyricZ]

Tell us more about the hardware. Perhaps it's your inexperience with FreeBSD that is causing your problems. Or perhaps you just plain fucked up while installing it.

Having installed FreeBSD on various hardware, from desktops to laptops, I cannot say that I have run into such a problem. CPU scaling works well with both FreeBSD 5.x and FreeBSD 6.0 on the systems that I have that support it.

And the FreeBSD ports system is far superior to the Gentoo equivalent. Take some time to learn how to use it effectively. Spend half an hour reading the documentation. You'll be amazed at how well it works.

Indeed, FreeBSD is a very versatile system. It is an excellent workstation OS, especially for power users. It shines spectacularly for many server applications. And it can be easily stripped down for embedded systems use.

You shun FreeBSD now. But that is most likely because you have not yet learned its full power.

Re:Why Linux?

[Anonymous Coward]

Exactly. For a lot of embedded systems (notice that real-time != embedded all the time) the ammount of valid states is significantly smaller than in general purpose systems, therefore making the code much simpler.

I did a lot wth embedded programming and building some of the interface hardware in my senior year, and the code normally was not where a lot of the debugging was. Since you can design hardware to handle to what-ifs sometimes, it makes things easier on the software side.

Re:Why Linux?

[Anonymous Coward]

Because we know better and those aren't really "better."

Re:Why Linux?

[swillden]

Because those better alternatives provide more freedom for Microsoft to take the code

I thought we were talking about embedded systems here. Just how is Microsoft going to dig the code out of the device? They're going to have to want it very, very badly.

Re:Why Linux?

[Hast]

IHBL, IHL, IWHAND.

Achieving Zen may not be for everybody, but an irrational possessiveness, it seems, is the source of much unhappiness in this world.

I agree fully.

That is why I support developers who aid others in their quest for achieving Zen by releasing the code as GPL and thus ensuring that more people will stop hoarding knowledge in their irrational possessiveness. Hopefully this will bring about a better world filled with cuddly teddybears for everyone.

Re:Why Linux?

[ClosedSource]

You're right in some cases.

The problem with a simple loop is that you often end up with timing relationships between functions that are really arbitrary ("Function A occurs on every interrupt. Let's make function B happen every 10 times function A occurs by having it run once every 10 loops. That's probably about right"). Then you find out that later that you need to change the timing for function A and now the timing for function B is off.

When of the main benefits of an RTOS is modularizing time. The only timing relationships between tasks are those you create.

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:Why Linux?

[ClosedSource]

I think the term "distribution" is quite open to interpretation by the courts. Is it a distribution if I distribute it to a coworker or a friend? What about my parent company? Can somebody start a Screw-the-GPL club where they modify GPL'd software and give it only to club members so they don't really distribute it?

I think the real purpose of putting this in the GPL is to sucker people into GPLing their own code. If you create something really useful internally and GPL fanatics get wind of it, you can bet their intrepretation of distribution will be very broad.

Re:Why Linux?

[Lifewish]

If it wernt for microsoft computers wouldn't be nearly as popular as they are today

Just because Microsoft managed to sneak their operating system in at the right moment doesn't mean that they deserve credit for the IBM PC revolution. As the name suggests, it was IBM who first started building standardised desktops and letting others in on the standards in question. Microsoft's one innovation was their refusal to exclusively license the DOS variant they acquired to IBM, thus opening the way for OS standardisation. And yes, that was fairly handy, but (IMO) nowhere near as big a contributory factor as you're making out.

Just the warm feeling of knowing what you wrote became something so much more is nice in itself.

And then watching the company using it turn round and do its best to cripple you and your co-developers by (for example) patenting software, distorting standards and applying legal pressure to competitors wherever possible? Doesn't that annoy you even slightly? The thought obviously worries a lot of people (probably including, as I said, some of the developers in question), otherwise the GPL wouldn't be so popular.

Re:Why Linux?

[ClosedSource]

"As the name suggests, it was IBM who first started building standardised desktops and letting others in on the standards in question."

This is revisionist history. It took years for other vendors to be able to clone the non-OS part of the PC. It would have taken many more years to make a viable clone if the vendors had not been able to buy the OS from MS.

IBM introduced the PS/2 computer line (with its proprietary Micro Channel bus architecture) specifically to gain back the market share lost to the clones. Hardly the behavior of a company that wanted to be totally open.

Re:Why Linux?

[jrcamp]

I think the real purpose of putting this in the GPL is to sucker people into GPLing their own code. If you create something really useful internally and GPL fanatics get wind of it, you can bet their intrepretation of distribution will be very broad.

Yeah, like Google, who runs a custom Linux kernel. Sure would be nice to get ahold of that. You don't hear anybody clamoring for it and claiming to have rights to it now do you?

Re:Why Linux?

[ClosedSource]

"because with linux, all improvements are available to all whereas with bsds they can be taken away and nobody will be able to takes advantage of it. "

You're wrong. Not all improvements to Linux will be available since not all of the modified code is distributed. No BSD code can every be taken away, only the private modifications people make.

I think this "improvements" argument isn't a very strong one anyway. I'll bet that most of them will never appear in a major distribution.

Re:Why Linux?

[ClosedSource]

"Yeah, like Google, who runs a custom Linux kernel. Sure would be nice to get ahold of that."

Yes, I'm sure Google has put the word out that they have a custom Linux kernel and it's really, really great. I doubt that it has broad appeal or that it does something nobody else can do.

Re:Why Linux?

[drsmithy]

As the name suggests, it was IBM who first started building standardised desktops and letting others in on the standards in question.

"Just because IBM were the first to start building standardised desktops and letting others in on the standards in question[0] doesn't mean they deserve credit for the PC revolution."

Look, Microsoft had a significant part to play in the ascendence of the PC. So did IBM. So did Compaq. Certainly, any other company that just happened to have the same products, at the same time and willing to treat them the same way might have taken us to the same end result we have today, but the fact is it was Microsoft, IBM and Compaq.

I fail to see why people insist on saying "yeah, well another company could have done what Microsoft did", as if that somehow changes the fact that it was Microsoft that did it (or, even sillier, that the computing world would have turned out substantially differently today if it was "someone else"). Microsoft were in the right place, at the right time, with the foresight to sieze the opportunity - and by doing so became one of the key reasons we have the computer market we do today. Get over it, already. If it had been WhizzyBangWare instead of Microsoft, Slashdot would be bitching just as much about WhizzyBangWare instead.

Microsoft's one innovation was their refusal to exclusively license the DOS variant they acquired to IBM, thus opening the way for OS standardisation. And yes, that was fairly handy, but (IMO) nowhere near as big a contributory factor as you're making out.

It was just as important as the PC itself, if not more so (IBM-compatible PCs were a complement to the success of DOS, whereas DOS was basically a necessity for the success of IBM-compatible PCs) . Without DOS, there wouldn't have been any market for "IBM compatible" PCs. Compaq wouldn't have made record-breaking amounts of money off their first product if the buyers hadn't had an OS to run their "IBM PC-DOS" applications on.

[0]This isn't really true. While IBM did make the PC out of off-the-shelf parts, they didn't want to license it to anyone. That's why Compaq had to go and clean-room reverse engineer the BIOS. Had IBM got what they wanted (and they tried again with the PS/2), the "IBM PC" would have been just another single-sourced microcomputer. If you seriously think IBM *deliberately* created the "IBM PC revolution", you're delusional - no company seeks to create a marketplace where competition is easy.

Re:Why Linux?

[Breakfast Pants]

"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." Ugg, I think the parent was suggeting that the companies do exactly that themselves; then other companies couldn't take any of their work.

Re:Why Linux?

[Breakfast Pants]

Not only that... we're talking the BSD license here. The company could take the code along with their changes and relicense it GPL if they wanted. Or hell they could even make it proprietary. I don't see the parent's point about Microsoft whatsoever--he is a shill who should never have been modded +5.

Re:Why Linux?

[Anonymous Coward]

LOL no it doesn't GNU does. Linux has a huge fanboy comunity such as Slashdot... Linux is JUST a kernel and its not such a good one. Currently there isn't really any good kernels... I can't wait till the first sucusful exokernel that will be something good....

Re:Why Linux?

[Lifewish]

You're right, I completely misinterpreted the greatgreatgrandparent - I read it as suggesting that the embedded developers license their code under the BSD license rather than just using it as a base. Doh.

However, in context, there's still the remnants of a point amidst the scattered detritus of my idiocy (note: idiot, not shill). This was an academic gathering not an industry event, so any code probably would be passed around and tinkered with (this sort of thing is where the FOSS movement came from, of course). In that context, my rant is not completely without meaning - from conversations I've had at uni, Microsoft appears to have alienated a decent chunk of Computer Science academia (remember Kerberos? I believe that was mostly an MIT thing til MS killed it). As such, they might well choose to license under the GPL rather than BSD license.

I'm getting convoluted in an attempt to save face, so will quit now. Again, apologies for completely misreading the original poster.

Re:Why Linux?

[TheRaven64]

Like the man said, RTFM. Read Dru Lavine's excellent article on portupgrade. Then learn how to type:

# portinstall teTeX

Voila, a full LaTeX install. If you like installing everything from source, that is. On most ports, I don't want to bother tuning them, so I tell portupgrade to install from a binary package if one is available (it usually it), using this command:

# portinstall -P teTeX

Much more convenient if you're in a hurry, on slow hardware, or both.

Free and OpenBSD also have the best documentation I have read for any Free OS (HP-UX has the best overall - I usually consult it when I want to find out things about POSIX), but if you don't actually read it, then you won't understand how things work - coming from Linux and complaining when things don't work the same way won't help you.

Re:Why Linux?

[norton_I]

No, it is simple. Anybody you give the software to you have to give the source to. If you give modified GPL software to a coworker, your employer, or some dude named Bob, you have to give them the source. Any of those people who accept the GPL are allowed to distribute it further, but your obligation is satisfied, regardless of who the code eventually makes it to. Nor are you ever under an obligation to return your modified code to the original author unless you give that person modified binaries.

You are free to create a screw-the-GPL club, but you cannot actually bind the members to not redistribute the code. To do so is to not accept the GPL, and without agreeing to it you are prohibited from distributing the software to anyone. Other than that, creating a club of members who voluntarily share modified versions of a program and do not redistribute it outside the club is within the letter (and mostly the spirit) of the GPL.

What IS ambigious (and supposedly addressed in GPL3) is whether letting someone use a program on your computer counts as distributing it to them -- the "ASP loophole". This is a whole bucket of worms that I sincerely hope the FSF thinks clearly about before making a decision. I suspect that a court would decide that allowing someone to run a program on your computer counts as a performance, not a copy, however public performance is protected by copyright law, so the FSF is free in principle to put whatever restrictions they want on that as well.

Re:Why Linux?

[MrCopilot]

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

Philisophically, You are an ass. Embedded are Developers are Developers first, Linux Developers Second, Embedded Linux Developers third. Except for the few that are being trained by GreenHills and VX, most embedded Linux guys used to be Linux Guys.

I don't know if you have heard, but we like to share. We like our products to live and grow. We like to create flexability and freedom.

But, I say freedom you say IMPRISON. What are you afraid of, people (shuddder) seeing your code? How am I imprisoned by acknowledging other peoples works? How am I imprisoned by allowing my users the freedom to edit and modify thier code?

Oh, I see I am imprisoned because I cannot deny my users that flexability. I cannot hide my mistakes, vulnerabilities. I can hold out updates for cash. I'm not free enough to imprison the user!
I don't want to be that free. I don't want my code that free. I don't want IBM that free. I sure as hell don't want my code turned into some rebranded product with no acknowledgments of the efforts of myself and others.

Surely you can understand these chains bind me to the rest of humanity. Didn't they teach sharing in your preschool.

End Rant.

Re:Why Linux?

[Eisenfaust]

I'm currently using uCLinux on a development project I'm working on. uCLinux is some what unique in that it will function without a memory management unit (MMU). This basically means there are no virtual memory and all physical memory is accessed directly. Right now my entire ram image is about 1.5MB. Cheap 32 bit Microcontrollers are readily available these days and they are perfectly capable of running uCLinux.

uCLinux is free as are most tools required to develope for it. Most RTOS vendors ask a pretty hefty upfront price which isn't ideal if you aren't even sure if their product is right for you.

I'm running on an ARM7TDMI core which run at 60Mhz. CPUs such as the one I'm using are available in quantities for about 10 dollars a piece. The Gameboy Advance uses an ARM7TDMI CPU and people have Linux up and running on it.

Our biggest challege will be getting uCLinux to meet the timing requirments of our application. I will say that for designs in which most or all of the operations have rigid time require Linux is probably not the best choice. Our design has a small realtime portion mostly involving board level I/O but the ethernet/tcp portion doesn't have any requirements different from a normal server. Linux seems to work very well with this type of design. For an anti lock brake system it seems the easiest thing to do would be not to use an operating system at all (I don't know much about antilock brake systems so I may be misjudging their complexity)!

I've not done much investigation but I believe NetBSD/FreeBSD/OpenBSD require an MMU to operate. Windows CE also requires an MMU.

I must add how nice it is to have all the source code available for trouble shooting of problems. I can easily grep the entire uCLinux source tree and find out where things are actually happening!

Re:Why Linux?

[Mancat]

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

Most ports have multiple mirrors. Some don't. Looking at the MPlayer port, it's listing 10 mirrors. Maybe you didn't wait long enough for the first to time out.

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

Because csh is the traditional BSD default shell. Don't like it? Use bash then.

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.

Read the man page for 'powerd' Loading the cpufreq module doesn't automatically enable scaling.

You can't call FreeBSD worse if you haven't even figured out how to use it yet.

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.

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

[patcito]

uclinux is great for embeded. Also you probably have linux in your home router if you have one. Linux on handheld.org is very neat too.

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

[Orrin Bloquy]

Task specific operating systems like TRON and its variations take only few kilobytes, and are extremely efficient and reliable in what they do.

Well, you have to remember that was before we used real ray tracing on those light cycles.

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

[moro_666]

i'd still like to see a cutdown linux which can operate on a handheld like the hp/compaq ipaq. i know something exists right now but it reminds me more of like playing with fire than getting a solid linux machine in my pocket. currently the devices run with windows-ce and i don't like the idea having this thing in my pocket at all.

ofcourse really tiny devices that have less memory than pocketpc's should choose probably something else to operate on. linux is getting more complicated each day to support new hardware and new software ideas, it's impossible to fit this everywhere.

Re:not really key area for linux

[Executive Override]

Yes, therefore no more research should be done in this area. :-)

And from wikipedia:

TRON itself does not specify the source code for the kernel, but instead is a "set of interfaces and design guidelines" for creating the kernel. This allows different companies to create their own versions of TRON, based on the specifications, which can be suited for different microprocessors. The specification of TRON is open, but the code generators are not required to make their source free unlike with the GNU General Public License. The TRON project permits the source to be protected and closed from the standpoint of intellectual property.

Which I think means most TRON systems are proprietary, and makes the idea of embedded linux even more interesting.

Re:not really key area for linux

[TheRaven64]

If the device has an MMU, you might have more luck getting NetBSD onto it - there's even an eBook floating around telling you exactly which bits of a BSD OS need modifying to support a new platform. NetBSD still runs quite happily on 68K hardware (so does OpenBSD, for that matter), so it should work okay.

If you want a cheap Linux handheld, I can thoroughy recommend the Nokia 770 (rubbish name, great product). The developer environment is available for download, and it runs a fully open stack (Linux, X11, GTK).

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

Re:not really key area for linux

[moro_666]

right after they add a normal keyboard to it and gsm/gprs support :p , if i have to use a cellphone to do things that a modern gsm enabled pda can do, i obviously come 1 pocket too short.

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

[utnow]

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

This was undiplomatic at best. If you know something better than someone else... then just explain to them where they're mistaken. There's no need to be an lemur's ass about it.

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.

Good Books on the Subject

[SlashdotOgre]

I know this isn't Ask Slashdot, but does anyone have recommendations for good books on the subject of embedded systems? I was actually at Barnes & Nobles today and found two books: "Embedded C" & "Programming Embedded Systems in C and C++". I will be finishing UCSD in December with a BS in EE, and I have an opportunity to join a UC funded research team in a position which will require a lot of work with embedded devices (of which I have very limited experience), and I could use any advice on getting into the subject. It's expected that I will be learning on the job, but any suggestions would be appreciated.

Re:Good Books on the Subject

[patcito]

here oit is http://www.google.com/search?q=linux+book+embeded& ie=UTF-8&oe=UTF-8

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:Good Books on the Subject

[Anonymous Coward]

If you want to start with real-time operating systems, "uC/OS-II, the real-time kernel" from Jean J. Labrosse is very good. The book includes the OS, which is used in a lot of projects.

Best regards and happy reading.

Re:Good Books on the Subject

[phusg]

A respected Dutch lecturer in Real-time systems I know recommends Alan Shaw "Real-time systems and software" ISBN: 0-471-35490-2. Personally I found it a bit heavy on the maths (he suggested I start out on Doing Hard Time ISBN: 0201498375), but if you're going on to do University research then you'd probably better get used to it! ;-)

But...

[Anonymous Coward]

...does it run Linux?

Oh.

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

[Anonymous Coward]

everything else, like file systems, drivers, and networking, is in user space and preemptable.

AFAIK, device drivers are in kernel space in QNX (it's a ``hybrid system'' rather than a ``pure microkernel'', if you happen to be a member of the sect).

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!

Re:Wow, I'm Impressed?

[drxenos]

I've been a real-time embedded programmer for years. You seem to have a misunderstanding what "real-time" means. It does not mean really fast. It means you have hard dead-lines that must not be missed. The amount of time can be any required. You can have a hard dead-line of several minutes to hours. That is why having a good RTOS is so important. It is not, necessarily, important to have really, really fast context switches (though faster is always better). It is important that they are always deterministic with respect to time. Determinism makes it possible to prove you can always meet your dead-lines.

Re:Wow, I'm Impressed?

[redwraith]

I can confirm this. Or at least I could eleven years ago when I worked on QNX :)

Sad to hear that they have been acquired and dumbed down. QNX was a very cool system. I was involved in a beta program for their lightweight X-windows knockoff Photon, and I seem to remember the president of the company occasionally chiming in on the message boards. Good times.

Funny though. The world was supposed to be all microkernels and RISC processors by now. Just not the case. Linux on PowerPC is a pretty cool thing tho :)

Hard realtime for the Joint Strike Fighter

[Anonymous Coward]

I looked at the list of papers and it reminded me of a Linux1394 article I read several years ago where FSM (Finite State Machine) Labs used the linux 1394 stack to provide an IO/Sensor feedback and control network to Pratt and Whitney for their Joint Strike Fighter engine test stand. The system provided full environmental control of the engine under testl The Pratt & Whitney engineers said they were very impressed with Linux's 1394 stack and it's real time ability to move literally hundreds of gigabytes of data in a very short time without hiccups or problems of any kind. That article was here: http://www.techweb.com/wire/26803973

OT: SCALE 4x Call For Papers Extended Through Dec

[Anonymous Coward]

Antoher Linux conference, SCALE 4x, is currently seeking speakers and .ORGS for their 2006 event. The call for papers has been extended through December 3rd. Non-profit organizations and open-source projects can sign up for free booths on the expo floor.

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?

Re:You are wrong

[ClosedSource]

My point was that less hard real-time software is being written today relative to non-real-time software than 10 or 20 years ago. I don't know the details of the software running in cars but I doubt that it's hard real-time. The fact that you used the word micro-processor rather than microcontroller suggests to me that you may not be all that knowledgeable about it either. If you are, then maybe you could expand on the details a bit.

Re:You are wrong

[Mindjiver]

Doubt you will read this though but..

Fair enough, it might be more microcontrollers than microprocessors. I was a bit unprecise when I wrote the comment.

Software in cars? What do you call airbags, anti-lock brakes, traction control, which are all controlled by software, if not hard real-time! The move towards drive-by-wire would not be easy without hard real-time software as well. Fly-by-wire as implemented in Airbus airplanes are all hard real-time. Then we have GSM/3G communication networks, all using real-time software, further we have computer that control processes in steel mills and such.

But the number of applications using real-time software have also increased, but not perhaps as much as for "normal" applications.

Re:You are wrong

[ClosedSource]

Saying that real-time software was completely dead was perhaps overstating the case, but I think the use of dedicated microcontrollers implementing a single function and specialized hardware has made the programming effort less complex than in the past. That's as it should be.

A single microcontroller in car probably represents less than .1% of the overall cost. Why not have more than one and improve the safety and lower the cost of developing the software?