Open Source In Embedded Systems 131
coxjohnson writes: "Technology Review reports on the OS battle between Microsoft and Open Source for the lucrative embedded computing market. Since 99% of computers can be found in embedded applications, an Open Source victory in this sector could deal a major blow to Microsoft." Good informative overview of the competition for embedded OSes.
That "Start Button to End" thing (Score:2)
Linus needs to support PPC better (Score:2)
Unfortunately, Linus is ignoring PPC [slashdot.org]. I know I've experienced stable-release kernel versions that wouldn't even compile on my PPC box. I don't see how the embedded systems market is going to take Linux seriously when Linus ignores anything but x86. Either Linus needs to wake up to PPC (I know somebody has given him a PPC box--why can't he test kernels on it?), or Linus needs to pass the torch.
Re:How do you Signal 11 a microwave? (Score:2)
Distributed development of embedded systems? (Score:2)
Aren't the software and hardware of an embedded system much more closely tied than that of a desktop computer? If so, wouldn't this make distributed, OSS-style development much more difficult? Each programmer would also need access to the hardware and the (proprietary?) devices used to alter the system's built-in code.
Re:PPC makers need to support Linus better (Score:1)
Then you own at the very least one PPC CPU already. the OBD 2 specification (on-board diagnostics v2) calls for a PPC platform, and ALL car manufacturers are using it. Automatic tranmission? there's another one. Digital dash? theres one more. Anti-lock brakes? there's at *LEAST* 2 more PPCs in that computer.
I seriously doubt there is a PPC running my digital dash, transmission or even engine for that matter. The PowerPC is one fuck of a lot of power. I would believe that a 68HC-class 8-bitter were running the display, maybe another for the transmission and a 16-bit CPU running the engine timing and so on.
Hell I would imagine that the ColdFire processor by Motorola would have enough juice to run the car, transmission and dash. But I digress -- DSPs would run the engine and brakes. Not a PPC.
Re:PPC makers need to support Linus better (Score:1)
You're not understanding the issue here. There are people contributing PPC patches and Linus is rejecting them. IIRC, he was saying the patches were too big. He wanted a number of smaller patches instead of one big patch.
What makes the PPC guys think that they can get big patches by Linus when he rejects big patches from everyone else too? Does their shit smell better or something?
If that's the only issue, I see nothing wrong. Linus is holding everyone to the same set of standards.
What about FreeBSD ? (Score:1)
The article, equates open source with Linux
and fails to mention BSDs, especially, in
light of the arguments presented by Wind River
Systems, the largest player in that market.
Re:Embedded + MS = Why?! (Score:2)
It depends obviously on your application.
But still even though the subheading of this article says 99% of computers are embedded... only 1% of those need an OS.
Most embedded computers, such as those found in cars, airplanes, your toaster, etc. are nothing more than a lower power processor of some sort running some simple instructions that monitor for some event and then perform an action. They probably have only a few bytes of memory total and run at very low power.
Out of curiousity, do you even know what POSIX is?
Re:Requirements are different (Score:2)
Microsoft essentially will have two embedded OS systems to sell. Whistler/XP embedded, and WinCE.
WinCE is intended for small devices with a simple GUI interface. So your point #2 conflicts with your later claim that we're talking about CE.
This leaves Whistler/XP embedded, and there you are talking about situations where point #1 and #3 are quite relevant, whereas #2 is not.
I see anti-Microsoft people do this a lot, where they take all the negatives of six different products and combine them to prove Microsoft sucks. Yet obviously, Microsoft produces six different products to target six different needs. You have to look at them from an appropriate vantage point, which I don't feel you are doing.
99%, huh? (Score:1)
Makes you wonder what that extra 1% is...
To Microsoft's AMBITIONS (Score:1)
Misunderstanding the Embedded Industry (Score:1)
Not true, IMFO. The multiplicity of options is essential to the industry because every product will be produced in large quantites. Every inneficency that costs money (needing more memory, faster processor, etc) gets magnified by tens of thousands to millions. Thus, the options are needed to find exactly the right tool for each job.
Also, I cannot see this as the root of interoperability problems. That's what open protocols and file formats are for.
The article does rightly outline many of the limitations for Linux in the embedded world. As I play pundit, I expect Linux to do better than WinCE because it is a better OS. But, it's still not the right tool for many jobs and I expect the traditional solutions to maintain 90% or more of the market.
Same old hack phrases (Score:2)
Soon they will allow our home appliances to diagnose their own malfunctions, and will even call and order their own replacement parts before they fail.
God, how many times have you seen this?
The problem is, nothing is built in this way anymore. When was the last time you had anything fixed. Stuff isn't built to fix anymore. You can't even order replacement parts for most stuff; I called customer service the other day for an appliance I have that's broken, and they practically laughed at me when I said I wanted to buy some parts. When you can get them they cost more than a new unit.
end rant
Re:99% my 80c51 (Score:1)
Anyway, there's avr-gcc for the Atmel line - tried an inexpensive STK200 ($70) and you have free gcc. Pretty cool.
Re:Hardly. (Score:2)
You don't understand embedded systems. They range from extremely cost-sensitive single chip processors to high-end workstations. Rack-mount PCs are very popular with the engineers that I know. They are cheaper than designing a custom controller and enable the use of off-the-shelf I/O boards and software.
Re:Microsoft in everything (Score:1)
PPC makers need to support Linus better (Score:1)
The main reason for this is that not many Linux hackers have PPC boxes. (Can't scratch an itch that you don't have.) And the reason they don't have the PPCs is that there just aren't any such boxes for sale, except for Macs or "server" boxes that cost many thousands of dollars.
It's ultimately up to Motorola and IBM if they want to sell PPCs or not. If they do want to, then they need to start selling POP motherboards or something like that, which will increase developer interest and result in more OSes running on it, thereby making PPC a more viable choice to developers who haven't committed yet.
But Motorola can't even fill the anemic chip demand that the Mac generates. Increasing the demand would just make them look even worse. As for IBM ... shit, I don't know what IBM's problem
is. That's a company that seems to take a
serious liking to watching superior
technology collect dust.
Anyway, PPC software is going to lag behind x86 (thereby reducing demand for the hardware) until the manufacturers decide to get off their asses and truly go for it. There's only so much that hackers can do. "If you build it, they will come."
---
Re:Indeed. (Score:1)
Well if that isn't a fine "Who is John Galt?"
You wanna quote authors? I think T.S. Eliot put it best when he said "Our beginnings never know our ends".
Let's tackle the toaster first (not a football reference). Let's say I get up in the morning in my groggy way and I walk to the kitchen while my wife is doing her hair in the loo and begin to make toast. As I depress the lever to allow the toast to descend into the toaster....
1) my circuit breaker blows because the toaster is competing with my wife's hair dryer
OR
2) my house lets me know that the breaker box has informed the toaster that not enough energy is available to run at this time and prompts to leave the toaster's request in queue or disregard or override (screw her damn hair, it's too expensive anyways)
Or better yet, how about an upgrade to my microwave that allows it to toast. What could be more elegant than reducing the number of devices that I have to interact with.
I can envision smarter Microwaves that remember how long it took to cook this particular size of Potato last time (adjusted for current room temperature) and offers that as a default preference.
These are (IMHO) more elegant solutions, but even with the simplest toaster your interaction is complex. It is counter-intuitive that you would put a piece of fermented baked wheat into a shiny silver box on your counter in order to improve it's texture and taste. These are really just things that you learned. So why can't I learn how to use an integrated environment to my benefit?
Your disdain for this kind of progress is not the kind of thought that I read in the work of Ayn Rand and I think you do her a disservice by using her name.
You don't like my toaster? That's fine. You go ahead and hunt ebay for your appliances and I'll remind myself not to invite you over. I agree that not all progress is beneficial, but there is no reason to impeed it and I have faith that the market will weed out the bad ideas.
bnf
Who are Michael and Bojay? (Score:1)
Microsoft, Embedded Devices and Licensing (Score:2)
Re:Then I shall debate until work is through! (Score:1)
Cost of the os is really infinitesimal to the actual systems design though don't ya think? which brings me to...
Not when you are rolling out tens of thousands of your devices. And the smaller/cheaper the device, the more the cost of the OS licence impacts the sale price. When you're trying to sell your devices for less than a few hundred bucks, the OS licensing will have a serious impact.
And having the source code is quite valuable. I've spent enough time in embedded systems design to know that bugs in some of the well known embedded OSes are not as uncommon as one might think.
We're talking about specialists though.
No, we're talking about the embedded RT OS, not the applications running on that OS. These are two very different things. Your Embedded RT microwave applicataion would run on an Embedded RT OS. The developer of the OS wouldn't need to know jack about the application. Do you think the makers of VxWorks (WindRiver) know about microwave circuit design? Or cell phone applications? Or satellite propulsion systems? No. And they don't have to. And VxWorks is used in all of those. Those people know Embedded RT OS design. And that's all you need to know to design an Embedded RT OS. Unless, of course, you are developing an OS *specificly* for microwave applications. But this thread is clearly talking about general-purpose RT embedded OSes.
Personally, no matter how good of a kernel programmer Alan Cox is, I don't want him poking around in my microwaves chips design, because he doesn't know the system. See my point there?
But he doesn't *have* to know microwave chip design. The microwave code is just an application that would run on an embedded, real-time OS, whether it be Linux, or VxWorks, or whatever. The folks who know microwave chip design would write their application to run on the OS.
We're not talking about opening up the code for the microwave chip *application*, just the Embedded OS it runs upon. The Alan Coxes of the world wouldn't be writing the application code, just the real-time OS. And quite frankly, I am reasonably cetrain that he and the rest of the kernel developers could create a much better real-time embedded OS that most of the current close-source alternatives.
In my experience Microsoft is the best.... (Score:1)
BSD is dying? Two tokens: (Score:2)
Suddenly, about one in ten desktop computers will be shipping with BSD. Not too shabby, IMHO.
Re:Don't get fixated on toasters. There's lots mor (Score:2)
Don't get fixated on toasters. There's lots more. (Score:4)
I'll give you one appliance I have that is fairly intelligent. My thermostat has a PIC that adapts based on the way my house responds. I tell it to keep the house at 58 degrees all night, and then to bump it up to 68 at 7 am (it then turns it back down after 8:30 AM). Initially, it just turns on the heat at 7am, but gradually, it figures out how long it takes my house to go from 58-68; if that's 20 minutes it starts the heat at 6:40 AM. As the seasons progress, it continually adapts so that it always hits the mark when I ask it to. I love this because I like it to be cold when I sleep but have trouble getting out of bed unless it is warm.
The problem is that it is painfully hard to program. I'm pretty good at this kind of stuff, but I don't look forward to figuring it out again when the battery goes dead. Think of the proliferation of bad interfaces; these are generally because some kind of complex behavior is required, but there isn't money or space for a decent UI and no computing power for connectivity to something with a reasonable UI. And, bad enough as the interface problems are on my thermostat, I'd like it to be even more complicated in behavior -- eventually I'd like a system that controlled heat and cold air to different rooms on individual schedules.
I can give other examples. Many people have systems which control irrigation on a timer. These could well get smarter as the costs go down. Why water the grass after a rain storm, or better yet, why not cut down the watering if there is 50% chance of rain today, or if it is cloudy? You may need to water the grass more when the temperatures are high. Water is likely to become fabulously expensive in places over the next few decades.
Of course, there's even MORE utility for this in an agricultural setting. I had a farmer recently ask me about web enabling some heating equipment he had for some high value crops.
Generally speaking, the consumer part of this is just the tip of the iceberg. Commercial, industrial and agricultural environments abound with things that are already smart but difficult to use, or which really ought to be smarter. Why not have an elevator service which adapted to produce minimal wait times by prepositioning the cars based on statistical analysis? Or which automatically switched some cars into express mode? For all I know new elevators are already doing this; most likely you wouldn't notice.
The degree of automation is almost incredible, and almost all of it utterly invisible to the casual observer.
For example, there is one company that sells salmon to high end restaurants. It has strategically placed several facilities within less than a day's driving distance of probably 90% of their potential US clientele. The restaurant orders exactly the number of steaks or filets in precisely the portion size they want. Meanwhile, workers throw a continuous stream of fish onto a computerized assembly line, where laser scanners develop a 3D model of a fish. This goes into a sophisticated computer model which basically figures out how to cut the stream of fish into pieces that will fit all the needed orders with minimal wastage. Robotically controlled jets of super high pressure water cut the salmon, and each piece is then routed to the container destined for the ordering restaurant.
You, as a diner, have no idea of the automation involved in the salmon steak your eating; even the chef doesn't know. All he knows is that he can order two dozen one pound salmon steaks at 10 AM and have the right number of steaks, accurate to within less than an ounce, ready for the dinner rush.
Ultimately technology like this will allow us to enjoy a higher standard of living with less environmental impact. Go capital!
Oh, and that toaster? I'd like to put my toast in at night and have it hot and ready for me after I wake up in the morning. If I didn't have to program another damned clock. It should also have a smoke detector and shutdown when my toast begins to burn.
Well... (Score:2)
Oh sure, you still have some devices that are to weak to run a heavy operating system like a Unix or a Windows, but nowadays many embedded devices have plenty of power for running these OSen.
So Linux and Microsoft are competing for a growing market. And if your embedded device is powerful enough to run a Linux, then there are some very big advantages to running it instead of a VxWorks, especially in the areas of debugging and support.
But good debates should never end... (Score:2)
Now, if you have a system with multiple threads, and enough horsepower/memory, then a Unix or Windows kernel starts to look very attractive. The development and debugging environments for these OSen are a lot better than what's available for most of the traditional embedded OSen.
From the user's POV, I can see where it doesn't make a difference, but that doesn't mean that it's pointless. There are several:- Better development/debugging environments than the traditional embedded OSen (this applies to Windows as well as Linux).
- Access to the source code w/o the high price. Don't underestimate this one. I can't tell you
how many bugs I've found in some well-known
embedded OSen.
- Better code/support. There are more people looking at, fixing, & understanding Linux code
than for most (any?) embedded OSen. The quality
of the code tends to be higher.
Just to clarify, I think Windows will also begin to displace the traditional embedded OSen. I don't think this is merely a victory for Linux.Re:Then I shall debate until work is through! (Score:2)
The good folks at Wind River don't know any more about microwave chips than Alan Cox. But both are specialists in OS design and development, and I would trust Alan Cox to fix my SMP issue as much as (or more than) I would the folks at Wind River.
embedded (Score:1)
Re:A little background here... (Score:1)
Embedded does not imply schedulable, and schedulable does not imply real-time.
Yes, there do exist some embedded systems that do not have real-time scheduling requirements. But many do, and a much much higher portions of embedded designs do than desktop boxen.
Real-time may or may not have anything to do with time-of-day, instead it's about performing at the time of required event. That x-ray treatment machine must turn off its beam within so a so many milli or microseconds of being turned on, or you are toast (2pm, 3pm, doesn't really matter; as long as it's N mS +- TOL uS after turn-on). Or I'm sure you won't mind an occasional "temporary" blue screen, lengthly interrupt hander, unrecovered floating point exception, random garbage collection cycle, or indeteministic unbounded cache or TLB trash in the middle that causes your death.
Re:Distributed development of embedded systems? (Score:2)
As someone who used to work in that field (I do programs that connect Oracle databases to XML files now), no. Many embedded systems (Hubble Space Telescope comes to mind) run on x86 CPUs. The main differences were that the UI often consisted of push buttons, lights, buzzers, and, if you were lucky, a five line LCD display. And they often had little RAM. Linux is a big win in that area.
Embedded is not neccessarily Real Time!!! (Score:2)
Re:Don't get fixated on toasters. There's lots mor (Score:1)
- not enough complexity
- complexity is overexposed
You cited a (bogus) example of the second kind. A toaster that I have to program is stupid. But imagine a toaster identical in interface to existing ones, except with a little camera that detects when toast/pop-tarts/whatever are about to burn and ejects before it happens. That's smart.
Most of the negative posts here spring from a mental picture of {some applicance} with a laptop stuck on the side. A better model is {some appliance} that looks and works like current ones, but gets extra input from the environment and usage history, and uses those inputs to make better decisions.
Successful embedded devices will have lots and lots of intelligence on the inside, and will look just like their predecessors on the outside.
cheers,
mike
Re:What a BS Article (Score:1)
that the same area of silicon that contained
a 4 bit CPU in 1980 can contain a x386 compatible
PC and all motherboard functions plus network controller. At some point, as the chip circuit densities
increase the packaging and
bonding for the semiconductor become the
dominant cost, not the chip area.
So, as devices require more sophisticated networking
and other features, it makes sense to use
a controller with enough oomph for the job. Bumming instructions in assembly language is
getting to be less and less necessary, and is
actually a waste of developer's time, if the
silicon is cheap enough.
Try looking ahead (Score:2)
We've been told for awhile now that the kitchen of the future is going to adapt and mold itself to our whims in ways we can't yet imagine.
Now granted I have yet to see any of these predictions bear fruit yet, but a necessary first step is going to appliances that can communicate, and what better way then giving them a full blown OS?
The costs to this are minimal in the sense that the storage requirements for a mini-linux are small enough that they won't add to the cost of the product(apart from development time).
So I'm going to accept, for the moment, that they have something like this mind instead of wildly bashing MIT.
And if I may ask, how is it dangerous?
Re:99% my 80c51 (Score:1)
Add to that the fact that most every wired telephone, all of the wireless phones, all of the TV's, VCR's, stereos, remote controls, calculators, and so forth have embedded processors in them. It adds up, and quickly.
The only problem I had with the story is the implication that embedded systems are a new thing. When I started doing embedded systems in 1991, most or all of the names that they mentioned as dominating the real-time OS market were already well established. The embedded systems themselves were the very first application envisioned for microprocessors. From my perspective, embedded systems aren't the next thing, they were the first thing. I guess the rest of the world is just now catching up.
Much like Consoles, the key is Stability (Score:2)
It's great that it's somewhat easy to maintain a Linux web server, but embedded systems are different. If my grandmother's cell phone has a bug in it, she can't just call tech support and have them fix it. If your Xbox has some internal glitches in the hardware, you can't just swap out the defective piece and replace it with something that works.
Embedded systems need to be supported by a corporation that is dedicated to system stability. Open Source may make a lot of cool software, but 90% of the stability comes from beta testers in the field. In the embedded systems, you need to find 99% of your bugs before it leaves the door. I'm not saying that Open Source projects couldn't handle this... Just that they've been found wanting in the past.
-Ted
Re:Embedded + MS = Why?! (Score:1)
But for the record, yes, I know what POSIX is. Or at least I believe I do -- I'm often wrong about just about everything. It's a set of (or, really, a set of sets of, since there are multiple POSIX standards) programming interfaces/APIs. They exist for many languages and purposes.
I was referring to their various C standards for things like file I/O, networking, and threading. I know several of the above-mentioned OSes are compliant with the relevant POSIX standards, meaning that you can program large parts of them in C using the same calls you would on POSIX-compliant unix systems.
I hope that made sense.
-Puk
p.s. Posting at 1 since I don't think anyone else cares about this.
Re:Embedded + MS = Because (Score:1)
I'm not mainly from an embedded background, but I do have some history in embedded systems. But mostly I take this from the people I work with who are excellent embedded systems designers, and who cringe if you even joke about using a MS OS in our system. Mind you, as everyone has pointed out, it is very application dependent -- it just doesn't make sense for ours, while it does make sense for others.
1. Tons of developers know the platforms. If you're an MS development shop, it's easier to do embedded development if you stick with the familiar.
Fair enough. But very few desktop MS dev shops go towards embedded (afaik), and plenty of other embedded OSes support C compilers many of the POSIX standards for libraries, and so can be used by anyone with a unix programming history, and a lot of people with a Windows history. But true -- if you're doing an embedded system and have a history with MS, it may turn out to be the best choice.
2. There are many choices of embedded platforms that license MS OSs. Just look at how many MSDOS-based embedded platforms there are:
I actually didn't know about this. It's very interesting, and I'll have to explore it more. Are these use in computationally-intensive systems (set-top boxes, etc.), or mostly simpler/cheaper ones (microwaves, etc.)?
As for embedded systems with a GUI, MS is actually the clear market-share winner. AT&T set-top boxes embed CE, as do devices from Hitachi, Samsung, Siemens, etc. How many embedded UNIX-based systems with a GUI do you know?
I agreed with this.
The good news is that Open Source looks like it's poised to open up market for embedded OS development.
Fair enough.
-Puk
Embedded + MS = Why?! (Score:4)
Most of these are (by reputation) faster, more reliable, and more stable, with more embedded-type features such as real-time scheduling and cross-platform support.
Unless I need a nice GUI on my system (and I'm pretty sure GUI-based embedded applications are only a small fraction of the embedded market), I might as well go with one of these. Whether Open Source or commercial win, I don't know, but MS doesn't even seem to be a contender.
Oh, and regardless of open source, many of the commercial vendors (some mentioned above) support open standards such as POSIX, making even more interoperability possible. How about WinCE? Hmmm...
-Puk
What's really important (Score:1)
I accept a certain about of instability in computer systems, there are many companies all working seperatly, and problems will happen. But for my vacuum, answering machine or lawn mower, I don't want to have to worry about crashes. I don't care what's in them, as long as it works, and works well.
The Good Reverend
I'm different, just like everybody else. [michris.com]
Bullshit. (Score:2)
Deal a major blow? Given that Microsoft has almost no share of this market to begin with, this is not dealing a blow.
What a BS Article (Score:5)
ÕÕ
Been there, Done That (Score:5)
Of course, a couple of other lessions learned from that job are that you should hire developers who know the platform you're using. Moving a bunch of Win* programmers with no previous Linux experience over to a Linux platform seems to be a recipe for disaster. Also, a clueless manager can spell doom for a project. Well, we knew that from before, but I've never seen a project heading for destruction quite that fast before. It was actually kind of impressive in a morbid sort of way.
Anyway, Linux can be a good choice of environment for at least some embedded projects and if it fits your needs it can save you a considerable amount of money in the process.
Re:What's really important (Score:1)
No that's not what's really important. While having a good product with those qualities is necessary you should remember the potential for embedded systems and what implications it has for every day life.
Embedded systems will (probably) one day be just about everywhere. You'll be carrying a personal digital assistant which will be in continuous communication with a host of services such as traffic control, weather stations etc. across the transparent wireless network that encompasses modern life. I'm sure you've heard of such visions of the future.
That all sounds fantastic and swell doesn't it? (despite the fact that it won't happen for awhile) But it raises a very important issue. Do you want a closed-source operating system to have control of every single facet of your existence? Do you want all of your personal data, all of your diary notes, family pictures, financial data, and location under the control and in the trust of a single company? Do you want to enter a world of transparent, ubiqitous computing not knowing what kind of backdoors or surveillance some corporate or government interest has built into your OS?
There is no other way to guarantee security and peace of mind but to have an open source operating system behind the scenes (by security I mean protection from malicious interests who would seek to pry into your life like the government or the company who would be tempted to sell your data). Sure the law forbids the government from spying on it's people, but we all know that the government will bend the rules for the sake of national security. Any other view is naive.
Your assertions of not caring what runs on your vacuum cleaner and lawn mower worry me for the reasons I've stated. Ya sure, your mower won't have network access(or will it?
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Re:PPC makers need to support Linus better (Score:1)
-----
"Goose... Geese... Moose... MOOSE!?!?!"
point taken (Score:2)
And putting some version of the kernel into an embedded system is still pointless, even if it is open for everyone, as it is useless to all but embedded systems users. And why would any embedded systems company really /want/ an OS os? Their money is really in 'we thought this up and can do it the best, don't buy it from joe compeitor'. The market isn't in a place to accept something like that at this point (IMHO).
I think the only real victory is for zealots who think they are 'beating' MS.
Then I shall debate until work is through! (Score:2)
Access to the source code w/o the high price. Don't underestimate this one. I can't tell you how many bugs I've found in some well-known embedded OSen.
Cost of the os is really infinitesimal to the actual systems design though don't ya think? which brings me to...
Better code/support. There are more people looking at, fixing, & understanding Linux code than for most (any?) embedded OSen. The quality of the code tends to be higher.
We're talking about specialists though. Personally, no matter how good of a kernel programmer Alan Cox is, I don't want him poking around in my microwaves chips design, because he doesn't know the system. See my point there?
Not really a blow to microsoft (Score:4)
ummm not really. (Score:4)
Re:Much like Consoles, the key is Stability (Score:2)
The flaw in your reasoning it your assumption that open source software has to be developed differently from any other software. While this is certainly possible it is not a requirment. It is possible to develop software conventionally with thorough QC and release the source to the public. You can still accept or refuse patches from the public as you see fit.
Re:Requirements are different (Score:2)
Currently Nucleus but it'l be VxWorks in a few months here. But I only know beacause my employer designs and builds the control systems for one of the largest manufacturers of conveyorized furnaces.And btw our customer really wanted WinCE but our sw developers absolutley refused (they were pushing for RTLinux), VxWorks was a compromise.
Re:Linus needs to support PPC better (Score:2)
It's a good analogy actually, with torches, as with open source, if someone needs some light, there is no need to pass them your torch, thay can just light their own off of the flame of yours.
If you really really want PPC Linux, you can make the mods to run it yourself. If you want a Linux that compiles on everything out of the box, fork the kernel. If it's worth doing, it will be supported. If it isn't supported, it wasn't worth doing.
Rich
Re:Requirements are different (Score:2)
Microsoft *could* create an embedded OS but it really couldn't be anything like Windows as we know it. I mean, how can you fit Internet Explorer into 64k? (It is an essential part of an OS after all)
Rich
Re:Not really a blow to microsoft (Score:1)
Yah, I'd be very surprised to see people trying to put that round peg in a square hole.
blessings,
Re:That "Start Button to End" thing (Score:1)
blessings,
Have to remeber (Score:1)
Re:A little background here... (Score:1)
Re:A little background here... (Score:1)
Linux's big advantages (Score:3)
1. Open source. I know it's fairly obvious and has been mentioned before, but it really is a pain in the ass to get the proprietary embedded OS folks to take your project seriously. Basically you have to take what they give you and like it. Often there are workarounds, but that's more engineering time, usually for hardware, to fix a fairly simple software problem.
2. Native developement. I haven't seen this mentioned by anyone else yet, but it is a definate advantage to be able to run the same OS on the system you write the code on as you are on the embedded system. It makes testing/debugging a lot easier.
3. Licensing fees. At my last job we used Phar Lap, a unix variant embedded OS. We had to purchase a license for every single processor that running Phar Lap. These licenses came in the form of sheets of little stickers that we had to put somewhere on each board that had a processor running Phar Lap. The stickers were made from a conductive material. What a pain in the ass. On the other hand you could buy one copy of an embedded linux, or built your own embedded linux and use it as many times as you want. If you want stickers you can print up as many "Powered by YOURCOMPANYHERE Linux" stickers as you want real cheap.
4. Support (or, do you know where your copy of windows 3.1 is?). How do support a legacy system that is running a proprietary closed source OS? Tis is a real problem for embedded systems as many of them need to be supported for 5, 10 years, or more. At the afore mentioned job we supported systems for 7 years and generally at that point one of the support techs would "retire", buy up any excess parts we had for that system, and we would refer any support inquiries to them and/or their consulting company. Finding replacement hardware was hard enough, even within the 7 year window, but try finding a copy of an OS that hasn't been sold for 5 or 10 years. Go ahead, try to buy a copy of windows 3.1, I dare you...
Anyway, I spent a couple months trying to sell our engineers on linux (versus a combo of NT controlling Phar Lap or VxWorks) and some of them seemed to be interested, but of course I got laid off because of the tech slump, so I don't know if it's actually going somewhere.
Re:99% my 80c51 (Score:2)
I have one PC, one TV,CD,Stereo,VCR,answering machine, microwave, clock radio, wristwatch, thermostat, modem, and at least 10 embedded systems in my car. I'm told that only 1 in 4 households (in the US, anyway) has a PC, so even in the US residential market, that's 1 PC and 80 embedded systems.
I will have all the Operating Systems!! (Score:1)
In essense, people who come later in the business can charge cheaper prices.
Re:I will have all the Operating Systems!! (Score:1)
It is like drivers for devices. Once one is written, you can use it as a template for other very similar devices. Now if your job is selling the hardware, sure.. but if your job is selling the hardware and the HMI, would not taking an existing standard save you money? Of COURSE it will, and existing code will make that easier.
Will you then release code you make to add on to it to now make it easier for your next competitor to come along?
GPL means that the person who initialy invested PAYS the cost. Others can live off it.
Re:A little background here... (Score:1)
Slight correction. It would be closer to correct to say that many embedded controllers have RT operating requirements, but by no means all do. Embedded controlers cover a huge range of conditions, everything from ABS controllers (where RT features are critical) to vending machines (where they're not). Embedded devices also include a number of things that are basically single purpose computers, like home firewall boxes, and Linux has some real potential there.
Re:That "Start Button to End" thing (Score:1)
I can't speak for anyone else, but I don't need to click on the Foot button on my Gnome desktop to log out. It has a perfectly good dedicated logout button right there on the panel, and IIRC that's part of the default installation. Yes, logging out is also avaliable under the foot menu, but you don't need to go through the silly, backward thought of pushing the start button to stop the machine.
Re:The important point is (Score:1)
Re:Then I shall debate until work is through! (Score:2)
If you haven't yet -- read kernel traffic [zork.net] if you get a chance. Much of this has been covered there and in detail.
To summarize the comments there, Alan (or Linus, or Theo, or ...) doesn't have to know about the specifics of the chips in the microwave. I doubt any of them would care to know the specifics of most hardware unless they have it.
Good code is highly portable; 'Bits are bits'.
Sure, different chips will execute the same string of binary information differently, but the design in the original code -- if solid -- will be reflected in the binary when compiled for any target device. (Baring, of course, compiler bugs you'd have to deal with anyway.)
Am I over-simplifying? No doubt. Yet, the design defects corrected in the non-hardware-specific code won't have to be fixed for each and every new piece of hardware.
In many cases, defects found working with a specific piece of hardware might point to flaws in the general code.
Very little programming is necessarily hardware-specific. Most code is either OS or interface not hardware.
Indeed. (Score:1)
Also, a full-blown OS is not needed or wanted in this case; a much simpler embedded OS supporting perhaps a reasonable subset of ANSI C would be far preferable than a full-blown Windows or a Linux.
It is dangerous in the sense that it hurts the consumer, and adds an extra level of failure that does not need to exist. At the moment, my microwave is far more reliable than my computer by virtue of its simplicity. I would like to see this continue in the future, especially if I ever need to buy a new microwave. I would also appreciate it if said microwave does not require a Pentium IV.
---
Hardly. (Score:3)
What would be the simple cost of upgrading all simple household appliances to run a heavyweight Operating System such as Windows or Linux, and why would there be any benefits to doing this? Indeed, what should a toaster do besides toast? Why should a watch concern itself with anything but the time of day?
This is simply technology for the sake of technology: dangerous, and not in the best interests of the people that MIT claims to serve. It is not sane, rational, or in the best interests of mankind, and as such, is a shame to their long University tradition of developing and promoting new and useful technology.
---
OS? We don't need no stinking OS... (Score:1)
1. Don't have an embedded application
2. Have over designed your product
Let's take a look at how you would code up a PIC 16C74 [microchip.com] from Microchip [microchip.com].
org 0x00
goto START
org 0x04
goto INT_Vector
org 0x20
START
; Code to setup all your I/O states
MAIN_LOOP
; code you execute in the main loop
goto MAIN_LOOP
INT_Vector
; code to save register states
; code to handle interrupt(s)
; usually time critical I/O and timing
; code to restore register states
retfie ; return from interrupt
I give you a complete embedded O/S. If you need more than this, please refer to rules 1 and 2.
This chip with a FTDI [ftdi.co.uk] FT8U245AM [ftdi.co.uk] latched onto Port D gives you a complete embedded 20Mhz USB device (with linux drivers).
You need an OS? That is the rumor that keeps Microsoft and Slashdot in the green.
TastesLikeHerringFlavoredChicken
Re:What's really important (Score:1)
This is actually not uncommon in today's market: small bugs occur, the customer unplugs it to take it to be repaired, it gets to the repair store and suddenly there is no problem. And before you start blaming embedded winNt, realize that most embedded devices today are VxWorks, QNX Neutrino, LynxOS, pSOS or VRTX, all of which are mostly stable, but DO occasionally encounter problems.
Ignoring the big players in the embedded market (Score:1)
Wind River's VxWorks has roughly 40% of the embedded market. Over 50% of companies developing embedded products roll their own OSs. That leaves less than 10% for all the other embedded OSs around. All the embedded OSs mentioned in the article (QNX, VRTX, Win CE, LynuxWorks) together have less than 5% of the market.
Re:It's the arts (Score:1)
Re:What's really important (Score:1)
Re:Requirements are different (Score:1)
Microsoft is a household name. Other than the geek community, who the hell has heard of LynxOS?
Microsoft has thousands of developers to throw behind whatever they want.
Microsoft is cash rich. Then can throw hundreds of millions of dollars at something and not have it financially affect the company in any way if it fails. I'm not sure about their cash reserves now (anti trust trial and stock markets collapse), but at one point they had many billions in cash just lying around.
Re:What's really important (Score:1)
Name your (consumer) OS, and I'll name an app that can kill it. (Most of the time it will be Netscape, of course).
Asbestos underpants donned.
FP.
--
Re:A little background here... (Score:1)
Hard realtime means if you don't get it done in time, you may as well kill yourself, you've failed.
Soft realtime means there's a time limit, but things will recover if you don't manage to make it.
Hard realtime includes things like the transmission of telemetrics from sensors near nuclear tests, which basically will only exist for a thousandth of a second.
If any type of QOS is an issue, then many comms apps are hard realtime too.
FatPhil
--
Re:I will have all the Operating Systems!! (Score:1)
Linux is good but.. (Score:2)
Re:The important point is (Score:3)
Curiously, though, there seems to be something fishy, a dark side, regarding Windows Media Player, aka WMP.
WMP, the acronym, looks strangely like WhoMP, as in conquer and destroy.
WMP is strangely a high quality product--indicative of an attempt to gain "market share" in the area of music file formats. (The reason I say "market share" is because, well, is there's a market here?)
WMP has its own format while maintaining backwards compatibility.
When I installed WinAmp, clippy politely informed me that Windows Media Player had all the features of WinAmp and more. Then he (or she) politely informed me that he (or she) could uninstall WinAmp for me. At first I didn't want to, but then it did that Japanese seizure-inducing thing, foreshadowing the coming events:
When I set my computer's clock to 2002, WMP said "MP3 format has become obsolete. All your MP3 are downgrade to 56 kbps."
When I set my computer's clock to 2003, windows said, "You are not using our flagship product!!! Please upgrade to XP; it's our flagship product!!! Make your time! Small print: you do not have to do this."
Okay, this post is getting stupid, so I'm stopping now.
The important point is (Score:5)
Try a MINOR blow (Score:2)
No, not really. Did you even read the article before you posted this?
From Technology Review: In what must be a humbling experience for the Great Software Monopoly in Redmond, WA, Microsoft's offerings constitute mere slivers of a pie chart along with such geeky names as VxWorks, QNX Neutrino, LynxOS, pSOS and VRTX.
This could deal a minor blow to a tiny fraction of Microsoft's business at best.
Re:Hardly. (Score:2)
You don't need any OS for that. You can do it with a PIC.
Unless your watch is full of gears and springs, it has an OS.
No it doesn't. Unless it is a very fancy nerd watch it likely doesn't even have a CPU, just an oscillator and a bunch of counters.
Someone calling themself "Ayn Rand" from aynrand.org is scarcely in a position to pontificate upon what is sane and rational.
C'mon, you can do better than this ad hominem response. The guy is right -- when you make things more complicated than they need to be you make them fail more. When you make them more capable you depend on them more. Thus, you end up depending more on stuff that is less dependable. What happens when the only user interface is through your kitchen master console (after all, everything intercommunicates so why spend a few bucks on buttons? Just ask printer manufacturers), and one day that interoperability fails? Then your toaster not only doesn't brown your toast right, it doesn't toast them at all; your fridge inexplicably shuts down and ruins all your food, none of the lights will come on, and the phone won't even work so you can call the service guy. Yeah, I really want a house that works like that.
Spare Parts (Score:2)
Yeah, it's sad. The flipside of this is that with a little planning ahead you can often get spare parts for free -- just wait for someone else to toss their exact duplicate of your gizmo in the trash, and fish it out for a "parts spare." It's surprising how often I've been able to do this.
Prolly noone will readdis but waddehey... (Score:2)
No it doesn't. As I said, you could do it with a PIC. Have you ever done any embedded programming?
Is there any other kind of watch worth wearing?
Actually I have been given to understand by non-geek but well-connected friends that, if you ever intend to do anything in the world, the Geek Watch is exactly what you don't want to be wearing. I have progressed through the years (under tutelage from the boss and female unit) from the Digital Wonder to the Citizen Pseudo-Digial Wonder to, finally, the Classic Seiko (the new ones aren't as good, the cognescenti know) which doesn't have a second hand. Yeah, it's a pain when I have to time a wait loop, I keep a stopwatch in the desk for that. You deal with it. Fashion costs.
Nah, it's not ad hominem. Every Ayn Rand footkisser I've ever met has been a lunatic of some kind, usually with an undeservered superiority complex.
Your problem with the type then. You were still wrong.
" The guy is right -- when you make things more complicated than they need to be you make them fail more." Sorry, that's just not true any more. Unless you're Microsoft, of course. (ObMS Bash)
OBMS or not, you're wrong. I work with embedded stuff day in and out. It's still true that the more complicated you make the plumbing, the easier it is to muck up the works. Modern automobiles fail in much more frustrating and interesting ways than Model T's did -- I should know, since I have some relatives who run an auto shop. They are slowly being driven out of business by the equivalent of MCSE's -- equivalent in every way, including paper over experience and inability to deal with real failures.
If you pay attention to the details, you can indeed have a complex and highly reliable system. But nobody is paying attention to those details. Microsoft? HAHAHAHAHA They have never met a detail they liked since 1974. Anybody else? The Linux folx, yes, they like details, but their system isn't realtime and is very, very bloated re: embedded systems. Look, I'd love it as much as anybody if this fairy tale could be made real, but it can't and it isn't and it's really stupid to hope for it. In embedded systems, it's you and the metal. If you think otherwise, you will fail.
The OS will never be a big deal in embedded (Score:3)
But the car, fridge, and toaster do not need an OS and aren't getting one soon. Embedded is most of what I do, and it is mostly done to the bare metal in minimal hardware. Even when it is bloated (as when a 6-level interrupt system has been coded in C++ on a 80186) it's a charming kind of backward bloat, harkening to the 1980's. It takes 256 whole K, isn't that cu-ute.
Most embedded apps are realtime, mission critical, single-tasking (or pseudo-multitaskable), and lack user interfaces. Until recently the dominant chip in car applications was the 8048. When you are building in the quantities, with the price structure, and with the requirements of embedded, it usually makes sense to code the whole thing from the bare metal up in C and assembler.
We are beginning to see a few devices that don't really need OS's showing up with OS-like kernels, and they are notoriously slow and unreliable. They don't compete well against more traditionally created firmware, which runs circles around them even on inferior hardware. At least this is the case in the scale industry; I don't see why it would be different anywhere else. Even PC104 hasn't really taken off, despite a few companies that have invested in it. When you are building mission-critical stuff or in quantities of millions, it makes sense to do it from the ground up. In the first hand you have the chance to make sure it's right, and in the second you save money. Yes, Virginia, it does make a difference whether you need 512K RAMS instead of 256's. And the ability to live with that extra wait state can make the difference between a product that ships now and one that never does.
There simply is no room for a general-purpose OS in such an environment. We've seen them (QNX, etc.) already where they are appropriate, and that niche isn't going to change. Meanwhile, neither Linux nor anything ever created by Microsoft since 1974 is really suitable for an embedded platform.
kaboom (Score:2)
Some RTOS' can be used, for a typical production server running http, mail, etc, often faster and more productive than most other OS', and I'm sure there has to be advocates of RTOS' with a comment or two. There are benefits to making a switch or are RTOS' a high tech OS solely geared for companies needing higher computing standards, but I can see many here trying to advocate Linux, Linux, and oh yea Linux, and I'm sure there are those who will mod unfairly [slashdot.org]. whatever
Don't get them confused, a lot of THESE OS's are not free to download, and they're not the same as using redcrap, or dumbian progeny. The article itself though didn't mention that some of these are pricey OS' it seems like they just jumped on another "Oh
Is our soldiers forthcoming homecoming? [antioffline.com]
smackdown (Score:2)
You post this so much its just stupid, you offer nothing to back up your claims, instead you talk out of your anus. Could it be you tried to use a BSD and you were too much of a fucking clueless script kiddie to get a connection?
Hint: get a life
Re:Not really a blow to microsoft (Score:2)
99% my 80c51 (Score:2)
If that is only 1% of the CPUs, then there must be 99 billion embedded CPUs.
If that's the case, why isn't the SOX [yahoo.com] doing better?
--Blair
Re:A little background here... (Score:2)
Embedded does not imply schedulable, and schedulable does not imply real-time.
Embedded means you normally don't use a general-purpose human interface on it (your PDA don't count, it's just a small personal computer).
Schedulable (what most people call real-time, so much so that it's a linguistic shift I'm willing to tolerate) means it will perform its requirement before a deadline.
Real-time means it is schedulable using the date and time-of-day.
I now leave you to the flame war that will ensue. If it digresses enough, we can talk about editors, political wings, and whether the lack of a salary cap is ruining baseball or making it greater.
--Blair
Re:Not really a blow to microsoft (Score:2)
--Blair
Re:A little background here... (Score:2)
No.
Real-time is "within one second". Schedulable is "within 400 million clocks".
The question comes when you ask "how many seconds is 400 million clocks?"
or
"Can I re-point this buffer descriptor between subsequent 100Base-FX packet-received interrupts on a Motorola PowerQUICC 8260 CPM?" Then your schedulable had better be real-time.
Think internal vs. external events. Throwing the baseball to yourself on the run vs. throwing it to Rickey Henderson on the run. You don't need to know how fast you're going. You do need to know how fast Rickey's going.
The difference between the two is everything.
--Blair
Re:99% my 80c51 (Score:2)
--Blair
Re:Requirements are different (Score:2)
enkeller wrote, "You're missing the point about the Microsoft advantage in my opinion ... Microsoft is a household name."
Remember the topic. We're talking about embedded systems here. Sure, a PDA might say "Made for Windows CE" on it, but that's a tiny fraction of the market. Quick, what OS kernel powers the antilock brakes in your car? Your fancy calculator watch? The power supply cycling for the burn-in ovens at the chip factory? Your synthesizer keyboard? Your multi-line caller-ID 100-number-memory desk phone? Your MP3 player?
How many makers of that kind of device are going to pay an extra license fee just to put Microsoft's logo on the box? Who cares what OS is inside, as long as it works? (And I hope nobody ever puts Microsoft Windows CE inside a car engine or breaks, or "Windows crashed" will have a whole new meaning)
Re:Requirements are different (Score:2)
Sheldon wrote, "Don't you think you are confusing some things?"
No. But perhaps I didn't explain it well enough for you to understand.
"Microsoft essentially will have two embedded OS systems to sell. Whistler/XP embedded, and WinCE."
True, but if you actually read my message, I'm referring mostly to the vast majority of devices that have no use for a fancy GUI, so we're talking about WinCE here. From my point-of-view, an embedded system is just a component of the product-- and a relatively invisible one at that. Everyone knows there's some kind of pump moving refrigerant around in your fridge, but nobody really cares what make or model it is. Unless the GUI is the focal point of the device (as in a new-generation cellphone or a PDA), why put in WinXP/embedded and have the higher cost, slower boot time, increased memory, and so forth?
"WinCE is intended for small devices with a simple GUI interface. So your point #2 conflicts with your later claim that we're talking about CE."
No conflict at all. I said that the GUI is a big part of the selling point of Windows. If you're using a non-GUI environment, this advantage evaporates. Where's the conflict in that?
"I see anti-Microsoft people do this a lot, where they take all the negatives of six different products and combine them to prove Microsoft sucks."
I see blindly pro-Microsoft people do this a lot, where they don't bother to read the arguments to even determine whether the writer is pro or con. I didn't say that Microsoft sucks. I said that the factors that make Microsoft Windows a success on the desktop don't contribute to making it a success as an embedded system.
There are some Microsoft products I really like. I think VB is a fantastic UI prototyping tool, faster than any other I've used. Microsoft Word (when you turn off the "we know what you really wanted" features) may be the greatest word processor of all time. But I find their business tactics reprehensible and I think Windows is not sufficiently stable to be my operating system of choice. Does this make me an anti-Microsoft person? If so, it makes me one with a well-considered opinion based on over 20 years of experience working with the company and its products.
Requirements are different (Score:3)
What are Microsoft's big advantages for desktop computering, and how do they apply to embedded computing?
Add in overall OS stability (Linux beats Windows by a mile) and the ability to customize the kernel to fit your particular embedded application, and I don't see the fit of WinCE in any non-GUI embedded environment. Linux, OTOH, is a great match. I wish I'd had it when I was doing embedded realtime code and had to roll my own mini-OS.
I guess LynuxWorks doesn't get it (Score:2)
This comes from a company that ships BlueCat Linux and touts the compatibility of LynuxWorks with the Linux APIs. I guess they don't quite get it, and the market will likely punish them for it in the long run. Lynx may or may not be better for real-time applications right now than real-time Linux, but in the long run, there will be open source real-time operating systems: the long-term economic incentive for companies to create and share that kind of software are simply too overwhelming for any proprietary software vendor like LynuxWorks to compete.
Of course, they can try to hedge their bets by shipping BlueCat Linux, but as long as they also have a proprietary product, there will be conflicts of interest within their company: whenever they enhance their free software, they cut into the market position of the proprietary stuff. This seems worse to me than committing to one or the other business model and focussing all their resources on that.
Note that I'm not saying that there is anything wrong with them trying to sell proprietary systems; I simply think they won't be competitive in the long run.
Re:Embedded + MS = Because (Score:2)
1. Tons of developers know the platforms. If you're an MS development shop, it's easier to do embedded development if you stick with the familiar.
2. There are many choices of embedded platforms that license MS OSs. Just look at how many MSDOS-based embedded platforms there are: http://www.google.com/search?q=embedded+microsoft
As for embedded systems with a GUI, MS is actually the clear market-share winner. AT&T set-top boxes embed CE, as do devices from Hitachi, Samsung, Siemens, etc. How many embedded UNIX-based systems with a GUI do you know?
The good news is that Open Source looks like it's poised to open up market for embedded OS development.
Invisible Agent
Obligatory Links (Score:2)
--