Forums

RTOS's and Windows CE question

Started by Mike Harding September 9, 2004
On Thu, 09 Sep 2004 16:27:31 -0700, Mike Harding 
<mike_harding@nixspam.fastmail.fm> wrote:

> Any other RTOS suggestions welcome - cost is not the > major factor, performance, support, stability etc. is.
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. http://www.qnx.com Another interesting place is http://www.openqnx.com (I am not affiliated with them, just used QNX for several years :) HTH, Vadim
"Mike Harding" <mike_harding@nixspam.fastmail.fm> wrote in message
news:dlp1k0581uf4g6794fs5ejc3s614cqjtt6@4ax.com...
> 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). >
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.
> 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 >
> The product will be truly embedded having no display > capability,
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.
> 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).
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).
> > 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)?
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.
> Can CE considered > to be stable?
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).
> Is it real-time?
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.
> What about footprint?
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.
> Despite a Google search on this (and other) groups > surprisingly little objective opinion was unearthed with > regard to Win CE in embedded applications. >
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).
> Any other RTOS suggestions welcome - cost is not the > major factor, performance, support, stability etc. is. >
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 alfkatz@remove.the.obvious.ieee.org
>Any other RTOS suggestions welcome - cost is not the >major factor, performance, support, stability etc. is.
Costs are not limiting ? Wow, must be a military project ? If not, maybe look at my employers HP: www.sciopta.com -- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use <same-name>@epost.de instead !
On Thu, 9 Sep 2004 14:39:10 +0200, "David Brown"
<david@no.westcontrol.spam.com> wrote:

> >"Mike Harding" <mike_harding@nixspam.fastmail.fm> wrote in message >news:dlp1k0581uf4g6794fs5ejc3s614cqjtt6@4ax.com...
[...]
>> 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). >> > >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
I evaluated WinCE for a project at a PPOE about 5 years ago. At the time, WinCE 2.x was acknowledged by Microsoft to be less than a hard real-time OS, but the forthcoming (at the time) WinCE 3 was going to be truely real-time. We didn't use it because it wasn't the best fit, but we probably could have without undue difficulty.
>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).
From what I remember WinCE would be ideal in an environment with a graphical display and user interaction, especially if your programmers are familiar with the Win32 API. It's getting some use in telematics. It doesn't sound like an exceptionally good fit for the OP's project.
> >Alteratives to look at are qnx, linux (available with hard real-time >varients if needed), eCos, RTEMS, vxWorks, microC OS 2.
I'll second QNX because I like the architecture, and I've actually used it. I've looked at RTEMS, but the project I intended to use it on got cancelled. I've not used eCos, or even looked at it, but it sounds like a better choice than Linux. I evaluated VxWorks for another project (back when Tornado was new) and rejected it because the tools were too buggy to be useful. The OS itself looked OK. Micro C/OS might be too lightweight. The USB requirement might be the kicker. If you have to have USB, the OS which handles that best is probably the best choice. Just about everyone gets TCP/IP right (or close to right) these days. Regards, -=Dave -- Change is inevitable, progress is not.
Mike Harding wrote:
> 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
Look at MicroC/OS-II on www.micrium.com. Get started for the cost of a book ($70) which includes a CD-ROM containing all the source. Commercial license with the latest version is less than $3000. No royalties. Ethernet and USB direct and from 3rd parties available as options. -- Scott ExoTech R&D, Inc.
On 2004-09-09, Dave Hansen <iddw@hotmail.com> wrote:

> From what I remember WinCE would be ideal in an environment with a > graphical display and user interaction, especially if your programmers > are familiar with the Win32 API. It's getting some use in telematics. > It doesn't sound like an exceptionally good fit for the OP's project.
I haven't used CE either, but the people I've talked to who have done so say that the desktop Win32 API is different enough from the WinCE API that experience with the Win32 API isn't all that applicable. WinCE development does use the same toolchain and environment, so that experience does transfer. -- Grant Edwards grante Yow! Don't SANFORIZE me!! at visi.com
On Thu, 09 Sep 2004 16:27:31 -0700, Mike Harding wrote, in part:
> Any other RTOS suggestions welcome - cost is not the major factor, > performance, support, stability etc. is. > > Mike Harding
Take a look at velOSity and INTEGRITY from Green Hills Software, http://www.ghs.com/ (my employer).
Mike Harding wrote:

> 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).
Without display, any windows is not really justified. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net
On 09 Sep 2004 15:28:44 GMT, Grant Edwards <grante@visi.com> wrote:

>On 2004-09-09, Dave Hansen <iddw@hotmail.com> wrote: > >> From what I remember WinCE would be ideal in an environment with a >> graphical display and user interaction, especially if your programmers >> are familiar with the Win32 API. It's getting some use in telematics. >> It doesn't sound like an exceptionally good fit for the OP's project. > >I haven't used CE either, but the people I've talked to who >have done so say that the desktop Win32 API is different enough >from the WinCE API that experience with the Win32 API isn't all >that applicable. WinCE development does use the same toolchain >and environment, so that experience does transfer.
I have some small experience with Win32, though not graphical applications. In particular, at a PPOE I wrote some libraries to allow separate processes to share data. Specifically, a shared buffer interface along with some data structures (a deque and an application-specific structure) with the required behavior. At the time I described Win32 as being similar to the old text adventure games -- you don't have exactly what you need, but if you dig around a little and find the magic incantation, you can build it. For example, the routine to get an item from the deque had an option to block if the deque was empty until data was available. In order to do this I had to have one process wait until another woke it. This is harder than it should be. IIRC, the process to be blocked had to create an event, and record both the event handle and its own process handle in the shared buffer. The waking process would use the blocked process' process handle to create a duplicate of the event handle, signal the event, then destroy its handle to the event. After it was awakened, the blocked process would then destroy the event to recover the resources. The point of the story is that Win32 API experience should help you find your way out of the twisty little passages, all alike... Regards, -=Dave -- Change is inevitable, progress is not.