Requirements for Embedded Linux

An anonymous reader sent in: "As Embedded Linux becomes established as a solid alternative to many proprietary OSes and RTOSes, demands on embedded Linux developers and providers are increasing. This detailed technical article by Nicholas McGuire sketches the top requirements for Embedded Linux systems including considerations of user interface, network capabilities, security issues, resource optimization, performance requirements and issues, and compatibility and standards issues."

Comments

An important concern they left out

[Anonymous Coward]

And that concern can make or break the deal (and potentially make or break the company): Licensing.

I used to work closely with a development team that made the transition from a proprietary (and, may I add, unmaintainable and unreliable) embedded OS to Linux. Though some of the concerns in the article did come up, especially speed and size issues, those didn't hurt us much. After all, we could afford a better processor and more memory with the money we saved on royalties and maintenance expenses - these were substantial.

Unfortunately, if the many features of Linux and the transition from assembler to C didn't hurt us, the licensing did. Things went very smoothly until we needed to make some big changes to the kernel to accomodate a newer version of our hardware. At that point, there was a schism in the group: some of the developers wanted to change the kernel and release the product without source (the "who would find out?" crowd) and the rest of us knew that Linux was not going to fit our needs anymore unless we wanted to give our work away to competitors.

Well, the "who would find out?" crowd won the first round, and because of release deadlines we "slipped" the kernel changes into the next version of the product. And nobody knew. Except one of us told the legal department about what happened and they became very agitated.

Now our software runs on embedded NetBSD. It wasn't quite as robust as embedded Linux but it works well and we really can't complain. Transitioning to a new OS took a lot of effort but it was a necessary evil. After all, we couldn't risk getting sued out of existence to save a little money.

But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications? It seems like this area of the market will never be dominated by Linux until companies can stop fretting about licensing problems and start concentrating on coding instead.

-Name withheld so I don't get canned

Embedded vs. "desktop" perspectives

[apk]

First off, it's an excellent article covering most of the issues that arise in embedded systems -- you should at least peruse it if you're going to comment in this thread. One of the biggest issues for non-embedded developers to understand is that each development task is somewhat unique -- different hardware, I/O requirements, cost targets, time to market, etc. It's not a [relatively] standard environment like that of a typical desktop computer. In fact, the vast majority of embedded devices are "headless" -- no keyboard or monitor, so support for video drivers and/or X only impacts a very small number of applications.

My company recently went down the path of evaluating several embedded linux suppliers, including Hard Hat Linux, LynuxWorks, RTLinux, and others. This evaluation was for an embedded communications platform.

There are many "real-world" issues that will arise when considering Linux instead of some of the more established embedded OS players (WindRiver/pSOS, Green Hills, Keil, QNX, et al -- see Embedded Systems Programming magazine for a pdf summary of embedded OS providers). These real-world issues, which will vary in importance among organizations for various reasons, include:

• Existing non-linux OS usage (e.g., WindRiver)
• Staff familiarity with Unix-like programming (most embedded developers know traditional RTOS-like architectures, not unix IPC methods or socket programming)
• Ease/difficulty with which already-written application software can migrate to a new OS
• OS support for preferred hardware devices (processor, communications peripherals, flash, etc. -- writing drivers from scratch isn't desirable)
• Internal corporate or organizational resistance to change (don't underestimate this one, folks!)
• Product life cycle phase
• Existing customer experience(s) with any previous OS-related behavior that may change under linux (customers like seeing behaviors they've seen before, not something new)
• Hard real-time versus soft real-time requirement(s)
• Communications stack and protocol requirements

In short, development in the embedded world tends to have many more complications associated with it. That's not necessarily bad -- in fact it often makes it more technically challenging and thus professionally satisfying -- it's just something that ought to be recognized, acknowledged, and taken into account when OS decisions are being made.

Andy

Embedded Linux Presentations

[Bill Kendrick]

The last two Linux Users' Group of Davis meetings have dealt with embedded Linux.

At our last meeting, a couple of cool folks from BlueMug in Berkeley came and talked about an embedded Linux prototype they built for a client (photos). Their presentation slide is also online here (2MB PDF).

At the meeting before that, Rob Wehrli of Arizona Cooperative Power came to talk about Clinux (photos). His presentation is online, too.

Enjoy!