Re: Embedded Processor/Compiler Selection

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

>My suggestion is to have one of the Ada vendors host their compiler on
>Windows CE, which is hosted on multiple CPUs. CE must have a common
>intermediate form. You do NOT have to use any part of the Microsoft GUI or
>Windowing environment. CE was designed for embedded systems and is building
>market share. This way, you will not be sponsoring a special but helping to
>start a viable maintained, commercial product. Amusingly, Ada code which
>uses Latin 1 will have a significant advantage in code size over the other
>compilers, which use 2 byte Unicode.
>
    I'm afraid I don't know much about Windows CE except that its some
    kind of stripped down version of WindowsNT for things like PDAs
    and Gameboys. Correct?

    If this is the case, there's some credible reasons to believe that
    it is unsuitable for (at least hard) real time systems. (see:
    http://www.realtime-info.be/encyc/market/rtos/ntspecial.htm) Maybe
    Windows CE has corrected these problems?

    Even if its suitable, I'm not sure we could use it in our current
    application. Just briefly, here's a look at the system:

    The engine control is a dual-redundant computer with the two
    channels connected by a Manchester data link. Both channels have
    to synchronize their 1mSec cycles to within about 50uSec and have
    to stay in synch for data coherency and data latency reasons. (You
    like to be operating on loop closure data that isn't more than one
    cycle old, if possible.) Each channel consists of 3 general
    purpose processors and a digital signal processor, which also have
    to operate in synch with each other for the same data coherency
    and latency reasons. Each channel reads A/D converters, F/D
    converters, Discrete inputs, etc according to a schedule
    determined by which cycle number it is in. (Point the MUX, read
    the data, then execute the software that depends on that data to
    be as fresh as possible.) These deadlines are pretty serious
    deadlines because you're tracking the motion or state of physical
    hardware moving about rather rapidly. If you miss reading or
    processing the data in a timely manner, things can slam into stops
    & break, or a pressure can exceed some limit and start a stall or
    any other number of things generally considered by pilots &
    passengers to be "A Bad Thing".

    Historically, we have never encountered a commercial RTOS that
    would effectively do the job we needed done. Either it would have
    to have been heavily tailored or would run too slow or would suck
    up too much of the CPU time or all of the above. So we tend to do
    things with a relatively simple cyclic executive driven by
    interrupts. It may not be real exciting, but it works pretty well.

    Maybe Windows CE is different and I'm curious enough about it to
    do more research if you can point me at a resource. All other
    things being equal, there are obvious advantages to using a
    commercial RTOS where possible. If we can't use it to drive our
    engine control, we might very well be able to use it in other
    applications.

    Thanks for the info.

    MDC

Marin David Condic, Senior Computer Engineer     Voice:     561.796.8997
Pratt & Whitney GESP, M/S 731-95, P.O.B. 109600  Fax:       561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:  CONDICMA@PWFL.COM
=============================================================================
    "Because that's where they keep the money."
        --  Willie Sutton when asked why he robbed banks.
=============================================================================