A Warning about Windows CE

After working on several Windows CE projects, I am noticing patterns. There is a "gotcha" with the OS I find interesting, as it evades all sorts of higher-up managers. Before I say what it is, I'd like to cover first the things people think are gotchas with Windows CE, but are not.

Windows CE is not a RTOS

The first thing I've heard when Windows CE is under consideration is that it is not truly a real time OS. After reading some studies, working on projects with Windows CE and real-time requirements, and prepping to teach a Windows CE training, I am convinced that it is a real time operating system. Interrupt latency is deterministic, and if you know what you are doing, you can use Windows CE as your OS in your embedded system that has hard and soft real-time requirements.

Keep in mind though just because you can use Windows CE doesn't mean you should use Windows CE for your real time OS. I doubt any embedded software developer with real time system experience will take Windows CE seriously as a solution to control flow of medicine to a patient. Or the cooling of a nuclear reactor. For a front-end setup, without real time requirements, to drive a display, UI, and touch screen to these systems? Sure. To be in a closed loop safety control system where one late interrupt could kill someone? No way. Even though you may be able to get it to work, no one else will be doing what you are doing. Any sort of safety certification won't fly. And it shouldn't--you are using something in a way that it isn't intended for. Get something by Wind River or Green Hills.

As a side note, I don't think the above statement isn't recognized by Microsoft. I'm sure they are more than happy for CE not to be in the loop with real time safety critical control systems. Anything to avoid litigation when things go wrong and people get hurt. I'm sure 99.99% of Windows CE licenses are for Windows Mobile platforms anyways, that's where the money is for them. Although who knows what new luscious platforms like the iPhone and Android will do to Windows CE.

Windows CE is not Stable

This one I hear a lot and disagree. The times I have seen a Windows CE system unstable, it is always due to the application level code. When the system is configured right, and the OEM BSP software is production ready, Windows CE runs like a champ.

I think this notion is created by folks that haven't dealt with Windows CE, and fill in the gaps with what sort of Windows experience they have. More often than not this is blue screens on Windows 98 or (even better) Windows ME. But Windows CE is completely different, right down to the kernel.

Windows CE is Closed Source
This one is partially true. The kernel is completely open now, so there is no limit to delving into the source code to completely understand the ins-and-outs. A necessary feature when debugging, especially when timing is involved. However there are all sorts of standard Windows libraries that are closed source. Plan to see the source code for the .NET Compact Framework components? Sorry. How about the IP Helper API so you can figure out all the weird NDIS driver calls? Sorry again.

The Gotcha:
So if Windows CE is real time, stable, and open source enough... what is the big gotcha? It is actually quite simple:

Windows CE doesn't turn Desktop Developers into Embedded Developers.
Managers love the idea of Windows CE because they think they can take the stock windows programmers they posses and have them create an embedded system. But just because Windows CE supports the Win32 and a subset of the .NET Framework API, it doesn't mean you aren't developing an embedded system.

Take a past client I had at a prior job, whose name I won't divulge (as getting sued is lame).While the hardware was being designed, the windows developers got a head start and cranked away on the end-user software. Their platform of choice was AJAX running on top of pocket internet explorer. You don't need to be a rocket scientist to predict what would happen upon running their heavy-weight java script/IE based app on a 400MHz PXA270 XScale processor. Fortunately for them, we were able to accelerate the performance by migrating the system to Adobe Flash for ARMV4I/Windows Mobile.

Long story short, a good embedded developer will be thinking about software performance, and bench-marking end-user software from day #1. You need to start desigining your software for your target device, and use any sort of emulation or cross-platform development with extreme caution. Get the development kit with your embedded processor of choice as a stop-gap until your first rev hardware arrives. Save yourself the headache of discovering that the software you developed on your 500 Watt PC will run differently than on your 1 Watt embedded processor.

Bicycles and Roads

My good pal Anders frequently has told me about how some folks (yes, many of them conservative) think bicyclists should pay taxes for using the roads the cars drive on. He makes the argument that this shouldn't be necessary, since bicycles produce much less wear and tear on the road than cars. On a bicycle ride (ironically) I realized how I don't agree with this argument, because of what a road is. A road is much more than a paved stretch, it is a system.

As a quick side note, please understand that I am not saying bicyclists should pay taxes on the roads. I for one am a cycling fanatic, and it is absolutely great that so many people bike in my city. As far as who should be paying for roads I will leave to the IRS (until another bike ride where I come to some more random conclusions).

So what sort of parts and processes of this "road" system that costs money? And most importantly, ones that aren't just the pavement? Here are just a few I thought of on my ride:

Traffic Lights

Most roads have traffic lights. Although several rural roads don't have them, I can't think of a bike ride I've been on where I didn't see and use traffic lights. Both cyclists and cars use traffic lights. And although neither puts wear and tear on them (since the simple act of looking at them is the use), the simple act of maintaining them could add up. Electricity. Weather damage. Replacing parts as they age past the lifetime they were designed to have.

Evening Lights

Same as above, except evening lights are much more numerous than traffic lights. They use quite a bit more power too, as there isn't any fancy LED low-power version. Yet. The cost of all those light bulbs add up. Both cyclist and cars use these, and put equal amount of wear and tear.

Patrol

Beyond the core infrastructure of stop lights and evening lights, the roads are patrolled. Cyclists depend on cars to follow the rules, and cops are around to enforce them. And vice versa.

Cleaning

Roads get very dirty. Cars contribute to the mess, but weather does also. Combine this with the surrounding environment (dirt, sand, leafs).

Engineering

Roads are constantly being evaluated for safety and throughput, and often times civil engineers will need to add overpasses. Or create bike lanes (or in our city, bicycle boxes). Being an engineer, I know expensive this can be. It is something all users of the road take advantage of, not just cars.

There are several more I thought up of too.

A road is more than just pavement, it is a system. The cost of running it is expensive, but most of the time, all users benefit from the cost that goes into it. Not just cars.

If you do think a road is just pavement, go find a abandoned road and try to drive or bicycle on it. There are two I've actually tried this on, one in Wyoming and one in Vancouver. I failed. The sheer quantity of debris, cracks and washed out regions made it impossible. When a road becomes just pavement, and nothing else-no service, lights, maintenance-it becomes unusable.