Embedded

Embedded

[Lanarcam]

Suppose you have requirements for a basic embedded system such
as a few digital I/O, analog I/O, RSxxx communication links,
alphanumeric LCD, etc.

The usual way is to select a microcontroller with the required
I/O and based on the complexity some amount of RAM and ROM.

You often choose a microcontroller from a family you are
familiar with. You then select an OS or no OS, depending
on the requirements.

If you decide to write the code in Ada, how do you know
there will be a compiler that will target the microcontroller?

Do you have to ask every vendor or is there a list of
supported CPU for each compiler?

How will the choice of Ada affect the amount of RAM and ROM
needed? 

Regards

Re: Embedded

[Martin Dowie]

Lanarcam wrote:
> Suppose you have requirements for a basic embedded system such
> as a few digital I/O, analog I/O, RSxxx communication links,
> alphanumeric LCD, etc.
> 
> The usual way is to select a microcontroller with the required
> I/O and based on the complexity some amount of RAM and ROM.
> 
> You often choose a microcontroller from a family you are
> familiar with. You then select an OS or no OS, depending
> on the requirements.

yup

> If you decide to write the code in Ada, how do you know
> there will be a compiler that will target the microcontroller?
> 
> Do you have to ask every vendor or is there a list of
> supported CPU for each compiler?

Well, other that 'C' (which always has a compiler for any target
[not necessarily ISO C]), that's what you have to do for any
language!


> How will the choice of Ada affect the amount of RAM and ROM
> needed? 

Shouldn't affect it too much at all these days - might have in
the passed (Ada83). But the footprints I've seen with various
Ada95 compilers within the last 10 years have all been acceptable.

Make sure the binder/linker can remove unused subroutines - that
advice is good for all languages not just Ada! Otherwise you
may run into problems if the predefined language library is used
and is large.

Cheers

-- Martin

Re: Embedded

[Jeffrey R. Carter]

Lanarcam wrote:

> The usual way is to select a microcontroller with the required
> I/O and based on the complexity some amount of RAM and ROM.
> 
> You often choose a microcontroller from a family you are
> familiar with. You then select an OS or no OS, depending
> on the requirements.

That's the usual way, but that's not necessarily a good way. A better way is to 
choose a suitable language, then choose the hardware to suit the language 
choice. Since Ada's about the only thing around that was designed for embedded 
systems, an unbiased selection of a suitable language will usually choose Ada.

However, even if you do it the other way around, there's at least one compiler 
that produces ANSI C as its intermediate language, so you can always choose Ada.

-- 
Jeff Carter
"Mr. President, we must not allow a mine-shaft gap!"
Dr. Strangelove
33

Re: Embedded

[Marin David Condic]

Interesting in theory, but not very practical. In a commercial venture, 
a LOT more depends on the actual processor chosen than does the language 
  of implementation of the software. For one thing, anything having to 
do with the software implementation is a pure engineering cost whereas 
the microprocessor has both an engineering cost AND a production cost. 
Chip X has no Ada compiler and Chip Y does, but chip X is $0.10 cheaper, 
has a better field reliability history, multiple suppliers, is better 
suited to the existing production line equipment and we're expecting to 
make 10,000,000 units so we'd better be sure there is sufficient supply. 
Would you still choose chip Y because "Ada is Better!"? Are you going to 
save enough on using Ada to justify all of the additional costs and risks?

This is why Ada has an uphill battle in the embedded market. If the 
Adult Supervision around Ada wants to identify that market as the future 
for Ada, then it needs to actually thoroughly understand what the needs 
of that market are and be prepared to address them - or we end up using 
C because that's what we have that we can get the job done with. Ada has 
less than 1% of the embedded system market, so if that's its future, it 
has a really tough row to hoe.

MDC

Jeffrey R. Carter wrote:
> 
> That's the usual way, but that's not necessarily a good way. A better 
> way is to choose a suitable language, then choose the hardware to suit 
> the language choice. Since Ada's about the only thing around that was 
> designed for embedded systems, an unbiased selection of a suitable 
> language will usually choose Ada.

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "The Christian ideal has not been tried and found wanting. It has
      been found difficult; and left untried."

         --  G. K. Chesterton
======================================================================

Re: Embedded

[Colin Paul Gloster]

Lanarcam wrote in
news:1124485055.715288.205290@g43g2000cwa.googlegroups.com :

"[..]

[..] You [..] select an OS or no OS, depending
on the requirements.

[..]"

A partial Ada implementation for 8 bit Atmel AVR processors without
multitasking and without interfacing to an operating system for
substituting Ada processes (tasks) with operating system processes
or threads can be found from
HTTP://AVR-Ada.SourceForge.net

If you want to target 32 or more bits processors, there are a number
of vendors.

If you want to target 8 or 16 bit embedded processors, though other vendors
had supported them in the past, you may find that the Ada vendor
RR Software would be one of the most willing and can provide proper
Ada compilers and runtime executives for small targets: see
WWW.RRSoftware.com/html/prodinf/janus83/other/83embsys.htm
and also please realize that its staff member Randy Brukardt
<randy@RRSoftware.com> had said on Mon, 17 Nov 2003 15:57:57 -0600
in "Re: Is it possible to build an Ada cross-compiler for an 8-bit
embedded target now that gcc 3.X has support for Ada?", Message-ID:
<vrih63aerng37f@corp.supernews.com> in news:comp.lang.ada :

""Peter Milliken" <pet[..]@resmed.com.au> wrote in message
news:zgRsb.200$co2.10332@nnrp1.ozemail.com.au...
> Subject pretty much says it all.
>
> Now that you can build an Ada compiler using gcc 3.X (well,
> according to
the
> build instructions of gcc 3.x :-)), I began to wonder whether it was
> possible to build a cross-compiler for an 8-bit target
> processor. The
8-bit
> processor family in question is already supported by gcc (I
> believe).
>
> When I say "possible", I just mean "follow the cross-compiling
instructions
> and out pops an Ada compiler" - I don't mean, "spend months of work
patching
> various files and then you might have an Ada compiler" :-)

To not answer your actual question at all, but...

As someone else pointed out, the biggest cost/overhead is porting the
runtime libraries. Speaking for Janus/Ada, porting the code
generator/compiler usually only takes a month or so (and that's for
building
a code generator from scratch). But building the basic runtime support
for
exceptions, tasking, floating point (which usually has to be emulated
on
small processors), etc. can take a lot of time. In addition, that
support
can make programs quite large.

Because of this, I think you'd have trouble making acceptable programs
with
a general-purpose compiler like GCC.

Janus/Ada was originally built for Z-80 and 8086 processors without
much
memory. Thus, we only load floating point and tasking support when
they are
used. That isn't very valuable on standard systems like Windows these
days,
but it matters a lot on 8-bit systems.

The only reason that we don't support 8-bit processors is a lack of
demand.
Everyone seems to use a different processor, and thus we cannot really
justify the investment building code generators (easy) and runtime
libraries
(not as easy) for each one.

Of course, we're always interested in customization projects, but that
won't
help you convince your manager...

                   Randy Brukardt"

Jeffrey R. Carter said:

"[..]

[..] there's at least one compiler
that produces ANSI C as its intermediate language, so you can always
choose Ada."

Mr. S. Tucker Taft's AdaMagic Ada to ANSI C compiler (sold by SoftCheck:
WWW.SofCheck.com/products/adamagic.html , Lanarcam: I would suggest
you to remember the compiler's and the person's name: the name of
company has changed a few times) could be used: but do not forget that
C compilers for microcontrollers are often not ANSI compliant,
though they may be compatible enough with AdaMagic.

Targets for various vendors' compilers listed on
HTTP://AdaIC.org/compilers/cpl/lists/CPLbase.html include:
Analog Devices ADSP 21020; Algorithmics P-4000i (R4600);
PowerPC; Analog Devices Visual DSP 4.0; Analog Devices SHARC 21060;
Heurikon Baja (R4700);
Heurikon Laguna (R4600); Heurikon Malibu (Mips R3081);
Intel i960MC; Lockheed Martin RAD6000; MIPS R3000;
MIPS R4000; Motorola 68040; Raytheon Extended Weapons Control Computer
(EWCC); and Siemens Nixdorf RM 200.

More from HTTP://AdaIC.org/compilers/report83.html :
68000; DSP96002; Freescale (Motorola) MVME1603, MVME1604;
AN/UYK-43; AN/UYK-44; AN/AYK-14; Harris NH6202; 68030;
Integrated Device Technology IDT7RS301 R3000/R3010;
MIL-STD-1750A (these are still being made by the way);
68882; Tadpole Technology plc TP860M;
ICL Series 39 Level 80 & Series 39 SX Processor;
Encore 91 Series; Heurikon Malibu (R3081);
IBM 937x, 43xx, 308x 8090, & ES/9000 processors;
Intel iPSC/860; RISCAE Honeywell RH32; Intel i80960MC;
Intel i960MX; R3200-6; 68020; Intel 80860; NEC MV4000;
PSS Zoran ZR34325 Digital Signal Processor AdaRAID;
MAXION Multiprocessor System, Model 9200; Phillips PG2100;
CAPS/AAMP2, CAPS/AAMP3, & CAPS/AAMP5; SKYstation 8117-P;
SKYbolt Model 8146-V; ATLAS ELEKTRONIK GmbH MPR 2300;
i960MX; 1750B; Analog Devices, ADSP-2106x; Intel EXV80960MC;
Texas Instruments TMS320C30; Fairchild F9450 on an SBC-50 board;
Tronix PI960MX-JXV Board (80960MX); Cyclone CVME962 Board (80960MC);
Intel 80960KB; Texas Instruments TMS320C40;
Integrated Device Technology IDT7RS301 System; the
F-16 Modular Mission Computer (though I doubt you will target
that!); TMS320C31; Freescale (Motorola) 68881; 68010;
INMOS T425 transputer on a B403 TRAM; INMOS T800 transputer on a B405 TRAM;
CETIA Power Engine (VGPW2/VMTR2); DY 4 Systems SVME-122;
INMOS T800 transputer implemented on a B417 TRAM; Cyclone CVME 48;
Force CPU 21, CPU 29, CPU 30, CPU 31, Ironics IV9001 board (AMD
29000); Heurikon HKMIPS/V3500; LSI Logic LR33000/LR33050; Motorola
68302, Philips-Signetics 68070, & Toshiba 68301 single-board
computers; DY 4 Systems SVME-144; and ForceCPU-40 Series/Eagle I.

More Ada compilers exist too: e.g. Irvine Compiler Corporation (
WWW.Irvine.com ) targets Texas Instruments the C62xx/C64xx/C67xx
platforms of DSPs.

Re: Embedded

[Lanarcam]

Colin Paul Gloster wrote:
> A partial Ada implementation for 8 bit Atmel AVR processors without
...
> More Ada compilers exist too: e.g. Irvine Compiler Corporation (
> WWW.Irvine.com ) targets Texas Instruments the C62xx/C64xx/C67xx
> platforms of DSPs.

Thank you all for your answers and particularly Colin Paul Gloster
for the detailed response, most helpful.