Embedded Linux Tools Market a Myth?

nadamsieee writes "EETimes is running a story that proclaims that the embedded Linux tools market is a myth The author, Dan O'Dowd, sites variety of problems (challenges?) with embedded Linux ranging from poor real-time performance to lack of broad developer support. Dan concludes: "Considering all of the possible support avenues, Linux support ends up being lower quality and more costly than the alternatives of using a homegrown operating system or purchasing a proprietary one." Maybe Dan should check out the success stories at LinuxDevices.com or perhaps try a more traditional embedded OS that also happens to be Free."

Comments

The author has a point... as far as it goes

[j0keralpha]

The article is IMHO unnecessarily inflammatory, but the author highlights a problem not only for the embedded linux market but for the entire linux market. The lack of support for what are admittedly GOOD products is gnawing, and makes the enterprise usefulness of some of them fairly limited. You and I might be able to figure stuff out on our own, but Joe CEO wants everything he uses to be backed 24/7/365 by the company making it. And you know what? Hes right.

Re:The author has a point... as far as it goes

[lurvdrum]

Then let Joe CEO take out a paid for support contract - heaven knows there are enough companies getting into the Linux support game now. With all the money he saves avoiding proprietary operating software he can certainly afford it.

Re:The author has a point... as far as it goes

[EmbeddedJanitor]

I'm sure a Linux support contract would be lower cost than an Microsoft one or Sun, IBM,....

The biggest problem is that people get it into there minds that Linux==free, therefore they feel they're getting cheated when they spend any money on Linux-based services and software.

Your application has to need Linux.

[HotNeedleOfInquiry]

To throw Linux at any and all embedded applications is a big mistake. Unless you need stuff like multiple TCP/IP servers and multitasking, you are better off with a smaller OS. There are millions of DOS-based controllers out there that won't be replaced with Linux anytime soon because they are cheaper than the hardware needed to support Linux. Likewise, PIC controllers can do things cheaper than DOS controllers for trivial tasks.

There is no one-size-fits-all in the embedded controller market. Linux has it's niche, but it can't fit everywhere.

Reliable unbiased article, not !

[polyp2000]

The guy that wrote the article...

Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc. (Santa Barbara, Calif.)

Green Hills Software

Green Hills Software are a large RTOS manufacturer, so of course he is going to say that. Whether or not his statements are true or not I find it difficult to believe someone whose business relies on their own Proprietary OS.

They also have a not dissimilar marketing bumpf on their website

our product is so much better than everyone elses!

nick ...

I'm using embedded Linux right now

[Helmholtz Coil]

Good thing I read the article, now I know to drop the last two years' worth of work and get a "real" OS!

Sarcasm aside, while I could maybe grant that there isn't a very large market in commercial compilers for Linux in the embedded space, there is definitely a market for Linux itself in the embedded space.

I just finished a proof of concept project in December. Now that we're moving towards a commercial system, we're looking to reduce power draw and size. Because we're using Linux, I can switch to a different SBC with a different processor and architecture without too much trouble (the compiler toolset was provided by the SBC manufacturer, basically just a cross-compiling GCC).

My application isn't a real-time system, so I can't comment on whether Linux is applicable as a real-time OS, but on the other hand I need to be able to resolve time on the nanosecond scale, and Linux/GCC does that just fine. So despite the article I think I'll stick with what works for me.

He is right though

[scorp1us]

He is 100% right, provided it is 2003. The 2.6 kernel goes a LONG way in supporting the embedded segment. In 2004, average ram and flash will almost double, clock cycles will almost match that growth.

He is right about size - Linux is too big when compared to the competition.

What he does fail to understand is the real reasons people switch to embedded linux. Not for gains today, but gains tomorrow. EL (Embedded Linux) provides hardware abstraction, simplifies programming and opens you up to standard technologies.

The problem with most EL projects today is that they are ports of legacy systems. One will realize much benefit int he now if the start from scratch. Backwards compatibility is the problem here.

If you look at all the sucessfull EL prodects, 90% are new designs or use 20% or less old code. It realyl does shorted your TTM and maintance costs, if you don't bother porting old code.

In the end EL is about the future, not the now. But we must use it now to bring about the future.

I've worked on 2 embedded linux projects professionally, and those is my opinions.

Right and wrong

[Alinraz]

Ok, first my quals:
* I am an embedded programmer.
* I've used a variety of embedded OSs including both vendor (pay) and home-grown (free except for labor) and Linux.
* I love Linux. I use it at work and home as my desktop, and at work on servers. I have contributed to several projects including ALSA and gcc and binutils.

The way I see it, Dan is both right and wrong.

He's right in that Linux is not approprate for many "true" embedded applications. Most apps have very stringent memmory requirements, don't need most services, and work on severly limited chips (over 70% of all processors sold are 8-bitters). Also, Linux can not meet the real-time reqirements of many applications (feel free to flame me, but it is definately true, despite any "real-time layers" that have been added to Linux). For example, I work on a product that has 512k of SRAM, with a processor clock speed of 156 MHz, and it's "clock tick" has to be less than 40 usec (typical times of Linux include 5 msec). We use an in-house "OS" which isn't a true OS anyway, just a tightly coded main loop in order to meet our requirments.

On the otherhand, we have another "embedded" project that does use Linux. It is the best OS for the job in this case.

As usual in engineering, one must chose the right tool for the right job.

But, for companies that make development tools, we'd be a poor choice on that Linux system because it is highly modded and they'd not be able to support it econommically.

What it comes down to is embedded projects MUST chose the right tools for the right job, and Linux is not allways the right tool.

For embedded tools vendors, Linux OSs will be difficult to support for the very reasons that Dan mentions.

But this doesn't mean that there's no place for Linux in embedded or psudo-embedded applications (psudo-embedded apps look like embedded systems on the surface, but are usually full-featured general purpose systems on the inside. Think TiVo).

The Linux support I'd like to see from tools vendors is better tools on the Linux workstations. Support gcc and binutils for more processors or optimize the code output better on gcc. Help with gdb, insight and DDD to make your hardware emulators work with them on the workstation. I'm tired of having to keep a dual-boot system just to run VisionClick so I can debug my 5407 embedded systems.