From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b736111afc6e20ee X-Google-Attributes: gid103376,public From: "Marin David Condic, 561.796.8997, M/S 731-96" Subject: Re: Embedded Processor/Compiler Selection Date: 1998/02/24 Message-ID: <98022409593985@psavax.pwfl.com> X-Deja-AN: 328227902 Sender: Ada programming language Comments: To: rracine@draper.com X-VMS-To: SMTP%"INFO-ADA@VM1.NODAK.EDU" X-VMS-Cc: SMTP%"rracine@draper.com",CONDIC Newsgroups: comp.lang.ada Date: 1998-02-24T00:00:00+00:00 List-Id: 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. =============================================================================