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.

Re:Of course not

[sadr]

In my experience (over 10 years of developing Real Time code on medium to large projects), it's almost never a win to write a home-brew RTOS (or try to do without an RTOS completely).

Except for very simple applications which can run as a single threaded application with interrupt handlers to perform processing, an RTOS is almost always essential. In fact, an RTOS with a correctly partitioned and architected application can be significantly more efficient than a single threaded application that has to periodically poll hardware or status variables. You don't want your protocol stack running in your interrupt handler, and polling to see if there's more data for the protocol stack is very inefficient compared to a context switch in an RTOS when data is actually available.

VxWorks may be overkill or may not be customizable to do what you want, but there are lighter solutions such as Nucleus, eCos (which is open source), RTEMS (BSD license), etc. These solutions are available for relatively small amounts of money. And this cost is a real win compared to the cost to develop and debug thousands of lines of "homebrew OS". And there's much more to the price of building an RTOS than just the developer time. Slipping a product by 3 or 6 months can cause the project to fail completely.

Even the ever-popular "write a homebrew abstraction layer" over a commercial RTOS is almost always a waste. It just introduces overhead, prevents the application from making full use of the underlying RTOS, and almost never makes porting to a new underlying RTOS much simpler.
In the meantime, it really sounds like your application has some serious architectural issues. If you're spending 15 seconds in your ISR, none of your other tasks (or lower priority interrupts) get to run. That's hardly "real time".

The more typical solution is to grab the data from the hardware and send it to a (high priority?) task to process. I find it very difficult to believe that running a single ISR for 15 seconds is optimum. On most systems I've worked on, that would trigger a hardware watchdog time-out.

Basically, it doesn't sound like you've got an competant, experienced embedded developer working on your project. You might consider finding someone to provide consulting services, or hiring someone with more background in the area.

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

Re:Use QNX for embedded work

[Anonymous Coward]

It all depends on what you're building. The projects I've been doing lately have something close to a real PC inside - because they actually need a big disk, a real TCP/IP stack with real network support, (QNX has issues with sockets, among other things) etc. So we run linux, and our clever method of dealing with hard-real-time is delegation. You need tight timing? Delegate that to a PIC or something. The PIC takes care of sync work and shares data with the PC-like system asynchronously over some flavor of serial bus (rs232, usb, ethernet, ...)

A success story

[BigDaddy]

The author seems intent of finding someone or some group that is successfully leveraging Linux in the embeded market. Why doesn't he check out LynuxWorks?
You may remember these guys from LynxOS. This RTOS (in true defintion of the term -- not in the LinuxRT version) runs on countless embeded platforms. Ever setup a JetDirect card on an HP printer? That's LynxOS.
Well, these guys are doing a lot with Linux now. I attended a talk about two years ago, right before their product BlueCat (strikingly similar to RedHat, eh?) came out. My information may be out of date, but some of the stuff the guys talked about was very cool. An embeded tool-chain. Boot loaders. And most interesting source (and later binary) compatability with LynxOS (by which I mean that LynxOS would run Linux source). To quote from the web page: BlueCat Linux applications can be migrated to the LynxOS platform with no loss of functionality and with minimal effort or delay. LynuxWorks development tools support both operating systems so there are no new tools to purchase and no new learning curves. This all means that customers can develop using BlueCat Linux and then quickly migrate and deploy applications to LynxOS when real-time needs emerge. Anyway, as I said, my info maybe out of date, but these guys shouldn't be overlooked. Oh, and for all who are wondering, I am in no way connected to this company.