Re: Embedded Processor/Compiler Selection

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

Roger Racine[SMTP:rracine@draper.com] writes:
|One of Draper Laboratory's first Ada projects was an engine controller.
|That project used a bare Ada runtime system quite successfully.  The only
|problem with that approach is the slowness of loading programs (typically
|over an RS232 line).
|
    This sounds pretty typical of what we have around here. We get an
    embedded compiler where the RTK supplied with the compiler is the
    closest thing to an RTOS we've got. Usually, the RTK needs a
    little customization for peculiarities of the given system we are
    sticking it in. (Quite often, there's no clock, so we disable all
    the "delay" features, for example) We usually have either a UART
    or a Mil-Std-1553 bus for communication with the development
    equipment & program loading. Yes it can get slow, but usually,
    you're running tests on whatever you've put into EEPROM, and
    program loads are not too frequent.

|One does not even have to completely forego using all the Ada features.
|On the International Space Station program, they use the timer interrupt to
|get the executive task running, and after the high-priority, extremely
|time-critical processing is complete, the executive initiates the
|lower-priority tasks.  This might not be possible with your engine
|controller if you are using floating point registers in a slow processor.
|Some of the processors I have used took on the order of 100 microseconds to
|save the floating point registers during a context switch.  Your mileage
|may vary. :)  In that case you might want to continue your approach (cyclic
|executive).
|
    The YMMV part is really important. I had one system where we
    clocked the response from the instant our 1mSec interrupt went off
    to the instant we hit the first instruction of the interrupt
    procedure and found it to be on the order of 60 microseconds. Most
    of the rest of the world is thinking "big deal" but when you burn
    up this amount of time once every milisecond, that's 6% of your
    CPU time budget spent doing absolutely no useful work. And it only
    gets worse as the tasking environment comes into play.

    We can and do use the Ada tasking features in building executives.
    Its just that one has to be real careful about what you use when
    you are in the really high speed parts of the system. I know the
    compiler vendors work very hard at trying to make the tasking
    features as quick as possible. Ada95 tries to provide some help
    with protected types and all that. (I *really* want to conduct
    some experiments with this in our real time world to see how much
    better it is. But that means getting an Ada95 compiler for some
    sort of inexpensive SBC, and I despair of seeing this happen) But
    at really high cycle rates, you often can't afford to waste any
    time, so you go with the simplest possible implementation.
|
|I have used Rational, XD-Ada and Aonix personally, and Draper personnel
|have also used the TLD compiler, all using the bare runtime system (all
|Ada83).  We have had varying happiness with them, but we have had
|unqualified success with all of them.  Our unhappiness came from "ease of
|use" issues, and "cost of source to runtime system" issues.  I do not think
|we have had a project yet where we were able to avoid at least looking at
|the source to the runtime system.  We have done our share of modifying that
|source in some projects.
|
    We've had quite a bit of experience with XD-Ada and have been
    happy with the results. It's good to hear about the others, too.
    I'm curious about the target processors you were using these
    compilers with. (Our XD-Ada experience is primarily with
    Mil-Std-1750a and MC680x0 targets)

    I don't know how you get around the "cost of source to runtime
    system" issue when you build systems that are unconventional in
    nature. Usually, the embedded compiler is targeted to some
    "generic" kind of SBC that presumes you're going to plug a board
    into a VME bus or something similar and go off to the races from
    there. But when you're designing the computer from the ground up,
    the preconceived notions and unwarranted assumptions built into
    the RTK just don't hold and you've got to be able to change them.
    Usually, it isn't some sort of wholesale rewrite, but you do need
    to make adjustments.

    Thanks for the input.

    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.
=============================================================================