Re: Moving from 8051 to AVR

Ulf Samuelsson wrote:
David Brown wrote:
Ulf Samuelsson wrote:
Regards,

I think you misunderstand how embedded programmers think and work. I
don't spend time and effort manually optimising my C code for 8-bit
systems - I write it sensibly in the first place, because I know the
target architecture well. This applies to working with the AVR just
as much as for other microcontrollers. The AVR is convenient in that
many of the styles rules are generally sensible (like preferring
locals to globals), but not all are general C rules (like preferring
uint_8 to int).

No one is arguing that the 8051 is better suited to C than the AVR.

No the argument is whether it is good that an architecure is better suited
to C or not.


Yes, that was the original argument (and I'd agree that it is good that an architecture is better suited to C than not, as long as it does not detract from other uses) - although it has now been slightly sidetracked by your claim as to *why* it is good, which was that it means any old PC programmer can then write good embedded code for the chip.

But you seem to think the AVR lets any C programmer produced good
embedded code, and that's simply rubbish.

No, I do not think that. I think that it is better to have an architecture
where the hurdle between "IT" style code and embedded code is
as low as possible. Obviously there are limits.


My point is that while the AVR has a lower "hurdle" than, say, the 8051, the difference between the 8051 and the AVR as a C target is very much less than the difference between the AVR and a PC. It's impossible to quantify these things properly, but if we have a scale of 1 to 10, where the PC is 10 and the 8051 is 1, you've been implying in your posts that an AVR is a 9 - in fact, it is more of a 2.

A good C optimiser might be able to hide the inefficiencies of using an
"int" instead of a
"uint_8" for a local variable, but it won't be able to fix the waste
of code and data from using "int" global variables,

There are actually compilers which employ feedback so it is not an
inconceivable optimization.


Unfortunately there is often a big gap between "conceivable" and "practical to implement". It will be interesting, however, to see how some of the heavier optimisations in the up-and-coming gcc 4.1 will handle this sort of thing (since it will be able to view the entire program as a whole).

and it certainly
won't help the PC programmer who malloc's a buffer and fills it using
printf. It won't help the PC programmer who doesn't understand the
difference between flash data and ram data, or who thinks a "volatile
variable" is someone at a party who can no longer stand up straight.

True, there are limits.
It's also worth noting that the AVR is *not* C friendly, and was *not*
designed in conjunction with C compiler experts. It is *IAR-C*
friendly, and was designed with help and advice from *IAR*.

Which of course do not have any knowledge in C compilers.


IAR have plenty of knowledge of C compilers, but they (like all embedded compiler vendors) have their own particular way of handling microcontroller functionality that has no place in standard C, such as handling flash memory spaces. Atmel worked with IAR when designing the AVR, and designed it to be IAR-C friendly. IAR already had compilers that dealt with separate memory spaces, and that could produce reasonable code for 8-bit targets despite C preferring 16-bit (or more), and Atmel took that into account. If they were making a truly C-friendly chip, they would have had a single address space (or at least a way to access both code and data space through a single pointer type). I don't blame IAR for this - they are a business, and have no interest in helping competitors. But certainly in the early days, Atmel had the attitude that the C compiler for AVRs was made by IAR, and they had a total disregard for any alternative compilers or other tools. Again, Atmel are not alone in this - TI had the same attitude with the msp430 (except that they did not design the chip with/for IAR - the msp430 really is C-friendly), and I can understand Atmel's reasons for preferring to work with a single tool vendor. But there are also many reasons to choose not to use IAR compilers, and then AVR loses a little of its convenience for C programming.

So what you have ended up with is an architecture that is a lot better
for embedded C programmers than many other 8-bitters, not quite so
useless of PC C programmers as many other targets, and quite good as a
general 8-bit microcontroller.

Thats a very good summary of my opinion.

.

Relevant Pages

  • Re: C programming on ARM
    ... You can't rely on these things having a consistent pointer size - you should not even rely on the C requirement of a "void *" supporting them all (embedded compilers don't always follow the standards if they conflict with generating good object code for real-world source code). ... Look at the AVR, for example - it has different address spaces for flash and ram data, so the pointers are incompatible. ...
    (comp.arch.embedded)
  • Re: Beginning PICs
    ... Only reason you might would be bad hardware layout or bad hardware design. ... Messing with AVR fuses is trivial. ... Messing with PIC banking is a huge mess. ... The only free C compilers for the PIC are toys. ...
    (comp.arch.embedded)
  • Re: C programming on ARM
    ... But as you say C doesn't map onto these architectures, ... Look at the AVR, for example - it has different address spaces for flash and ram data, so the pointers are ... There are indeed architectures which can't fully support standard C. ... work on standard C compilers. ...
    (comp.arch.embedded)
  • Re: Purchase microcontroller dev. kit
    ... char b; ... Even on compilers which don't support it directly, the way to deal with code like that is clearly explained in user manuals and FAQs. ... The two most sensible families of small microcontroller for beginners or general use are the AVR and the msp430. ... Nothing you write now will be reused significantly in the future, and all embedded code has at least some layers of non-portable code anyway. ...
    (sci.electronics.design)
  • Re: Atmel AVR development tools
    ... AVRs with an ARM eval board (programmed as AVR programmer). ... I've used other "clone" Jtag ices, with the same reliability problems. ...
    (sci.electronics.design)