Username or EmailPassword
I had this notion that it was not a new market. I also had the notion that MS was not the leading player in that market.
But maybe we're speaking about different things?
MS is not the leader in this field.
Embedded developers tend to be of a hogher calibre and know what they are dealing with - the use embedded OSes and embdedded toolchains.
MS has a history of spectacular failures ion embedded. And not just kiosks and displays. A famous car manufacturer was burnt when MS technology failed its braking system. dangerous.
how did this happen? It happens, from my experience, MS sends representative to ask you to use their technology. Then they lower the price. If that doesn't work they offer to buy you up.
microsoft can not even keep a desktop stable and secure, how could anyone take ms serously enough to use anywhere else?
Before reading this article, I too thought that MS didn't have a presence in the embedded space. After doing a google for embedded OS market share, it looks like MS is doing pretty well after all. http://www.vdc-corp.com/embedded/press/03/pr03-23.html
That really too me by surprise. I had assumed that QNX and Symbian were the market leaders.
It would seem that the Engineers are not making the choices but clueless Managers.
I was shocked a couple of weeks ago to see one of the new Colour Natwest cash machines running dosscript upgrades i.e the system was running Windows.
In the Uk with all the talk of Chip & Pin and Bank security to do this is incompetence.
I'm not necessarlily saying it should be running Linux, but systems like these should not be running Windows- something like QNX would be more appropriate.
ATM machines have been running NT and OS2 for *years*. I used to design s/w for ATMS, so I should know.
The article was fully of gramtical errors, and I find comments like 'embedded systems need graphical user interfaces' rather silly. Since when does the 8 bit processor in my car airbag require a GUI?
Since when does the 8 bit processor in my car airbag require a GUI?
That, along with the word new, is what led me to think that maybe Robert Kao was talking about something else.
So, I'll ask again: What exactly is meant in the article by new embedded systems market? I know that in certain markets MS does indeed have an important share, but it greatly varies depending on what market we talk about.
I think that in the "embedded market" definition here should take also all the classic WinCE applications, PDA, phone
In fact the serious embedded applications (real time and mission critical etc...) have nothing to do with MS, they just provide the embedded interface, for example some PLC vendor provide embedded touch screen with WinCE.
Sorry for my english
I thought Microsoft was still pretty new to the embedded market. I think they have an equal share as much as anyone else in this field. This sounds more like an advertisement for uClinux.
No memory protection. I don't think the reason gets more plainer than that one.
Microsoft with Sun Microsystems will beat embedded systems market!
Been there done that, even when they offered the cost of the project in consulting services for using ce as a bonus, anything for a win whether it will fit the client spec or not. Viewsonic on the squawk box, "linux isn't free, work with us and we can make windows free", yeah, they didn't buy it either.
No memory protection, now who could possibly develop anything of value without that? Heavens to murgatroyd.
it doesnt mean uClinux is a linux kernel that magickally has no memory protection.. uClinux is a linux kernel that is modified so it can work with chips that dont have memory protection
any other kernel you run on these chips wouldnt have ~built in~ memory protection either
No memory protection, now who could possibly develop anything of value without that?
No memory protection, now who could possibly develop anything of value without that? Heavens to murgatroyd.
didn't seem to stop people who wrote software for the eight bit systems in the eighties such as commodore, apple, etc etc
heck commodore managed to have preemptive multitasking on the amiga line ... which had 68000 series chips with no MMU
feigning disdain and pretending something cant be done doesnt carry much weight when the entire history of computing disproves your contention
although i suspect i most likely just fed a troll ;o)
The function of an OS kernel is to moderate access to hardware resources and provide abstraction layers for manipulating hardware. An embedded device is a special purpose hardware platform. Therefore it is the job of the embedded OS designer to create/port an OS such that it properly handles the particular embedded platform. Microsoft has yet to develop an embedded OS for an existing platform. It has merely created one kind of high-level embedded OS and a specification for developing compatible hardware platforms.
In the real world, an embedded OS is written for a class of devices. In M$'s dreams, the devices would line up to run a particular OS.
When ARM decided to allocate the bottom of physical memory for monitor and debug stacks, MS whined and complained that the WinCE kernel would only work if it was loaded at 0x00000000. ARM was forced to place its monitor and debug stacks adjacent to userspace.
Want to use Windows in my embedded systems. All the links you guys provided has really made me think about it. i plan to do some research tho and see how well current customers have to say about the performance. Thanks for the info. I have one question tho, why shouldnt Windows be used in ATM's? What makes Windows so inappropriate for these devices. The author did strike me as an anti-MS zealot as well.
Most memory protection is focused merely at the stack as if
there isn't a heap overflow.
Those logo would make my shopping for system a lot easier.
That logo would tell me 2 thing:
1- the device is overpriced and i could get one 5%-10% cheaper around in the same store that use a smaller/free OS.
2- the device was made by lazy folk and it probably reflect in the material quality, assembly, product support and more importantly in the lack of "innovation" o the overall product.
It was really nice to be able to evade easily crappy dreamcast game as the winCE one showed the logo on the box.
Forget about "beating" MS. The embedded space is totaly different from the regular OS space, in that its essence is to hide the OS from the user. Embedded OSes are around us, but we do not need to know which one they are, and manufacturers can switch from one to the next when they see appropriate. The fact that I ship a product with this OS doesn't force you in anyway to ship yours with the same OS. The market mechanics here are totaly different. Even if 100% of embedded devices out there were using MS or Linux, that would have little influence on my choice (appart from the fact that if there is such a complete domination, there might be a good reason!)
The choice of an embedded OS isn't about a market share, or about the "best embedded OS". It is soly about finding the best match of features for your needs, at the best price.
Your needs may be to have very reduced footprint, and memory protection may be too expensive.
Or your priority may be reliability, and strict API may be required, with complicance with security standards.
Sometimes, memory footprint might not be an issue at all, or at least not be stringent (same goes for disk footprint). I think about kiosks and other devices that can afford or even require to have a hard drive, which means they even can page to disk.
I happen to build an embedded system for the audio world. We have made an in-depth evaluation of all our options. It turns out that XP Embedded is the best of *our* options.
Should we have other contrains, we would have a different solution.
So let's not be ridiculous about beating Microsoft just because it is MS. There are tons of scenari where MS sucks. There are also tons of cases where MS is just the best option.
Not to even mention price: even with MS's legendary greed, XPe was the cheapest option we had, hands down. Again, not for everyone, but certainly not a solution to dismiss right away.
"No memory protection, now who could possibly develop anything of value without that?"
You clearly don't understand why you would, or would not, need memory protection. In larger systems, memory protection is used as a way of catching bugs. Users can run random shitty apps on their systems, vendors have no control over that. Large systems are mostly developed in C/C++, languages that don't guarantee reliable compilation/execution. And systems are built with large number of components, many from 3rd parties or added on after sale.
Embedded systems are different. If you have a small OS controlling a cell phone, all components can be provided by a single vendor, so that vendor has full control over what goes in, and what 3rd party apps users can run. Being small, the vendor can debug it enough, that NO -critical- bugs remain. And vendor might use different development tools/languages than what's used for desktop systems. What is built in, often stays inside the product from sale to junkyard.
You can do just fine without memory protection. It just depends on the product and how it is developed.
for what???, just consider the mission critical systems imbedded OSs goes in to, how about medical equipment crashing and killing someone, or power company's automated systems crashes and the city suffers a blackout, many examples of this could be said but at the risk of sounding redundant i posted the two above...
"microsoft can not even keep a desktop stable and secure, how could anyone take ms serously enough to use anywhere else?"
The links itself don't say anything that makes up for such
strong language, how truthfull the might spea, i think..
This modern trend, to stuff Linux into everything and anything is somewhat scary...
If you have a small OS controlling a cell phone, all components can be provided by a single vendor, so that vendor has full control over what goes in, and what 3rd party apps users can run. Being small, the vendor can debug it enough, that NO -critical- bugs remain.
Note that most modern mobile phones do have the ability to run third party code. Your point is certainly correct with regards to certain embedded devices (say, microwaves), but for any remotely multipurpose device - or probably any device where all input isn't tightly controlled/strictly defined - I'd say memory protection would really be required for reliable operation.
There are tons od SOCs and platforms that take advantage of regular Linux. For instance the IBM PPC 405, a 266+ Mhz CPU runs PPC Linux. uCLinux is only for devices without a MMU. Even an old 823e ship runs full-blown linux!
But despite which Linux you use, they are all mostly the same. We develop here on x86 until we get the PPC prototypes. We replace the stubs or hacked-in feature emulation, move the hacks to real code to run the PPC devices and voila! We developed our unit concurrently with ardware development.
It also helps that MontaVista has a VXWORKS porting layer. It's not 100% as we have found, but it is a huge benefit. Our Propretary RTOS was modeled like VXWORKS, so we were able to use the package.
Our app/platform is nearly complete. We are removing the x86 stubs now, and the board is goign through low-level software testing. When we get the boards, we'll only have a few days or weeks of final integration.
And the fact that we have the source to it all: Priceless.
I was being sarcastic, and so was everyone else I hope. The Snagglepuss quote is usually a good indication.
Listing obsolete hardware ala Amiga doesn't help you make your point -- its irrelevant, no-one is using it. The fact is that there are enough alternative embedded platforms with MMU to make it easy to choose an arguably better alternative. If you want to cripple yourself, thats your choice.
Embedded systems like settopboxes are *all* moving in this direction, and its a big advantage to allow 3rd parties to add their code to you platform without having to do a massive code review. Now a simple watchdog process will suffice.
We use Linux for embedded STBs. The comparison to everything I've used and seen for the last 10 years is night and day -- it is possible to crank out a full platform in 1/10th of the time taken before. No longer do you need massive banks of testers and rigorous QC. Bugs that are not showstoppers (which would have been on other platforms) can be fixed with over-the-air updates.
As for the small systems vs large systems comment... everything is becoming a 'large system' now. In terms of a new rollout without existing platform or deployed hardware limitations, the choice for using a small system (I prefer to say cheap system) no longer is dictated by functionality but instead by the device budget.
The only trolls in this thread are the ones not working in this field.
I was not very impressed by this article.
The embedded operating system application area is extremely diverse. Embedded windows only addresses a very small part of this market and IMO relatively poorly at that.
Cost and performance requirments vary over such a range that the hardware solution range from 8 bit microcontrollers to 32 bit processors, DSPs and multip-processor/DSP solutions.
Realtime: From microsecond deadlines to none
GUI: from none, to simple buttons/displays to full GUIs
Software complexity: from very simple single task, to complex multi-process, multi-thread.
Reliability: ranges from acceptable failure intervals of hours to predicted failures intervals of millions of years.
To me MS only address low reliability systems without signiicant RT requirements, with a GUI and with a very limited range of hardware platforms.
uCLinux addresses a similar application area but with much wider HW platform support. I would use memory protection in a high reliability system or even just a complex one as it makes debugging and development much easier. The only reason not to is cost of the HW platform or if a DSP solution is required. Cost is not usually a problem nowadays for anything but the smallest/lowest cost systems. I would therefore expect more Linux than uCLInux solutions.
Some of the points in the article are way out of line with the reality of embedded system,s development:
1. Cost competition: What is important is no per-unit license fee and the ability to use cheap HW platforms. This is a problem for MS but not for Linus or other embedded OSes.
2. Graphic User Interface:
This is obviously a strength for windows but many embedded OSes support X and there are GUI toolkits specifically designed for embedded which have resource consumption advatages over either. As mentioned above GUI is often not needed or can be provided remotely through a web server.
3. Embedded Browser:
Nowhere near as frequently needed as an embedded web server for control/monitoring. MS solutions for both have well known, resource, reliability and security issues.
4. Chip Drivers:
By far windows biggest weakness. It only runs on two architectures! Custom driver development is notoriously difficult. I would say MS is probably the worst embeeded OS available from this point of view.
5. Quick Embedded Software customization:
Again a big MS weakness. Source available OSes and those accustomed to working with embedded development teams have a big advantage here. Motherborad development is only applicable to a very small sub-set of embedded designs.
6-8. This seems to be about a very specific application area. I would not say that network protocols was a windows strength either with most embedded system providing extensive support and Linux/BSD being the gold standard.
Suprised to see article generated so many comments.
I believe it was a poor attempt to get free PR for the company.
Very simliar to spam mail, except there is a little more effort involved.