Slashdot Mirror
Choosing an Embedded OS for Sustainability?
vivekb asks: "I work for a small start-up that's building its first commercial product. Because cost is less of an issue than development time, we've decided to make the brains out of an ETX computer with some sort of (non-realtime) operating system. Based on initial costs of tools and estimated license fees, the cheapest OS's I've found are Windows CE and several offerings of Linux. The big question that I can't answer is, 'How much will these platforms cost in sustaining activities?' In three years, when we're fixing bugs or applying patches, how much will we be paying vendors and how much will we be spending on internal developers? When the Linux kernel is at version 3.0 and our device is still running 2.6 -- or when CE reaches .INFO and we're still at .NET -- will support even be available? If anyone has past experience picking an embedded OS for a screen-and-button based electronic device, what did you learn to stick with or avoid?"
You are asking the Slashdot Fanboys to tell you what to choose between Linux and Windows CE? Are you for real?
Well, one viable OS the author of the article is forgetting about are the BSD variants, specifically NetBSD if you're wanting to use it on an embedded device. Many people have been using netbsd on various devices, which even NetBSD supporting suspend on some. I believe the author needs to take a look at what he is really wanting however. Money is the main goal in any project. Please take some time to think, "what is the easiest and best way to deploy while making a profit?"
Tsume
I would pick the OS based on whichever has the best device driver support for everything in your product. Device driver development can chew up a lot of time. You would be better off spending resource time on the application layer of the product.
(S(SKK)(SKK))(S(SKK)(SKK))
So of the two you've listed, clearly Linux would be your choice. Plus, don't forget that Microsoft's embedded OSes reinvent themselves every few years - just wait until they throw out CE and sell you Vista Embedded next year.
There are other choices based on the size/scale of your project - such as Nucleus, which gives you source access.
I've worked on products that had no OS at all, just a loop that called various functions in sequence. I've worked on products where the company wrote the realtime OS from scratch. I've worked on products where the company used a commercial OS, but bought a source code licence. I've worked on products which used an off-the-shelf Microsoft OS. It all depends on your requirements.
Are there realtime requirements? Do you know what hardware will be used, or will you need to support different kinds of displays, for example? What are the reliability requirements -- will this be used in life-critical applications, or will it be used for games? Will you want to upgrade to the latest version of the OS from time to time, or will you pick a good one and make zillions of copies of your product based on that one version? I'm sure there are other questions you should be asking yourself (help me, fellow Slashdotters).
Figure out your requirements first, then figure out how to meet those requirements. Don't just pick a solution and then try to make it fit.
There is a lot of truth to this. A few years ago, I joined a project team after development had been underway for a while. Most of the people had no embedded experience, and I had to spend a lot of time redoing things that would have been OK on a general purpose system, but were nightmares under an RTOS. There a lot of programming fields where speciality and experience matter, and embedded systems is one of them.
(S(SKK)(SKK))(S(SKK)(SKK))
Semi-serious, semi-not. DOS runs a lot of embedded systems, because it gives some really basic hardware support (file systems and booting, really) but still lets you get direct to the hardware. My employer has somewhere around 65,000 MS-DOS systems in the field.
The preferred solution is to not have a problem.