comp.lang.ada
 help / color / mirror / Atom feed
* Embedded Processor/Compiler Selection
@ 1998-02-19  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  1998-02-20  0:00 ` John E. Doss
  1998-02-20  0:00 ` phil.brashear
  0 siblings, 2 replies; 14+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1998-02-19  0:00 UTC (permalink / raw)



    Embedded Processor/Compiler Selection

    We are currently in the process of trying to select both a
    processor and an Ada compiler for the next generation of engine
    control. We would like to get feedback from the Ada community on
    what is being used, pros/cons of various products, general
    comments and suggestions.

    Here is where we are at right now:

    We are trying to evaluate Ada compilers for the PowerPC, MIPS and
    Pentium processor families. We would like to know of any
    experiences with using these processors as embedded machines with
    Ada as the embedded development language. What type of embedded
    system? Which Ada compiler? How well/poorly is it working out?
    What sort of problems are you encountering?

    Since we are not at all committed to a processor at this point, we
    would like to hear about almost any recent 32 bit embedded system
    development using Ada95. (Note that we are not doing development
    using a SBC with some commercial RTOS - we build the processor
    board from the ground up and build all of the software that
    operates in it as well. So we are interested in experiences
    similar to the work we are doing and need to consider compilation
    systems aimed at this sort of bare machine.) If you have had some
    experience in selecting a processor/Ada compiler combination
    recently and wouldn't mind sharing the knowledge you have gained,
    please drop me a line.

    Thanks for any information you can send.

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




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: Embedded Processor/Compiler Selection
@ 1998-02-20  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  0 siblings, 0 replies; 14+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1998-02-20  0:00 UTC (permalink / raw)



    Embedded Processor/Compiler Selection

    Our compiler/processor search team is also looking at the
    following processors:

    Coldfire
    StrongARM
    Super H - Hitachi
    RH-32

    We are interested in hearing about any sort of embedded
    development with these processors that is similar to what we are
    constructing: An engine control with a highly specialized
    computer, having hard real time and reliability constraints.

    Naturally, we are interested in any experience (and sources for
    compilers) for programming these devices in Ada. (If this turns
    out to be the right answer, we might consider paying for a port.
    But we'd have to be convinced that this was the right long-term
    processor selection.) We would be interested in hearing about
    applications that are not programmed in Ada, provided they are
    reasonably similar to our own usage - high reliability, hard real
    time, bare silicon/ground up programming.

    If you can tell us about your usage of these processors, what you
    like/dislike about them, sources for tools, price/performance,
    whatever - we would find it a big help.

    Thanks for any information you can send.

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




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Embedded Processor/Compiler Selection
@ 1998-02-21  0:00 Robert C. Leif, Ph.D.
  1998-02-21  0:00 ` Robert Dewar
  0 siblings, 1 reply; 14+ messages in thread
From: Robert C. Leif, Ph.D. @ 1998-02-21  0:00 UTC (permalink / raw)



To: Marin David Condic
Senior Computer Engineer
Pratt & Whitney

From: Bob Leif, Ph.D.
Vice President Ada_Med

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.
----------------------------------
You wrote:
Embedded Processor/Compiler Selection

    Our compiler/processor search team is also looking at the
    following processors:

    Coldfire
    StrongARM
    Super H - Hitachi
    RH-32

    We are interested in hearing about any sort of embedded
    development with these processors that is similar to what we are
    constructing: An engine control with a highly specialized
    computer, having hard real time and reliability constraints.

    Naturally, we are interested in any experience (and sources for
    compilers) for programming these devices in Ada. (If this turns
    out to be the right answer, we might consider paying for a port.
    But we'd have to be convinced that this was the right long-term
    processor selection.) We would be interested in hearing about
    applications that are not programmed in Ada, provided they are
    reasonably similar to our own usage - high reliability, hard real
    time, bare silicon/ground up programming.

    If you can tell us about your usage of these processors, what you
    like/dislike about them, sources for tools, price/performance,
    whatever - we would find it a big help.

    Thanks for any information you can send.

    MDC

Marin David Condic.
--------------------------------------------------------------------------




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: Embedded Processor/Compiler Selection
@ 1998-02-23  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  1998-02-24  0:00 ` Robert Dewar
  0 siblings, 1 reply; 14+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1998-02-23  0:00 UTC (permalink / raw)



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




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: Embedded Processor/Compiler Selection
@ 1998-02-23  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  1998-02-24  0:00 ` Robert Dewar
  0 siblings, 1 reply; 14+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1998-02-23  0:00 UTC (permalink / raw)



phil.brashear@ACM.ORG writes:
>My standard response to such postings is to remind people of the Ada Compiler
>Evaluation System (ACES), a collection of performance and usability
>assessment tools, including analysis tools for comparing results from
>different configurations and for comparing results of related tests run on
>the same configuration.  If (especially) performance is important to you, and
>you have a pretty good idea of your requirements, then the ACES can be quite
>useful.  It's not particularly easy to use, requiring some time investment,
>but advice is available.  I'd start with the "Quick-Look" facility to cut the
>number of candidates down, then use the full ACES to compare the final 2 or 3
>candidates.
>
    We've used ACES before and the resources at the AdaIC have already
    been helpful in identifying validated compilers. However, I think
    we're more at the conceptual phase of the selection process where
    we are trying to figure out which processor is "right" because of
    market considerations, successful applications, infrastructure,
    etc. When we've more or less figured out where we'd like to head
    from that standpoint, we'll be much more interested in performance
    evaluations, etc.

    Thanks for the tip.

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




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: Embedded Processor/Compiler Selection
@ 1998-02-24  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  1998-02-24  0:00 ` Rakesh Malhotra
  0 siblings, 1 reply; 14+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1998-02-24  0:00 UTC (permalink / raw)



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




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: Embedded Processor/Compiler Selection
@ 1998-02-27  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  0 siblings, 0 replies; 14+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1998-02-27  0:00 UTC (permalink / raw)



Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>
>No, that's a misunderstanding. Windows CE is indeed intended for hard
>real time embedded applications. Look for example at the recent newsstory
>on its adoption for a multi-million unit High-definition cable TV gizmo.
>
    Some folks have mentioned to me that Windows CE has been designed
    to work for real time systems (I'd still like to verify that it
    doesn't have the interrupt uncertainty problems of NT) but that
    there are other complaints. One complaint is that CE can currently
    only be used to work with Microsoft development tools due to
    proprietary load module formats. Another objection is that it is
    large (I can't believe the numbers that were given to me, so I
    won't quote them. I've got to chalk it up to a misunderstanding.
    But still the indication is that it is quite sizeable.)

    So it would seem that for the time being, it may be beyond
    consideration for my kind of app. But if it is being used in
    something like an HDTV gadget of some kind, maybe it has some
    potential. More research is clearly needed.

    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
=============================================================================
     And who dares mock Spam?
     You? you? you are not worthy
     Of one rich pink fleck
        --  Spam Haiku
=============================================================================




^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~1998-02-27  0:00 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-02-19  0:00 Embedded Processor/Compiler Selection Marin David Condic, 561.796.8997, M/S 731-96
1998-02-20  0:00 ` John E. Doss
1998-02-20  0:00 ` phil.brashear
  -- strict thread matches above, loose matches on Subject: below --
1998-02-20  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1998-02-21  0:00 Robert C. Leif, Ph.D.
1998-02-21  0:00 ` Robert Dewar
1998-02-23  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1998-02-24  0:00 ` Robert Dewar
1998-02-23  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1998-02-24  0:00 ` Robert Dewar
1998-02-25  0:00   ` phil.brashear
1998-02-24  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1998-02-24  0:00 ` Rakesh Malhotra
1998-02-27  0:00 Marin David Condic, 561.796.8997, M/S 731-96

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox