>> Depends on your 8-bit processor.  GCC supports C++ for AVR.  I don't
>> use it myself, but others do, and it is supported and available.
>>
>> Ciebo used to have a C++ for 8051.  Never heard anything good about
>> it.
>
> Which I think proves my point. GCC for one processor and Ceibo for
> another. The code density of the GCC makes it not very useful compared
> to the commercial C compilers for the AVR.
>

And one of the more popular AVR compilers is the IAR, which has C++
support...


> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> \/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
> /\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

-- 
Best Regards,
Ulf Samuelsson
u...@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB

Dan wrote:

 
> There's very little need for using assembly in embedded programming.
> 
> Dan

Rubbish. There are still very many embedded projects that use a lot of
assembler.

-- 
Ian Bell

Chris Hills wrote:

snip
> 
> The vast majority of embedded systems are 8 bit.

How are you measuring this? By delivered units? (in which case I agree) or
by design starts? (in which case it is probably not true).


> 
> It is VERY useful to know assembly for any embedded target you work on.

Personally I would say it is essential.  IMHO the characteristic that sets
embedded projects apart form all others is the degree of hardware intimacy.
If software guys cannot cross the boundarys some of the way into hardware
and vice versa they are no good for embedded work.

Ian

-- 
Ian Bell

Rob Miller wrote:

> OK, so I think I want to build my own mp3 player.  Is this too big of a
> task for entering into embedded systems?

it is a perfectly good example of an embedded project.

> Which processors/development 
> systems mentioned here would fit my low budget, ease of use criteria?

Depends where you decide to put the hardware/software boundary. You need to
decompose your requirement into functional modules and look at the hardware
& software options for realising each one. Measure them against your
criteria, like development cost, hardware cost, fun to do or whatever and
make your selections.  there is *no* single correct answer.

> 
> I'm thinking PIC since I recently came across this:
> http://www.ladyada.net/make/minty/hardware.html
> 
>>From what I have gathered from all of you, the common, low cost
> processors vendors are :
> PIC
> Hitachi
> Freescale
> Olimex
> 
> If I am wrong about these, let me know.

*The* most common microprocontroller is still the 8051 and its variants.

Ian

-- 
Ian Bell

In article <3...@individual.net>, Ulf Samuelsson <ulf@a-t-m-
e-l.com> writes
>> The vast majority of embedded systems are 8 bit. There are no C++
>> compilers for 8 bit systems (not commercial quality anyway)
>>
>
>So what about the IAR EC++ for the AVR?

of course. My mistake... not withstanding it is EC++ rather than C++.  
( I will borrow one  from Jason to have a look at it.)
 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <d083em$il2$1...@slavica.ukpost.com>, Ian Bell
<r...@yahoo.com> writes
>Chris Hills wrote:
>
>snip
>> 
>> The vast majority of embedded systems are 8 bit.
>
>How are you measuring this? By delivered units? (in which case I agree) or
>by design starts? (in which case it is probably not true).

I can't remember. I have a survey somewhere I will have to dig out. You
will have to trust me on the numbers as it is one of the pay for
industry ones so I can't quote it as a reference. :-)

>> It is VERY useful to know assembly for any embedded target you work on.
>
>Personally I would say it is essential.  IMHO the characteristic that sets
>embedded projects apart form all others is the degree of hardware intimacy.
>If software guys cannot cross the boundarys some of the way into hardware
>and vice versa they are no good for embedded work.
>
>Ian

Agreed. 

So we all agree assembler is essential for embedded systems

The argument is should you use C or C++

For 8 bit (with the few honourable exceptions mentioned previously) the
answer is C


For 16 bit I think it is  evenly split c /C++

C++ really only comes in to the majority  in the 32 bit area.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Ian Bell <r...@yahoo.com> writes:

> > It is VERY useful to know assembly for any embedded target you work on.
> 
> Personally I would say it is essential.  IMHO the characteristic that sets
> embedded projects apart form all others is the degree of hardware intimacy.

In this sense, it's not essential to be an assembler expert.  It's ok
to not know how to structure a string search in assembler efficiently,
or be able to write a division routine.  But the basics of assembly
are essential.

-- 
Darin Johnson
    "Particle Man, Particle Man, doing the things a particle can"

Darin Johnson wrote:
> 
>  But the basics of assembly
> are essential.
>

Just about. I haven't used assembler for about 5 years. But you 
certainly need to get to grips with ONE, just so you know that if 
necessary you can use the others. Personally, I've got about 5 
processors on the go, and just use C for the lot. It's bad enough having 
to learn all the different peripheral architectures.

I expect that by the time I retire, assembly will be largely forgotten 
except by compiler writers.

Paul Burke

On Thu, 3 Mar 2005 17:34:52 +0000, Chris Hills <c...@phaedsys.org>
wrote:

[...languages other than C for 8-bit processors...]
>>
>>Depends on your 8-bit processor.  GCC supports C++ for AVR.  I don't
>>use it myself, but others do, and it is supported and available.
>>
>>Ciebo used to have a C++ for 8051.  Never heard anything good about
>>it.
>
>Which I think proves my point. GCC for one processor and Ceibo for
>another. The code density of the GCC makes it not very useful compared
>to the commercial C compilers for the AVR.

FWIW, avr-gcc code generation compares favorably with the commercial
compiler I have for that platform (avr-gcc code varies between
slightly larger to much smaller).  IAR probably beats it, but the
version of IAR I have is old enough that it doesn't support the
processors I'm using.

>
>>Leaving C++, there is a Modula-2 for 8051.
>
>!!!!!! ?Where did this come from? Mod2 is a procedural language like C

New Zealand.  ;-)  http://www.designtools.co.nz/mod51.htm

It was generating much better code (at least for a pathological
checksum I posted a few years back) than Keil C51 v5.5.  

>but a lot less well supported. It is effectively as dead as Pascal.
>There is more Forth about than Mod2 and Pascal.

A few years back, GM required the use of Modula-GM for safety-critical
software, such as that in antilock braking systems.  They may still,
I'm not sure.  Modula's advantages over C are widely (if not
universally) recognized.

>
>>Hmmm.  Is PLM still around?
>Yes but not supported at all AFAIK. Though I do have one of the last

Which means "no."  I last used PLM-80 on an avionics project back in
1983/84.  I recently read that Boeing built the last of that aircraft
the end of last year.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Paul Burke wrote:

> Darin Johnson wrote:
>> 
>>  But the basics of assembly
>> are essential.
>>
> 
> Just about. I haven't used assembler for about 5 years. But you
> certainly need to get to grips with ONE, just so you know that if
> necessary you can use the others. Personally, I've got about 5
> processors on the go, and just use C for the lot. It's bad enough having
> to learn all the different peripheral architectures.

Hmmmm!, I could certainly get by without an assembler product when I find 
it necessary to include some machine code in an embedded application. My 
first project was 4k of hand compiled machine code (look up op-codes and 
structure of instruction in the databook and enter the code on switches - 
but that was a long time ago). So, the essential ingredient is, in my view, 
a knowledge and appreciation of the processor hardware to the extend that 
you can get intimate with it at the machine code level from the 
databooks/instruction reference card. I have often included little snippets 
of machine code into my Forth based firmware (often need something like 30 
to 40 instructions doing this way to speed things up a bit).
 
> I expect that by the time I retire, assembly will be largely forgotten
> except by compiler writers.

I wouldn't be so sure on that score.

-- 
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>;
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************