Re: Moving from 8051 to AVR

David Brown wrote:

Ian Bell wrote:

Here we go again, the tail wagging the dog. A micro 'designed' to use C
is not a recommendation its a good reason not to use it.

Ian

Why do you say that? If you want to complain that C is a badly designed
language, that's fair enough - you'll get plenty of agreement there.

I don't know if C is badly designed - that's not my point. A microcontroller
'designed for C' wrongly encourages people to think that C will produce the
most efficient/effective code on that device which is plainly not true.

But generally speaking, being "designed for C" means the cpu must have
support for accessing data on a stack through some sort of index, and it
should have fast access to data through a pointer or two.

I disagree on two counts. First I do not think that that is all 'designed
for C means, is meant to mean by those saying so and is assumed to mean by
those reading the phrase. At a minimum it is a recipe for a whole host of
erroneous assumptions. Secondly, the 8051 has the characteristics you
mention but noone would say it was 'designed for C'

Where is the
disadvantage in that?

There is no disadvantage in being able to access data on a stack through a
pointer or two. Why not say just that?

Some high level languages could benefit from
other features (Forth would benefit from direct stack operations, Pascal
would benefit from a frame pointer, etc.). Some types of code cannot be
conveniently expressed in C (bit variables, rotation, dsp-type
operations), but being designed for C doesn't mean non-C operations not
supported.

Precisely, and because C does not support those operations, suggesting that
a microcontroller is 'designed for C' is not a plus because it could mean
that the micro does not even support those operations at an assembler
level. In my book that makes it a waste of time as a microcontroller.

And from experience writing assembly code on "C-friendly"
and "non-C-friendly" architectures, I have no doubt that being
C-friendly is a big plus.


Depends on the processor and the application. Here we are specifically
considering 8 microcontrollers where the emphasis is on control. IME non C
friendly microcontrollers make better controllers and are best programmed
in assembler.

The AVR is not actually very C-friendly - it is merely somewhat
IAR-C-friendly (although far better than the 8051). The msp430 is
probably the best example of a C-friendly cpu.

As I said, to me C friendly is not an asset.

Ian
.

Relevant Pages

  • Re: SNMP for dummies
    ... the microcontroller does not support a TCP/IP stack. ... If I were to start over, I would use a different controller. ... OS/scheduler support a TCP/IP stack, then it is likely there are SNMP ...
    (comp.protocols.snmp)
  • Re: uDrive CP/M source code may be available ?
    ... not Roger - that code is in the 4D Systems microcontroller. ... HD card and write the FAT32 support code ones' self - in Z80 assembler ... So if the device itself, like the 4D Systems product, can make life easier by offering a high level interface, a lot of memory space can be saved on a CP/M system for sure. ...
    (comp.os.cpm)
  • Re: 1-32 Khz in 1khz divisions
    ... >>> If you don't want a bunch of jitter, ... A microcontroller is not very appropriate for this, ... >>far too fast to clock the micro of course, at least for a few years. ... and run a 5 bit counter from each of these initial counters, ...
    (sci.electronics.design)
  • Re: Two Ethernet MACs in a new DualCore ARM Microcontroller
    ... I consider a 533 MHz PXA255 to be a microcontroller. ... and is still a micro. ... CAN, SPI, or I2C in order to qualify as a micro controller. ... Nor do I count On Chip Debugging interfaces. ...
    (comp.arch.embedded)
  • Re: Moving from 8051 to AVR
    ... The 8051 was a great microcontroller in its time. ... the tail wagging the dog. ... Would you prefer to use a micro that forces a C compiler ...
    (comp.arch.embedded)