Is (Embedded) Linux Worth The Effort?

Embedded Geek writes "Embedded Systems magazine is running an interesting story about building an embedded system (specifically, a diagnostic tool for auto mechanics) using Linux. Despite the foreboding title and tagline ('If your embedded system doesn't need networking and storage, porting Linux to your hardware may not be worth the effort'), it offers a balanced look at how the engineer implemented his solution and observations on each step. Interestingly, his discussion is as much about embedded design philosophy versus Linux's philosophy, pointing out where each meets or diverges. A nice read."

Comments

Wrong Question

[Euphonious Coward]

The right question to ask is, what kind of support does my application need? If it needs stuff that a simpler RTOS doesn't provide, and only Linux does, the choice is pretty easy, "trouble" or no.

But you don't need Linux just because you need TCP/IP networking. RTEMS has that, and so does eCos. Likewise, file systems. So, the real question is whether you want to run off-the-shelf programs that expect a full Posix environment. Furthermore, even if you do need a Unixy environment, NetBSD may be an equally good choice, or even a better one. (E.g. NetBSD works on lots of chips that have no mature Linux port.)

Asking the right questions is the only way to end up with the right answers.

Re:Linux is more than just networking

[Lurch00]

I agree with your post to a point, well, this point specificly:

Linux has been widely ported around the town and finding a lowcost CPU that can run Linux (and includes an MMU) is easy.. so theres less need for the ucLinux or other exotic forks. Plain Linux will work well and you in one swoop have drivers for almost any networking or multimedia chip made.

I truly fear (for the sake of the market, not my life [yet]) the companies that say "well, we'll take this processor, these support chips, then just slap linux on top of it and be done with it. After all, all the components we picked have drivers in the kernel." Without someone who truly understands all the pieces they're pulling together, we have the hardware analoge of much of the open source software built today - a mismash of tools in varying states of quality with some glue and new logic slapped on top. This leads to poor (well, I'll say "incompletely tested" ;-)) software, and would lead to a similar state in hardware.

I'm not at all suggesting that you should develop everything in house so someone understands it all, or that you need someone with a vast amount of knowledge covering all sorts of different chips etc to do embedded linux. But I do think if you're doing hardware integration using linux you should take every driver that touches the hardware you pick as your own. That means analysis, auditing, testing, etc. Many companies don't do this, and its a dangerous practice.

I think that there's truly a need for "trusted" platforms in the embedded market. That is, for a given SBC (single board computer) you can buy a BSP (board support package) that says here is a known tested and working configuration with a linux kernel on it. I think this is where the "exotic kernels" come in. Different projects have different needs, but most of them overlap with somebody else. So it makes sense to have a third party do the integration. This is the way it works with most commercial RTOS - how many companies buy the source to VxWorks, let alone patch and compile it themselves?

The government has finally figured out that (C)OTS (off the shelf) is the way to go, I wonder why so many companies still roll their own?