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

what's the meaning of this?

[gotem]

Linux support ends up being lower quality and more costly than the alternatives of using a homegrown operating system
why is a support from an open source OS diferent from a home grown one?

Re:what's the meaning of this?

[Shinobi]

Because, assuming basic competency, if you write it from scratch, it does _exactly_ what you want it to do, it's developed just the way you want it, and with the documentation that you want and need.

With Open Source, you can easily end up spending more time modifying it to your specific needs than it takes to write it from scratch, especially if the source you're looking at is using a method for doing things that is not suitable for your problems. Especially since lack of or inferior documentation is all too common among many projects.

Re:what's the meaning of this?

[mpe]

The people who wrote it will have the best understanding of how the system works.

With proprietary software these are likely to be the only people on the planet who know how it actually works.

If they happen to be sitting next to you, it is easy to get support.

Except in the case of very small companies the software writer is unlikely to be answering the "support" line. If the writer has left the company or was a contractor in the first place don't expect customers to be told :)

Re:what's the meaning of this?

[dgatwood]

Before I reply, I should disclose that I'm a minor stockholder in an embedded Linux company, so my opinion may be biased. There, now that that's out of the way....

Most embedded Linux developers do just that: they write their own system on top of a Linux kernel. The value-add from embedded Linux companies is having people with more Linux kernel experience porting Linux to your custom hardware.

The article's author shows a lack of understanding of the future of embedded systems. In the past, he would have been correct. Most embedded systems were historically devices where safety was a concern and real-time performance could mean the difference between a robot actuator arm killing an employee or stopping in time.

However, most modern embedded systems tend to be consumer devices---set-top boxes, iPod & friends, kiosks at the mall, video game consoles... the list goes on. These systems are where embedded Linux makes the most sense.

Think about it: you could buy an embedded OS, pay a per-unit royalty on every product you ship, pay extra money for a TCP/IP stack, more money for that driver you need, etc. and STILL possibly have to spend man hours porting it to your custom hardware. Alternately, you can go with Linux and pay up front for a cross-development kit, technical support, etc. and have someone ELSE port it to your custom hardware, generally pay no per-unit royalties, etc.

It's easy to see why old-world RTOS vendors are running scared. Linux offers more for less money, and frankly, people like this article's author will run all sorts of negative articles to try to stop it, but in the end, an RTOS vendor trying to stop embedded Linux is like a small animal trying to stop a buldozer. Short of some new environmental protection, it's not going to happen.

That's not to say that there isn't room for traditional RTOS vendors. I wouldn't want embedded Linux running the fly-by-wire systems in a jet aircraft. I wouldn't want it running automation at a manufacturing plant (at least at a robot unit level... managing a production line, maybe). I wouldn't want it running my digital watch.

Both sets of products have their uses, and I think the market as a whole would be much better off if RTOS vendors would focus on improving their products to try to compete with each other in the real-time space rather than trying to spread FUD about Linux and trying to pretend that soft real-time isn't good enough. For the types of devices that embedded Linux targets, soft real-time performance is more than adequate, costs less, requires less programming effort on the manufacturer's part, and often results in a faster time-to-market as well.

The two classes of products aren't competing with each other, hybrid Linux/RTOS designs notwithstanding, and in the case of those, most of his arguments are, in fact, outright lies. In short, this article has been moderated 100% troll. *sigh*

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

[AndroidCat]

I'm not sure if the "give it away and make money on service" model will really work for small development companies. While being able to charge for support would be nice, most small companies don't have the people to handle it.

I've also seen what happens to a company that suddenly changes its income model from selling software to supporting some very large clients, and it's not always pretty. ("Why yes, we'll uproot an entire development team and have them live out of a suitcase onsite for a couple months--as long as it takes!")

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

[mpe]

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.

If Joe CEO want's this kind of support for anything then they had better be prepared to pay for it. As for this support comming from the company who made the widget this isn't usually a condition with anything else so why should it be with software. Anyway when it comes to proprietary software all you know is who supplied it to you. Did they actually write it? Did they buy it from someone else? Did they buy it from somewhere else and hack it about? Only with OSS do you have any way to find out who actually wrote the software.

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.

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

[Prior Restraint]

The way you describe things, support contracts sound more like an insurance policy. "Pay a periodic premium, and you're covered in the event of unexpected blame."

This is not to suggest you're wrong; I happen to believe the single largest factor in day-to-day business decisions is blame-avoidance. Someone pauses by my cube and asks my opinion on some random issue, and an hour later I get CCed on an email with the phrase, "I consulted with [my name], and he suggested I...". Meetings swell with extraneous attendees to ensure anyone looking to fling blame about will find no one in particular to strike.

It's really fascinating to observe, if you aren't emotionally invested in the incident.

This guy sells his own stuff?

[BoldAC]

Founded in 1982, Green Hills Software Inc. is the technology leader for real-time operating systems and software development tools for 32- and 64-bit embedded systems. Our royalty-free INTEGRITY(R) RTOS, compilers, MULTI(R) and AdaMULTI Integrated Development Environments and Green Hills Probe(TM), offer a complete development solution that addresses both deeply embedded and maximum reliability applications.

http://www.ghs.com/news/230325c.html

Doesn't this guy sale his own embedded options?

Wouldn't he push his own product over linux?

What am I missing?

AC

Re:This guy sells his own stuff?

[justsomebody]

This makes him an expert in the field. Although he may be biased, he knows more about this market than 99.99% of the population

This also makes him more biased in this market than 99.99% of the population;)

Re:This guy sells his own stuff?

[Stiletto]

I have to use the Green Hills compiler / debugger tools at work.

Trust me, they SUCK.

I could go into many examples of how the product is inferior to even a bunch of xterms running vi and gcc. From dongle/license frustration to waiting twice as long for builds than, say, gcc/make, to getting the right bit of magic scripts to work with their probe, I don't think there is one redeeming thing I can say about it.

Of course this guy is going to disrespect gcc and Linux tools. His own product is horrible.

Not in asia

[Anonymous Coward]

article

Look who the author of the article is

[Anonymous Coward]

Dan O'Dowd is President and chief executive officer of Green Hills
Software,Inc.
Green Hills sells compilers and RTOS for embedded
systems. (They have been the market for a long time).
No wonder he does not like Linux.

Re:Look who the author of the article is

[October_30th]

Being a competitor does not make him automatically wrong. In fact, one might say that he's an expert on the matter.

Re:Look who the author of the article is

[leinhos]

... with a clear conflict of interest, as well as a biased point of view. Even if what he says makes sense, selective presentation of facts can be used to support any conclusion.

Re:Look who the author of the article is

[k12linux]

I would have been satisfied if the mini-bio at the bottom of the article had said, "Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc., which sells real time operating systems. (Santa Barbara, Calif.)" Or, preferably some type of disclaimer early in the article.

I'm certainly not saying he shouldn't be allowed to write an article. Just that, as it is, readers may not know there is any type of conflict.

Re:Look who the author of the article is

[Shinobi]

So? Slashdot links to stuff from pro-Linux biased people all the time, without any such disclaimers either. The really annoying part is that noone whines about biased PoV then....

Re:Look who the author of the article is

[ninejaguar]

So, why waste time reading questionable and logically faulty arguments from a competitor's clearly biased and conflicted opinion piece? That's what's called a commercial. A boring one at that. I'm simply peeved that my time was wasted reading the drivel. This is definitely a case where I could've simply skipped the article and read the comments on slashdot first. I would've at least have run across the warning of the author's conflict of interest and moved on to something relevant.

= 9J =

Well. I'm not too surprised..

[Czernobog]

I had to work with Lineo Linux and a cross compiler (from a British company, the name of which I can't remember right now) on porting Apache (of all things...) on a MIPS/RISC board.
I have to say I was fairly underwhelmed by the whole experience and the quality of linux-related knowledge and support out there.
Mind you that was 3 years ago.

No wonder he said this...

[PlanetX 00]

He is from GreenHills software look at all of their OS offerings and you know why he is saying this. Linux is eroding his bottom line.

Well

[DAldredge]

So let me get this straight, a person who sells a competing product says that a less expensive product is not as good as the one he makes.

I also love there support for Native Win32 processors as you can see on this page. http://www.ghs.com/products/rtos/threadx.html

Re:Well

[sik0fewl]

Yes, it's really disappointing that they don't support the Intel architecture.

Oh well, I guess I'll go with Linux, I know it runs on the Intel architecture.

Re:Well

[dasmegabyte]

So let me get this straight. A person who works in the embedded market makes a comment on the embedded market and he's automatically wrong because he works in the embedded market?

Is it at all likely that the guy has worked with Linux himself and had it turn out badly? Or that his customers have come to him with cobbed solutions based on Linux? Is it possible he wanted to support Linux, but found so little quality development in his segment that he realized he'd be doing most of the work himself, AND have to support a community, AND not be able to make as much money off of the work?

The party line is that Open Source is always better than proprietary software. And in some case I've found that to be true (apache, blender, bsd, firebird). In other cases, I've found Open Source solutions to be sorely lacking when compared to their proprietary competitors (bind vs djbdns, sendmail vs qmail, Gnome or KDE vs OSX ;). In those areas where Open Source isn't ready, I support and suggest to my clients non-Open solutions. Why? Because they work better. Which means my clients come back. They don't come back if I suggest something that's complete, insecure, hard to use shit, but has FSF approval. That kind of brainless advocacy would make me look bad.

Look, I'm not saying this guy isn't a sleaze trying to sell his own products. But he doesn't mention them in this article...and he's not the only guy who sells products in the embedded market. He's saying that, in general, Linux isn't there yet, and he's as much in a position to say that empirically as he is to benefit off saying it without basis. What, can a market analysis only be true if it comes out of Stallman's mouth?

Re:Well

[bit01]

What, can a market analysis only be true if it comes out of Stallman's mouth?

Short answer? Yes. People have become far too innured to commercial propaganda masquerading as commentary. That's all it is. Propaganda. Selective quoting and sometimes complete untruths. The vast majority of commentary from industry "leaders" (90+%) is just self-serving crap with no attempt at balance. Generally, journalists are a little more objective though many are just marketting front men. At least Stallman thinks a little more deeply than most "commentators".

More specifically: I've used both Greenhills VxWorks and Linux on major projects. Linux leaves VxWorks for dead simply because it is open source. While Linux doesn't have the polish and finish of VxWorks the per-copy licensing of VxWorks and the need to deal with buggy, unfixable closed source binaries is a major pain that now puts in the bin as far as I'm concerned.

Their support is also a joke as well. They have a support website with login restrictions that make it impossible for a large company to use effectively. Why they need login restrictions for support of their own product is beyond me. And when you get in you find it's just a disorganised collection of essays, a minimum of downloads, a poor search engine and a completely useless support team - while they respond to emails they don't actually do anything useful, just do the search for related material that you've already done yourself. Heaven help you if you actually need any code fixed or changed - it'll take months.

More generally: I've been on the client end of dozens of different software support contracts while employed by large companies. Almost without exception they cost a bomb, provide a minimum of service, are completely inflexible, always assume a problem is your fault not theirs and have multi-month turn-around times. That experience has pushed me firmly into the open-source camp. Closed source software after-sales support is vastly overrated and I have the experience to prove it.

While your general point (closed source is sometimes a better option than open source) is of course true, it's true much less often than most commentary implies. Of the examples you gave I would say only OSX is the only potentially better closed source solution and that depends on the client. For all the others open source is better. For me, interroperability with existing software or hardware is pretty much the only reason left to get closed source.

---

It's wrong that an intellectual property creator should not be rewarded for their work.
It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
Reform IP law and stop the M$/RIAA/MPAA abuse.

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.

Re:Your application has to need Linux.

[Apreche]

http://tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.htm l

Itron, the #1 operating system in the world. Untouchable in the embedded world. Linux is nice because it makes interoperability with the desktop smooth if you have the same OS on both. But in terms of quality ITRON is #1 for a reason other than marketing (which is the reason Windows is #1).

Microsoft has a big lead in embedded too

[MrDigital]

With both Windows CE for small applications and Windows XP Embedded for more demanding apps, Microsoft has been making a strong push for what's an extremely hot market. With everything getting smaller and smaller embedded OS's are going to be far more important.

It's not free but the developer tools for embedded Windows devices are extremely similar to those normal Windows, so developers have less of a hard time migrating.

Re:Microsoft has a big lead in embedded too

[codepunk]

Oh yea just like when blaster hit us and our machinery quit working becase CE go smoked by it. Yep sounds like perhaps we should use xp or ce in medical equipment as well....

He's biased, his company sells an embedded OS

[Anonymous Coward]

Go to his company's web site (search google
for Green Hills Software) and you'll see that
they make an embedded real time OS. He's hardly
an objective reporter. This is basically an
ad for his company disguised as an editorial.
Not to say that his arguments are wrong but
take everything he says with a grain of salt.

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 ...

Re:Reliable unbiased article, not !

[EulerX07]

From that page : "Microsoft Windows, MacOS, Unix, and Linux often crash, lock up, or go crazy."

Woah, these guys would have a field day on slashdot fighting all the zealots from all the sides simultaneously.

One thing that they do not mention in their little glorification, it's that these OS have to support thousands of devices, poorly written drivers, 3d graphic cards in conjonction with directx/opengl, run that recently released game that is really cool, and more.

I'm pretty sure any of those systems would be rock solid if they stripped EVERYTHING out of them.

Where are the Linux devices?

[NineNine]

That's great that Taco included the link to Linuxdevices.com, but I went to look, and they were mostly stupid consumer gee-whiz gadgets, or some Net tool (ie: router). What IT people don't seem to understand is that there are many, mayn industries out there that dwarf the IT industry. "Embedded" OS's can be used in all kinds of devices in all kinds of industries. I didn't see a single manufacturing tool using Linux as an embedded OS, for example. So other than the "this is neat, we're using Linux" devices, where are these real world applications?

No

[glenrm]

Embedded Linux Tools Market a Myth? No. When I read that Wind Rivers was looking into Linux you knew which way things were going.

Rio Karma runs Redhat's ecos and kicks butt

[linuxguy]

I sold my iPod and bought a Rio Karma. Finally
after 5 mp3 players I have one that I think I will
keep for a while.

I am not going to do a review here as there are
plenty of good reviews of this product on the web
that google will help you find.

However to me this truly remarkable embedded
device based on a free OS says a lot.

This is Industrial Flamebait.

[torpor]

Move along.

I work in embedded systems in Germany, and there is -plenty- of linux going on ... lots and lots.

Linux levels the playing field in grand new ways, even for the embedded folks, even for the snooty ones.

Dan will eat crow.

Processor support and realtime

[fatwreckfan]

"For embedded use, Linux must be ported to appropriate processors and modified to work in diskless, resource constrained, and custom hardware environments. Real-time performance capabilities are also often required."

Sweet jesus no! Not different processor architecures! Apparently this guy hasn't heard of Debian.

And real-time capabilities? How about the Real-time Application Interface

This guy simply sounds like he has a grudge against GNU and Linux.

Re:Processor support and realtime

[The Bungi]

Sweet jesus no! Not different processor architecures! Apparently this guy hasn't heard of Debian.

The embedded market is full of wacky microprocessors made by companies you've never heard of, with wildly different clock speeds, alignments and memory and I/O interfaces. These are chosen by device makers and integrators based on their needs, and then put into things other than desktop PCs and PDAs. Your ridiculous snide remark aside, I suggest you at least Google a bit before posting. That will help you understand what it is the article is talking about. The Debian ports collection indeed.

This guy simply sounds like he has a grudge against GNU and Linux

He has a differing opinion from the slashbot group think, so I guess that makes him evil. "Oh look, he's criticizing Linux!!! let's kill him!!".

And the fact that he runs a company that makes an embedded OS is besides the point - it's made clear in the article and gives him credibility to talk about the subject. You're more than welcome to disagree, assuming you understand the subject to begin with.

Re:Processor support and realtime

[Svartalf]

In actuality... Anyone considering the use of most of the RTOS choices out there are typically looking at one of the following CPUs:

x86
PPC
ARM
MIPS
Coldfire
DragonBall

The goof-ball stuff usually ends up using the roll-your-own stuff and is not typically used in most contexts because you have to find silicon, find tools to begin with (since it's custom, there's no standard tools- uh, gee whiz, what do you know, you have to build tools, just like he said...), and you have to certify the operation of the damn thing.

It's simpler and easier to use an off the shelf part from one of the usual suspects than to use something else.

Now, having said this, you've got choices, depending on what you want to do because you've got standard tools and standard operating system choices...

VxWorks
QNX
Lynx
pSOS
RTEMS
eCos
Linux

Of the aforementioned, the licensing on the last three are very attractive and depending on what you're trying to do, you really want to use them instead of the others.

The article from the author in question is guilty of lying by omission of key facts in the embedded systems industry. He's right about all of it. But what he doesn't tell you is that for most everything done, you're either not using an OS and using something like a PIC, Z8, or Z80 or you're using a more robust CPU with an OS and much more memory- something that Linux, RTEMS, and eCos do well with on most counts for embedded systems. IF you know what you're doing in the first place- you have do design your code for read-only conditions, etc. in the first place and most of Linux is happy fine with it. I know, I DO embedded Linux stuff. Real time? Don't need it all that often- most embedded devices just need memory and resource management, they don't need rate monotonic scheduling of tasks, etc. Real time is actually bandied about far more than is really, really needed- and worse yet, it's more defined by the box you draw around things. Throw enough CPU and memory Muscle at something and even Desktop or Server NT can be "real time" for the purposes of the definition.

This is a marketing white paper

[dtidrow]

The author of this 'article' is the president of a company that sells embedded RTOS's and related tool - therefore, he's biased to begin with. Most likely, he sees his company's market being deeply penetrated by Linux and is trying to stop the erosion with this article.

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.

Re:I'm using embedded Linux right now

[barawn]

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.

Realtime performance means fast interrupt servicing, and this is the part I don't understand: uClinux gives interrupt latencies of about 10-40 microseconds to the top half of the interrupt handler, about 50-100 microseconds to the bottom half of the interrupt handler, and about 300 microseconds from interrupt -> data read if the bottom half is putting data through the I/O and another process is reading it. That's on a 66MHz system - so it's about a thousand clock cycles or so to the top half. That's not bad. Granted, other RTOSs are better - I've also used Microware's OS-9000, and that's got an interrupt service latency in the tens of microseconds, and that's even after using system events to signal another process. So that's really quite good. But depending on what you need, I can't see how uClinux could really hurt you that much. If you desparately need speed, try to put as much as you can in the top half, and you should get quite good performance. (Plus I think there are other ways to get the latency down, but I've never bothered, as it's never been important)

Plus having the source is incredibly helpful. You can actually figure out what the heck is going on in certain cases without wasting days upon days trying to talk to crappy customer support for commercial RTOSes. Ugh. Maybe if the project I work with had infinite money, sure, but...

No kidding

[JoeBuck]

EE Times regularly gives space to marketing droids to flog their stuff, and regular readers know how to distinguish these marketing puff pieces from the very good stuff that the full-time staff writes.

If someone at one of the embedded Linux companies asks, EE Times will probably be happy to give them equivalent space next week to answer.

Bizarre opinion.

[Performer Guy]

Seems downright bizzarre that anyone would suggest homegrown as a cost effective option.

IT is full of idiots yelling at the tide though, move along, there's nothing to see here folks.

Facts?

[McLoud]

The author exposes a lot of "facts" about using linux in embedded device, but doesn't open the tests made, which linux version he made the tests or with what kind of software. All the problem I've seen in software for embedded generally lies in bad written software, so what? I can make the same claims targetted at any SO/device and will this make that SO/device bad?

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.

What do you want your heart monitor to run

[codepunk]

For 200 points what operating system would you like
your heart monitor to be running?

1. Linux
2. XP Embedded
3. Windows CE

Survey says.....Linux...

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.

Re:Right and wrong

[red_gnom]

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).

Linux with RTAI on 150MHz CPU has no problem with delivering Hard Real-Time with jitter not exceeding 20 usec (It can be much less).

RTAI

RTAI Shedulers

RTAI: Real-Time Application Interface

No conflict of interest here

[decaf_dude]

From the article:

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

So I Googled for Green Hills Software and found that Green Hills Software is "The Leader In
Real-Time Operating Systems". Their Products page lists several RTOS, development platforms, debuggers, compilers, etc.

So much for disclosure at EETimes...

he is missing the point

[markov_chain]

The author points out several times that Linux, due to its general purpose design, is too inefficient/memory hungry/not real-time capable/etc. for embedded applications. However, he failed to account for the current trend of hardware becoming capable enough for those things not to matter any longer, especially in non-critical applications like Web interface for devices, home routers, media gateways, etc. The phenomenon of not coding PC software in hand-optimized assembler is spreading to high-end embedded devices.

The article is about Linux Tools, not Linux

[leinhos]

This article seems to be about commercial tools for embedded linux, and how the market is soft for such software products. A few of the posters here seem to think he is putting down Linux, but rather states that, in order to make money in software tools, developers need to go somewhere else.
From the article:

Because most embedded Linux users roll-their-own, that leaves less than half of the market to the six-or-so major commercial distributions. Since none of them is dominant, no specific integration is able to address more than 10 percent of the market.

The author's concern is exactly what kind of market exists for commercial sofware development tools for embedded Linux, not whether Linux is a good OS for embedded applications. He does take a few swipes at Linux, but they are in support of his thesis that, while embedded Linux-based system developers will need support (for a host of reasons the author presents, be them good or bad), but will not want to pay for them:

The obvious refuge for embedded Linux users is to seek support from a commercial supplier. Unfortunately, most embedded Linux users are not willing to consider commercial vendors.

The author concludes that, because there will not be a strong market for Linux-embedded support, there will be few vendors able to support Linux-embedded (and still make money) applications/development, and therefore the will be no market for anyone selling Linux-embedded development tools (emphasis mine):

As manufacturers recognize the real impact of embedded Linux, the tools market will dissipate. Those inclined to buy tools will abandon Linux. Those who stick with embedded Linux will have no interest in tools.

The author does not, however mention what percentage of developers are those that are "inclined to buy tools".

Can't Imagine

[WindBourne]

Why CEO's of competeing companies to Linux keep saying these things. They must be correct, since there are so many studies by learned people.

LOL ROTL.

Confused Article - yes, no market for Proprietools

[tz]

First, he seems entirely unaware of RTLinux which is a full speed RT layer that sits below Linux and has the reliable near-zero latency he calls for, and it is a commercial product (with an open source side).

IF you need that hard real-time, it is probably the best solution. The 2.6 kernel might be "soft" real-time, but again, that means quantifying the required latency.

For many things including lots of existing systems you need a smart peripheral or second small processor (like a UART with a FIFO).

Much of the rest is confusion.

First, it is easier to "roll your own" OR buy proprietary? He says that it would be to difficult to look inside the Linux kernel to figure out something (not possible with most proprietary OSes without a big $ source license), buy you can apparently recode the whole easily.

There are places where "roll your own" fits - I typically can do most things in careful interrupt driven events, and foreground (every N milliseconds) and background loops. When you get into task switching or MM, it gets hard.

If you are very limited, e.g. using existing hardware that doesn't have room and can't be upgraded, the proprietary uOSes are probably best. One thing to note - if he is comparing like to like, the proprietary OSes get big when you add things like network stacks and filesystems (which may not have things like journaling - can you scandisk your flash?).

The current "small" platforms run linux fine. ARM and MIPs (think Zaurus and AMD's PDA platform) are well supported, and there is uCLinux. Here again, if you can get beyond a certain hardware threshold, you can find a lot of things available.

His article was titled "The myth of the embeddedLinux TOOLS market". That is probably true in that most people are likely to prefer GCC to something else (or it would be nice if they took the same command line switches instead of having to redo complex compiler invocations just to use the proprietary version). And they would probably prefer to mix and match (use GNU ld and ELF or whatever the Linux target object format is).

But what does that have to do with Linux? Or Windows CE (which isn't doing too well either and has far worse timing and resource problems).

Support? It's there, but harder and probably not at the same level, but a Linux wizard isn't an Embedded wizard, and vice-versa and if you are already being cheap, you aren't going to pay me (who happens to know both spaces) what I'd ask any more than you would buy a support contract.

Let me summarize my perspective (I do embedded for a living).

1. Linux isn't a panacea, but is or can be an acceptable solution for a very wide range of embedded products. The rest fall into the custom or proprietary niches. Linux tends to get better and hardware gets cheaper. It also helps in many things having the desktop and target run the same thing.

2. The free tools (compilers, etc.) aren't broken, so the market for "good" or better tools isn't going to be large. A tool cannot correct a design error (trying to run Linux in 64K which seems to be his example). Specialty tools have a better chance, but not "Our proprietary IDE now can compile the Linux Kernel" type tools.

(Think filesystems - even if you had a "better" filesystem, it would have to be a lot better or have some critical feature for someone to want to pay for it instead of using one of the various systems already there).

3. There are add-ons and products in other areas that have a market - like RT-linux which can be used as-needed. There are prototyping boards and systems that come with Linux preconfigured with most of the configuration work done. There are consulting and support services - if you want or need to pay for them, and are competetive with the proprietary OS.

He is correct with the basis of his article - It isn't easy to sell bottled watter in the rain next to a public fountain. But his criticisms of Linux and of the development process and targets are way off. But he doesn't consider reasons for picking Linux legitimate though the engineers probably did consider things carefully.

Typical...

[jasno]

Hello, Embedded Developer here.

First, let me point out that the article was written by the president and CEO of Green Hills, a vendor of proprietary development tools and several RTOSes.

Second, let me point out a mistake made by many, many analysts when talking about 'embedded' linux. The 'embedded' market ranges from 8-bit microcontroller based devices, to PC style hardware, to cell phones and set-top boxes, satellites and mars rovers. So it is very difficult to come up with an assessment of any technology that applies uniformly to the entire space.

I've worked in practically every segment of the embedded market(DSP based consumer electronics, 8-bit control systems, headless PC's, set-top boxes, cell fones, networking appliances). I've used a variety of tools/solutions ranging from expensive and proprietary to free and open.

I recently had a client interested in using embedded linux for a cell fone design. They were put off by the $80k price tag for vxWorks, and so they decided to try linux. They were able to squeeze the system down to around 2MB on an ARM9/TI-OMAP. The realtime performance was acceptable. And to support the development they purchased several JTAG BDM debuggers. Its not that they were looking for a free ride, but $80k for a proprietary OS with limited features didn't seem like good business sense.

Also, the support I've received on mailing lists and IRC is above and beyond anything I've ever seen from a commercial vendor. In fact, I used to work for one of the biggest RTOS vendors around, and I found it more difficult to get answers out of my own company than the linux community.

Can you say "bias"?

[El]

Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc.

Gee... don't they sell non-Linux tools? Do you think there is any possibility that the author might have some bias on the subject of embedded Linux tools?

Yeah right

[soccerisgod]

If it's a myth, I have to say it's a pretty profitable one. All the money I've been making last year I've been making writing mythical software for an automotive company... If only there were more myths like this - I'd be filthy rich! :)

Why This Article is Stupid...

[13Echo]

This article is stupid...

Why? Because the author has HIS OWN operating system products and services at:

http://www.ghs.com/

In fact, this guy claims to be the authority on operating systems... Read on to learn just why you should choose their "INTEGRITY" product over Microsoft Windows, MacOS, Unix, and Linux, etc.

http://www.ghs.com/RTOSLeader.html

It's Andrew Tanenbaum all over again.

Glad we have an author here that can back his article up with facts, and not just crap.