Interest in Embedded Linux Remains Low

burnin1965 writes "According to EE Times interest in embedded linux remains low. I was surprised to see their headline considering I just purchased a Sony TV which runs linux and I assisted my brother in setting up an Actiontec DSL modem which runs linux. A few years back I had only heard of devices that ran embedded linux and now that they are starting show up everywhere interest is low? The survey did bring up three issues which should be addressed by the embedded linux community, whether those issues are misconceptions or actual problems. 1) Incompatibility with software, applications, and drivers. 2) Performance or real time capability. And 3) support."

Comments

They are actual problems

[BadAnalogyGuy]

Issue 1 is not a big problem. The programming model is well-understood, so at the application level there really isn't a lack. However, there is little support for specific stuff that hardware vendors may want to do (like say a CDMA RIL) and the implementation of those features is pretty difficult.

The second issue is a real concern. User experience is significantly degraded when the interrupt latency is longer than the expected reaction time. There are ways to reduce the interrupt latency in Linux, but the side effects are undefined.

Support is only an issue because it is so expensive. Likewise, there are only a few top-tier Linux vendors who can offer good support. Montavista, for example, is one of the premier (if not the premier) embedded Linux vendors, but they can't support everyone who wants to build a Linux-based embedded solution. They pick and choose their support contracts, and anyone not selected needs to find someone else with the relevant support capabilities.

Not surprising

[Wackston]

I work for a large CE company that is using Linux for a major TV-related project.

This, sadly, is very much an pointy-headed-boss driven decision. From the perspective of the HW/SW teams its just plain stupid. The problems are probably pretty representative why those 66% aren't looking into Linux.

Its gross overkill. Linux architecture is for general-purpose multi-user information processing loads. It does a whole bunch of things that are simply ballast for an O.S. that is there simply to control some special-purpose hardware and run a simple on-screen-display. Bigger micro, larger flash footprint, more on-chip RAM gobbled. This really really hurts in a genuinely cost-competitive marketplace. If you're building an Net appliance type of thing of course Linux is almost a turn-key solution. For embedded control... its the wrong kind of OS.

Licensing is a pain if you have non-trivial know-how you don't what to gift your competitors realised in your Firmware. You end up doing really vile hacks like doing stuff in user space via 'dummy drivers'. Debugging becomes fun fun fun....

The abstract machine doesn't fit. In the embedded control space sometimes the cleanest solution really is to do direct HW access. However, the hard kernel/userland divide of Unix O.S. makes doing this in a systematic, safe, way rather clumsy. You end up writing around a bazillion special-purpose HW-dependent ioctl's where what you really wanted was some selective access to the I/O bus. Then you need a HW workaround with hard real-time requirements and the 'fun' really starts.

In short Linux is a fine information processing /network O.S. for embedded or general-purpose systems. Its very far from ideal for one-off embedded/control applications.

big surprise.

[nblender]

Hardware designers generally start with an eval-board of some sort so they can hack up their add-on hardware and get something running on the bench before drawing schematics on napkins and starting to do a layout. As such, they need a 'board support package'. You generally buy that from an embedded systems vendor. You generally don't just download the latest linux kernel and start porting drivers and vm maps. Your management will likely want you to get a BSP from a commercial vendor to whom they pay maintenance so your engineers can hassle them about bugs in the bootloader, etc... Your choices are limited. Generally something like Montavista, Windriver, QNX. In my experience, Montavista makes it hard to do business with them. You practically have to bribe them to talk to you in the first place; even when you're waving around PO's. You've already bought the hardware from Intel or RadiSys and now you need support for the BSP. When you finally get a price, it's $18k per seat for a GCC license, and support is $5k/year; maximum of 5 incidents.

QNX on the other hand, will practically send an engineer on site to hold your hand while you get your BSP running. Support is cheap and the runtime licenses are down in the noise threshold.

Sure, QNX has a few issues. So does VxWorks. But Linux is a real lose, and I've tried.

Frankly, if I was starting from scratch and rolling my own BSP, I'd choose NetBSD. Embedded friendly license, code purity, and it probably already has your processor arch.

Re:It's about economics

[ricklow]

You've got it exactly backwards. If you're going to make a million of something, you want the bill of materials cost to be as low as possible, whereas you aren't as worried about the non-recurring engineering. That's why Linux, with it's larger memory footprint, but lower development cost, is often non-competitive.

Look at the latest Linksys WRT54 router. They've abandoned Linux and gone to VxWorks, despite the huge up-front cost for WindRiver tools, but they can use half the memory chips. This is a big win on a large production run.

On a limited production item, you often can't afford commercial tools, because it will make the selling price of your product non-competitive. Just the price of one copy of the VxWorks tools will probably add about $20 to the BOM cost on a production run of 1,000.