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

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.

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.

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.

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.

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

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

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.

Re:No kidding

[Anonymous Coward]

The problem is that there's actually three types of embedded systems - resource starved, resource constrained, and resource abundant.

Three decades ago, these types formed a continuum - there was little difference between the largest "resource starved" system and the smallest "resource constrained" system, with a similar blurring at the border of constrained/abundant systems.

Over the years, though, gaps have appeared and expanded between these categories of systems. "Resource starved" systems haven't changed much - they're still at the low end of the spectrum, in terms of system resources like processing power and memory. On the other hand, "resource constrained" and "resource abundant" systems have seen components that provide more significant system resources showing up on the market at roughly the same price point as in previoud years.

For "constrained" and "abundant" systems, the "minimum spec" hardware you can purchase for $X or $Y keeps getting more and more impressive. In fact, there's no reason to go fore something less powerful than the least powerful comodity on the market, because then you get into custom fabrication costs. At that point it's cheaper to buy 4MB of COTS flash storage than it is to buy custom-made flash storage that's just large enough for your device.

Anyone who's bought a hard disk in the past two years can probably identify with this... we've reached a point where the cheapest hard disk you can find is probably around $70. 2 years ago, that would get you a 20 gig disk. 1 year ago, a 40 gig disk. Today, an 80 gig disk... and you'd be hard pressed to find a COTS disk that is cheaper. All other things being equal, you would have to be nuts to buy an older model with less storage capacity for the same price as.

You can make similar comparisons for memory and static storage - for a constant price, as years have gone by, you're capable of getting increasingly more for your money, and the capacity provided what constitutes the constant cost "low end" of the spectrum is generally increasing each year.

Where does that leave everything? Well, in today's market, I'd hazzard a guess that you have:

• Resource starved systems using 8-bit CPUs, less than 4MB of memory and less than 4MB of permanent storage. These are the classic "embedded systems".
• Resource constrained systems using 16-bit or 32-bit CPUs, between 8MB and 64MB of memory and less than 1GB of permanent storage. These are "set top box" devices.
• Resource abundant systems, with 32-bit or 64-bit CPUS (potentially even SMP), with the potential of multiple GB of memory and hundreds of GB of permanent storage. These are "turn a desktop into a manufacturing control unit" type of devices.

As time goes by, these gaps will continue to widen. In two years, a low-end "constrained" system might have 64MB of memory and half a gig of permanent storage, and a low end "abundant" system might be have 2GB of memory and a 200GB hard disk.

While Linux will probably never move into the "resource starved" embedded system space, it has already moved into the other two spaces. As Linux gains more and more RTOS capabilities in the stock kernel, you'll see it's usage in the resource constrained and abundant spaces start to spread from soft real-time into hard real-time applications.

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

Alternatives to Linux/RT

[Anonymous Coward]

Linux was never meant for REAL real-time usage. Linux will never be suitable for real-time usage and more so, never for hard real-time; the kernel is simply not structured to be 100% predictable in it's code-paths, plays various tricks to speed things up and tries to be a very good alround system; and it does this wonderfully well if used correctly. It has 2 basic RT-like scheduling-clases, SCHED_RR (round-robin) and SCHED_FIFO (Fist In, First Out), where the application has more control about the scheduling-decisions.

Please remember: RT means NOT to be fast, but to guarantee certain worst-case-latencies under all circumstances, load and IRQ-storms.
If you look for an open-source RT-system, here you go:

1) my favourite, eCos from RedHat/ex-Cygnus.
It has a very, very sophisticated configuration tool (almost everything(!) you don't need is rippable from the kernel), has even a Linux-Compatibility-Module and so on

2) RTEMS is also free, configurable and so on. IIRC it was used to steer the cruise-missles. The configuration is a bit more complicated.

3) number three ... i forgot about it just this moment, sorry

If you want to pay, there is always:
QNX and VxWorks.

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?

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*

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

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.

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.