Living in a Linux Embedded World

krow writes: "Embedded.com is running an article where the author is making some assumptions of Linux's use in the embedded markets based on the opinion of one consultant and the fact that Lineo had to lay off some people this year. It's still interesting reading though for some insight into a different world for Linux and there is a nice reference in the comments to the interview of Victor Yodaiken of RTLinux fame by by Kevin Fu on the ACM site."

Comments

Of course not

[bluGill]

Most embedded componants that I know of use an in house OS. Where I work we bought vxWorks, but we are seriously considering replacing it with something cheaper. Not linux, something we write in house. It turns out that most real time systems cannot afford the overhead of a OS. Sure we need something to deal with hardware, and schedualing, and if you have networking it is nice to have sockets are similear. In the end though, a OS gets in the way more then helps.

In our particular case we have a lot of code to jump out of interupt context and then back in every 15 seconds. That really hurts performance. (Yes, we often want to spend more then 15 seconds processing interupts, with out hardware it turns out to be a good idea, though I don't want to give away why) Of course the OS clocks get all screwed up when we do that.

Linux's Slow Approach

[Catiline]

But to conclude or suggest that the product is inferior for starters because is not sending the commercial competitors to the pawn shop...thats bunch of malarkey.

I'm a platform agnostic. Sure, I'll ask people "why are you running Windows?", but I don't then immediatly plug Linux as the grand solution.

New users -and casual users- need Windows (or a Mac) so they don't have to worry about the details of configuring the system. Learning exactly how PnP works isn't something they are interested in. As long as the only thing they use the computer for is simple tasks -write letters or surf the net- Linux isn't for them.

And on the embedded scale, much the same applies. I use a Handspring Visor; all because I want a OS on my handheld that <i>gets out of my way</i>. The OS needs to pull up whatever app I need- be it the calendar or notepad or whatever- and then dissapear- because the more memory / processor / battery power needed, the more it costs, and the less I want it.

No system can be applied everywhere in the computing world and be the best solution everywhere. Linux has its' issues dealing with new users and embedded systems; this is not a flaw. Where Microsoft has failed is trying to write a system that can be used everywhere. It won't work; IMHO it <i>can't</i> work. Let's not drive Linux down that same road.

maybe RTEMS

[e4liberty]

My embedded projects usually don't need virtual memory or processes, just memory protection and threads. So Linux is overkill as well as being too slow.

On the other hand, the driver sources, the libm and libc, have all been useful starting points for either roll your own, or extending another RTOS.

If this sounds appealing, and you need an RTOS, look at RTEMS an open source RTOS with many ports.

Re:Kada

[JabberWokky]

Hey! Too bad that Java sucks my left nut, and is in no way suited to deal with real time applications.

I dunno about your left nut, or if there's a RT Java implementation, but you (and many people on Slashdot, I've noticed) have no idea what "Real Time Applications" are.

16 milliseconds to process a single RSA key?

As long as it does that utterly reliably, it could take 30 seconds to processes it - it doesn't matter. As long as the process can be reliably timed, and can be predicted to complete in a given timeframe, irregardless of any interruptions, task switching, etc. That's what real time means. Not "125 fps vs. 127 fps" or anything like that. A radar might have a refresh of 3 frames per second - but the system had better *damn* well be ready to process the input as it comes in.

--
Evan