Embedded Linux Tools Market a Myth? 290
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."
what's the meaning of this? (Score:3, Insightful)
why is a support from an open source OS diferent from a home grown one?
Look who the author of the article is (Score:5, Informative)
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 (Score:2, Insightful)
Re:Look who the author of the article is (Score:3, Insightful)
Re:Look who the author of the article is (Score:2)
How can you not see that? He's getting run over by a free and agile OS.
Re:Look who the author of the article is (Score:4, Interesting)
Re:Look who the author of the article is (Score:2)
Re:Look who the author of the article is (Score:3, Insightful)
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 (Score:2)
Sure.. but at least with Bill and Linus you KNOW where the bias is. Dan comes accross in his article as just some poor embeded Linux developer who has been burned by using Linux, has seen the light, and is just warning the rest of us.
Again, I'm not saying his opinions are valueless, or that they should simply be dismissed. What I'm saying is that a little more disclosure would have been appreciated. What's wrong with that?
Re:Look who the author of the article is (Score:3, Insightful)
= 9J =
Re:Look who the author of the article is (Score:2)
Re:what's the meaning of this? (Score:3, Interesting)
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 t
What Slashdot is saying (Score:2, Interesting)
And people accuse Microsoft of bias.
Re:what's the meaning of this? (Score:2, Informative)
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 ha
Re:what's the meaning of this? (Score:2)
Sivaram Velauthapillai
Re:what's the meaning of this? (Score:3, Insightful)
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
The author has a point... as far as it goes (Score:5, Insightful)
Re:The author has a point... as far as it goes (Score:5, Insightful)
Re:The author has a point... as far as it goes (Score:2, Insightful)
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-
Re:The author has a point... as far as it goes (Score:5, Insightful)
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 (Score:2)
Doesn't IBM provide support contracts for Linux-based systems?
Re:The author has a point... as far as it goes (Score:2)
Yeah. That's why Joe CEO calls up Red Hat and buys Enterprise Linux and a 2 year support contract. Support is out there for those willing to pay for it...
Re:The author has a point... as far as it goes (Score:3, Insightful)
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 t
Re:The author has a point... as far as it goes (Score:2)
You know, having 24/7 support doesn't always mean much. Here at work we use Rational tools (now owned by IBM). Sure, we have a big honking support contract, but you know what happens when I call them
Re:The author has a point... as far as it goes (Score:2)
I find it interesting that the PHB thinks that Microsoft stands behind their product, but knows better than to actually call up Microsoft as an end user and try to get help.
It's more of a BUSINESS decision than a technical one. The reason management does that is to mitigate risks. That is to say, shift the blame onto someone else. As the saying goes "No one ever got fired for buying from IBM" (I hope I'm getting the quote right)
Re:The author has a point... as far as it goes (Score:2)
DYT?
.sig
This isn't just a problem with Linux, it's a problem with the all platforms.
Bad support? Poor/buggy software? High prices and low quality?
I've heard that about everything.
Of course, not everyone says that, but the ones that don't are trying to sell you something.
-- this is not a
Re:The author has a point... as far as it goes (Score:2)
And where does he get that now? Certainly not from MS, IBM, CA, or any other vendors we deal with. We have to PAY for support like that. You can get 24/7/365 OSS support for less money if you're willing to pay for it. I don't know any CEO's with the mistaken impression that if they buy proprietary software there's going to be a company standing by to assist 24/7/365 and they're even starti
This guy sells his own stuff? (Score:5, Interesting)
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
No kidding (Score:5, Informative)
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 (Score:2)
Re:This guy sells his own stuff? (Score:3, Informative)
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.
Re:This guy sells his own stuff? (Score:3)
This also makes him more biased in this market than 99.99% of the population;)
Re:Green Hills, eh? (Score:2)
Sivaram Velauthapillai
Not in asia (Score:4, Interesting)
Well. I'm not too surprised.. (Score:3, Informative)
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... (Score:4, Interesting)
Well (Score:3, Funny)
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 (Score:2, Funny)
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 (Score:3, Insightful)
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 hav
Or... (Score:2, Redundant)
Come on editors - at least point out the conflict of interest!
Your application has to need Linux. (Score:5, Insightful)
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. (Score:4, Informative)
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).
Re:Your application has to need Linux. (Score:2)
Re:Your application has to need Linux. (Score:2)
Is there any implementation of this that I can download and play around with? Preferrably something that runs on x86, but some cheap dev board would do. I see the link to the ItIts project, or whatever it is called, but I can't read Japanese so it doesn't help me too much.
Re:Your application has to need Linux. (Score:2)
For the very small scale devices you mention, uClinux (microcrontroller linux) is probably more appropriate.
uClinux is used in everything from modems to DVD players.
Microsoft has a big lead in embedded too (Score:2, Informative)
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 (Score:3, Funny)
Microsoft embedded software in cars. (Score:2)
He's biased, his company sells an embedded OS (Score:2, Insightful)
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 ! (Score:5, Insightful)
Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc. (Santa Barbara, Calif.)
Green Hills Software [ghs.com]
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! [ghs.com]
nick
Re:Reliable unbiased article, not ! (Score:3, Interesting)
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 w
Re:Reliable unbiased article, not ! (Score:2)
Real-time, embedded OSes are a world apart from MacOS, Windows, Unix and Linux. You don't use those OSes for most RT applications, but that is good. You should use the right tool for the job.
But even if you took Linux, Mac OS, or W
I have no idea whether its right... (Score:2)
Take a look. http://www.ghs.com/products/safety_critical/integ
So while he may be right, the information is coming from the wrong person to be trustworthy.
I think Dan needs to hire a PR flak.
Where are the Linux devices? (Score:5, Interesting)
Re:Where are the Linux devices? (Score:2)
Of course everyone wants the bigger companies, but I think if they could demo products outside of traditional geek tools they could really generate more interest for bigger companies.
Re:Where are the Linux devices? (Score:2)
Re:Where are the Linux devices? (Score:2)
Re:Where are the Linux devices? (Score:2)
Most of the "embedded" Linux devices are the bigger, more powerful things like you mention- PDAs, routers, kiosks, etc. Linux couldn't run on a lot of the hardware in a lot of other "embedded" operations without running ELKS or uClinux. For instance- Linux plus the Qtopia GUI on my Zaurus C760 takes up a whopping 18 MB on boot- absolutely gigantic compared to the 2-4 MB of WinCE or something even less on PalmOS.
I too would be interested in find
No (Score:4, Insightful)
Rio Karma runs Redhat's ecos and kicks butt (Score:3, Informative)
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. (Score:4, Interesting)
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.
Re:This is Industrial Flamebait. (Score:2)
The last thing companies who are doing fairly well out of proprietary software want is a level playing field. Especially if it means they have to work hard to gain and retain ("lock ins" are rather more difficult with OSS) customers.
Processor support and realtime (Score:3, Informative)
Sweet jesus no! Not different processor architecures! Apparently this guy hasn't heard of Debian [debian.org].
And real-time capabilities? How about the Real-time Application Interface [polimi.it]
This guy simply sounds like he has a grudge against GNU and Linux.
Re:Processor support and realtime (Score:3, Insightful)
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 unde
Re:Processor support and realtime (Score:4, Informative)
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 (Score:2, Informative)
I'm using embedded Linux right now (Score:5, Insightful)
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 (Score:2)
but would you say that the linux embedded market is increasing or will increase? I don't know exactly what a lot of embedded stuff runs, but i assume a real small bare-bones OS as a controller that's not much more than a fancy 64K asm program?
As stuff is expected to become more "intelligent", will we see
Re:I'm using embedded Linux right now (Score:4, Insightful)
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...
Re:I'm using embedded Linux right now (Score:2)
Draw a big enough box around the problem and even stock Windows can be "real time".
Yea Sure! (Score:2)
Bizarre opinion. (Score:3, Insightful)
IT is full of idiots yelling at the tide though, move along, there's nothing to see here folks.
Re:Bizarre opinion. (Score:2)
Depends on the particular product.
For many types of net-connected appliances (NAS servers, routers, firewalls, webcams,..), advanced PDA/cellphones, TiVo'ish media players and similar, Linux makes a lot of sense. Most of these devices are really mini-PCs, and Linux runs well on those.
But if we're talking washing machines, refridgerators, watches and other tiny stuff Linux is often the wrong choice because the hardwa
Facts? (Score:2, Insightful)
Over the last year (Score:2)
However, why suddenly all the criticism and negative press? I have a few theories:
1) The SCO case introduced linux to a lot of journalists that previously had never heard of it. Kind of hard to swallow, since "linux" *is* damn near a household name n
He is right though (Score:5, Insightful)
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 (Score:5, Funny)
your heart monitor to be running?
1. Linux
2. XP Embedded
3. Windows CE
Survey says.....Linux...
Neither (Score:2)
Re:What do you want your heart monitor to run (Score:2)
Right and wrong (Score:5, Insightful)
* 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 (Score:3, Informative)
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).
No conflict of interest here (Score:3, Redundant)
Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc. (Santa Barbara, Calif.)
So I Googled for Green Hills Software [google.com] and found that Green Hills Software [ghs.com] 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 (Score:3, Insightful)
Re:You're missing the point (Score:2)
There's more than one embedded market (Score:2)
Where Linux is useful is in the larger, more flexible products (handheld devices, etc.). Here you can often get away with using a more-or-less normal linux distro adapted to your processor architectu
The article is about Linux Tools, not Linux (Score:2, Interesting)
From the article:
Can't Imagine (Score:3, Interesting)
LOL ROTL.
Confused Article - yes, no market for Proprietools (Score:4, Insightful)
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... (Score:5, Informative)
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.
Real time? (Score:2)
Can you say "bias"? (Score:4, Informative)
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?
One example (Score:2)
RTEMS is a well known OSS real time kernel (Score:2)
(I have no financial stake in OAR or RTEMS, other than having good feelings about their involvement in OSS)
Yeah right (Score:3, Interesting)
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! :)
Re:Yeah right (Score:2)
Why This Article is Stupid... (Score:3, Informative)
Why? Because the author has HIS OWN operating system products and services at:
http://www.ghs.com/ [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 [ghs.com]
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.
supply is not market (Score:2)
Re:the success stories? (Score:2)
Have you ever been to LinuxDevices? They offer prominent failure stories. I'd guess well over half the devices listed their are either no longer available, vaporware, or very obscure.
Have you given... (Score:2)
Both are cross-platform IDE's that allow you to change out compilers, do class browsing and analysis, etc. One is a mix of C/C++ code and Tcl/Tk code, the other is based on Java.
Re:Have you given... (Score:2)
Here's the link to Eclipse [eclipse.org].