Slashdot Mirror
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."
I developed an embedded device using NetBSD. I would love to use Linux, but the agressive stance of the GPL license (Linksys!!) keeps me away. I know many others that share the same view.
Linux won't take over the embedded world, mainly becuase embedded is a commercial market. Who wants to invest money in developing a product, only to have the open source community go after you? And you get bashed for trying to earn a living.
Before you flame me, I did make a good portion of the code used in my embedded device available to the BSD community. I won, they won. Nobody twisted my arm.
I'm posting AC, STOP KARMA WHORING!!!
TDT
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.
...without knowing it. as i've pointed out before you can download sources for Sony devices from here: http://www.sony.net/Products/Linux/Download/search .html
anyone got anything on the list? [hint: try under the 'game' section]
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