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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fd6dd,c78177ec2e61f4ac X-Google-Attributes: gidfd6dd,public X-Google-Thread: 103376,c78177ec2e61f4ac X-Google-Attributes: gid103376,public From: dana@indyweb.net Subject: Re: ada and robots Date: 1997/06/06 Message-ID: X-Deja-AN: 246571556 References: <338CDA96.53EA@halcyon.com> <338F5D7D.6C03@tiac.net> <338F9D05.5EB3@bix.com> <01bc6dfe$9f580d80$21fa82c1@xhv46.dial.pipex.com> <3395A015.41C67EA6@digicomp.com> Organization: Indy Web Inc. Newsgroups: comp.robotics.misc,comp.lang.ada Date: 1997-06-06T00:00:00+00:00 List-Id: In article , aklee@no_spam.bonsai.net (Albert K. Lee) wrote: > So does anybody have any answers for the original poster? That guy > who was asking quite innocently about specific techniques and tools > for embedded programming using the Ada language? > > I am interested as well and would rather see answers than read thru > incessant language wars. > > > -Albert I think the general lack of response back to the group could be taken as response in the negative. I e-mail the original poster with a more detailed response but I'll post a summary here for all you curious folks. I assume the original question was REALY about looking for compilers for the calss of low cost 8 -16 bit processors typically used in hobbyist type robots. ("Hobbyist", not to demean these robots, just classify them) That question raises several other on obvious questions. 1) Q: are there any Ada compilers for 8051s, PIC-1X's, 6502, 80C196KB, etc micro controllers? A: No, or at least not many. It's hard to put an exact reason as to why but it is thought that these MCs are just "too small" in terms of address space etc to support a multitasking language/runtime. Hello world generated by DDCI's sun cross 80386EX compiler is JUST under 16k with the non-tasking runtime. I've seen similar performance from other Ada compilers. The whole answer is much longer but has been discussed at length in this group. Now, that being said, it is still worth a check of adahome to see what the vendors have. I could be wrong. It wouldn't be the first time:-) 2) Q: Is Ada used in robotics? This is a question several occasional posters to this group could have answered. But the answers weren't exactly what the original poster was looking for. Robotics is a vary broad field ranging from little critters skittering about on the floor with 8 bit micro controllers to large kinematically redundant manipulator mechanisms with multiple 32 bit high performance processors. A: Yes and No. No, due to the use of 8-16 bit MCs in critterbots, Ada is _probably_ not a good candidate for them. But with the falling cost and power requirements and the fact that 1M of RAM could be purchased with the change on the floor of my mini van, I think a 32 bit MC could be used in criterbots very soon. Yes, the former robot lab at goddard space flight center, as well as at least one robot lab at NIST controlled their robots with 25Mhz 386/387's running software written in Ada. These research efforts are long gone in history. I participated in the effort at GSFC. I also worked on a more recent effort where robot applications were written in C++, running on LynxOS running on Pentiums. As another poster stated, "good or poor software can be written in any language". Quite true. The individual programer and project probably have a greater impact at this level. I however have written robot control software in C, C++, and Ada and from my personal anicdotal experience, my C had the lowest productivity in terms of functionality per time period, and the highest rate of flaws found per function. My C++ just nosed out my Ada83 in apparent productivity per time period BUT had a much higher flaw rate and the flaws were much more difficult to remove than the Ada83 flaws. Debugging large systems by rummaging through the entrails of core dumps is VERY slow. The few cases where I have seen C/C++ head to head with Ada on the same or similar projects, the post release flaw rate was where C/C++ got murdered. They did usually beat the Ada implementation in productivity. But this is starting to sound like a language war. The SEI (software engineering institute) CMM (capability maturity model), as I interpret it, seems to indicate that intelligent language selection is an activity of VERY mature software organizations (wouldn't switching languages, however, seem like an immature undertaking?) because of the long term historical data needed to spot deficiencies in languages. It's easy to look over a language like Ada, C, C++, Java and say "Language X will be the BEST to write robot code!" Being correct in this is quite a bit trickier. Sometimes library availability drives this decision. I'm still looking for the deffinitive answer on how immature organizations should choose programming languages. Where one stands on this issue, also depends quite a lot on where one used to sit! If _I_ were to write robot controller software, and _I_ could choose the language, I would dig out my old 9-tracks tapes of Ada robot library code and catapult myself and my project ahead by many thousands of lines of tested re-useable code. Other, not so lucky people, might not have millions of dollars worth of public domain code on a tape in their closet (-8-0). When I suggested that by choosing Ada we might save whopping large amounts of time and money with reuse to a former employer, they looked at me like a bug. The original poster also mentioned how Ada was designed to be targeted at the "embedded market". I think this causes some confusion. The "Embedded market" ranges from small 2kbyte programs, writte in assembler, running on microcontrollers, to megga-line projects distributed across hundreds of processors controlling life and mission critical activities. Ada was targeted towards the traditional "medium to large" projects. I think this is where DOD was getting their butts kicked with cost overruns, schedule slips and project failures. It's a question of scale. One guy banging out ASM can handle a simple programming project. There are lots of personal electronic and other devices successfully brought to market with this approach and thats just fine for them. The disaster occurs when the "one dude hacking" model is scaled up to larger projects. This sort of thing is the nucleus for many books on software project management. Which would be a good point to depart from this discussion.