Slashdot Mirror
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."
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?
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.
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
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?
Embedded Linux Tools Market a Myth? No. When I read that Wind Rivers was looking into Linux you knew which way things were going.
Onward to the Aether Sphere!
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.
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.
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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.
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/
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?
"Freedom means freedom for everybody" -- Dick Cheney