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."
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.
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
article
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.
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.
There is no one-size-fits-all in the embedded controller market. Linux has it's niche, but it can't fit everywhere.
"Eve of Destruction", it's not just for old hippies anymore...
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
Electronic Music Made Using Linux http://soundcloud.com/polyp
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?
Move along.
... lots and lots.
I work in embedded systems in Germany, and there is -plenty- of linux going on
Linux levels the playing field in grand new ways, even for the embedded folks, even for the snooty ones.
Dan will eat crow.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
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.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.
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.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
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...
Got Code?
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.
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.
http://www.masturbateforpeace.com/