RTOS's and Windows CE question

QNX fits your description, both versions 4 and 6, though version 4 is close to its end of life. It is used widely in industrial and automotive applications, Cisco uses QNX it their routers.

As it is licensed per unit, with thousands per year you'll have very good price.

Another interesting place is

(I am not affiliated with them, just used QNX for several years :)

HTH, Vadim

You have specified a minimum worst case response time - that is precisely what real-time means. To my knowledge, CE is not real-time, although most versions are what is termed "soft real-time", meaning that it probably will respond fast enough, but there are no guarentees. Whether that is good enough or not depends on what might happen if a response takes longer than 2 msecs once in a while.

CE is an appropriate choice where you want to build a small device that looks like windows, and can run pretend-windows applications like pocket word processors. If you don't have a screen, or don't need to run ready-made CE applications, then it has no advantages over other systems, and plenty of disadvantages (cost, large footprint, lack of source code, poor reputation).

Alteratives to look at are qnx, linux (available with hard real-time varients if needed), eCos, RTEMS, vxWorks, microC OS 2.

There are wide ranges depending on whether you want to run on an 8-bit microcontroller or a full embedded pc, or something inbetween. If say what sort of hardware you have available, and what you want to do with the system, then you'll get more useful advice.

And hence you'll be carrying around a few million lines of someone else's code with all the inherent risk that that implies (whether it's Micro$oft code or open source) for no good reason.

Well, that depends a lot on processor speed, system loading and what you mean by response time. Timer granularity in CE3.0 is 1mS IIRC, but interrupt response time is much, much quicker (I think still on the order of

10s of microseconds on a 233MHz Pentium, though).

The development I worked on used 3. However, if I was forced to use CE on a new development, I'd use whatever the latest non-beta release was. At least that way you might still be able to get support and tools by the end of the development.

It's probably about as stable (i.e. undergoes about the same frequency of major revisions these days) as Linux. But I think you may have meant reliable rather than stable. Certainly on a dedicated system like the one I was involved with, it didn't fall over (nothing worse for your confidence in electronic banking than walking up to an ATM and being confronted with a BSOD).

Sort of. It's got a pre-emptive scheduler with multiple priority levels. Like any real OS (rather than an RTOS), though, it's way too complicated (allocating, freeing, garbage collecting) to be able to achieve the sort of guaranteed response times required to consider a system hard real-time.

Humongous compared the world of 8 bit processors that I usually frequent. Smaller than NT/XP. Microsft claims as little as 200k, but allow 4Mb for reasonable functionality with a TCP/IP stack, GUI, File system, etc. Don't need those? Find something else.

I've worked (in a requirements and architectural capacity only) with a team that implemented a real time system using CE. The particular technology development company doing the development had a bias towards hiring OO Windows programmers, and "when all you've got is a hammer, everything looks like a nail". The development took about five times the number of man-hours that I estimated it would have taken using a more established RTOS, Windows experience was not directly transferable - more time was spent on things that worked almost like Windows than on stuff that was completely different. The one thing that did shine was the GUI (but then you don't want that).

I'd consider a more traditional RTOS or perhaps QNX, eCos, or one of the more commercial RTLinuxxy things.

HTH. All my own opinions and coloured view of my experience, I'm afraid. So, as always, YMMV.

Cheers,

-- Alf Katz snipped-for-privacy@remove.the.obvious.ieee.org

I am evaluating embeddable operating systems for a client who will be using one in a new commercial product in the industrial control market, sales of which are expected to be many thousands per year.

The product will be truly embedded having no display capability, but will contain both an ethernet port, and a USB port, to allow for customer configuration etc. Although the product has no 'hard' real-time requirement, the worst case response times should be less than one or two milliseconds, under all operating conditions (that includes ethernet activity).

Amongst a few alternatives (and despite my natural inclinations :) Windows CE is on the list to be considered. Any suggestions on which CE variant might be applicable (e.g. CE 3, CE 4.0, CE 5.0, CE .NET)? Can CE considered to be stable? Is it real-time? What about footprint? Despite a Google search on this (and other) groups surprisingly little objective opinion was unearthed with regard to Win CE in embedded applications.

Any other RTOS suggestions welcome - cost is not the major factor, performance, support, stability etc. is.

Mike Harding

I thought I remembered reading that CE 3.0 switches between applications in 50 milliseconds or less. Prior versions were 250 ms. Can someone explain how response times and "application switches" can be compared with respect to an intended use?

thanks,

Jonathan

Take a look at MicroC OS 2.

You can even purchase Jean's book first and try out the OS. Then if you use it in your product you have to license it. If you want something for free you could find the original MicroC OS on the net for your processor.

Mark

... snip ...

I can do better with a PIC in assembly, or even with an ancient

8008.

--
"Churchill and Bush can both be considered wartime leaders, just
 as Secretariat and Mr Ed were both horses." -     James Rhodes.
"We have always known that heedless self-interest was bad
 morals.  We now know that it is bad economics" -         FDR

I wouldn't consider CE 3.0 - this is now in "maintenance" by Microsoft. This leaves you with CE 4.2 and CE 5.0; CE 5.0 has only been released in the last couple of months. The lifetime of CE (per version) appears to be slightly better than mainstream Windows. CE 4.2 was an improvement, in terms of functionality and mainstream Windows compatability. As others have pointed out, CE is similar to but *not* identical with Windows so don't expect to port any application straight across. One instance of this is exception handling in C++, although this is addressed in CE 5.0.

On one platform that I worked on, moving from CE3.0 to CE4.2 increased the image from 9MB to 11.5MB for the same functionality. This was with a GUI (but a minimal shell). Even a non-GUI platform is relatively large (several MB). The target application for the platform on which I worked didn't have any real-time requirements. You can get some source for CE but, given the size of the OS, this is relatively small (only a few MB of code :-) ). I found that Microsoft were helpful when we reported a fault.

QNX has always impressed me as has uCos. USB host support in the OS may be the thing that defines your choice of OS.

Andrew

CE's default thread time-slice is 1ms

I think you are referring to what MS calls the quantum (maximum time-slice).

If we are talking "default quantum", then see the following from the internet (

)

******************** Q: BenH : I have an embedded app with multiple threads at the same priority level. When one of these is encrypting data (about 20 ms), the others appear to be starved. Why is this occurring? John_Eldridge_MS A: BenH: The default thread quantum is 100ms so unless your thread yields it will run continuously for 100ms before switching to the next thread at the same priority. ***************

That, my friend, is 1/10 of a second. I remember the quantum on the version of CE I messed with being default to 100ms, but that you could change it by hacking the OS somehow. Other versions may have a different quantum.

Cheers,

Jody

It appears that these figures apply in the situation when multiple processes are executed at the same priority level at a round robin fashion. I don't understand why anybody designing a real time system would put the tasks on the same priority and use round robin scheduling.

Much more interesting would be the independent worst case figures for wake up times after an interrupts satisfies a read request or the switching time from SetEvent to WaitForSingleObject.

When using any flavour of Windows and requiring some kind of timing accuracy, do not use the SetTimer, since it will use the message queue even if only a callback routine (no window handle) is specified. The other traffic in the message queue and the responses to these messages will mess any timing accuracy. Use the timeout parameter in WaitForSingleObject or use multimedia timers when available.

Paul