Moving from 8051 to AVR

When the code is ready is way too late. In embedded systems most tuning should be done at the design stage. Developing the right algorithms is more important than the choice of programming language. You should code key algorithms to verify performance and estimate total code size during the design process. This is also the stage where you select the target microcontroller.

Ian

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. But you seem to think the AVR lets any C programmer produced good embedded code, and that's simply rubbish. 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, 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.

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*. Now, IAR make some powerful compilers, but like any compilers targeting small microcontrollers, they are not standard C, but have extensions and changes to suit the target. If Atmel had talked to ImageCraft, or to gcc experts, they'd have come up with a noticeably different architecture.

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.

Programming for small micros and programming PC's are different tasks. I can't see why you seem to have such difficulty understanding that. You use different tools, different techniques, and normally different languages - very few people nowadays would consider C to be a sensible choice for general PC programming (mostly only for low-level driver or library code).

No, it would be more sensible to learn what you are working with before wading in blindly. If you want to program microcontrollers, learn to program microcontrollers - not PC's. The target-specific C rules you need to establish are only a small part of the target-specific knowledge

- they are not a big deal to anyone actually experienced in microcontroller programming.

So you train them in the details - or get someone experienced or smart enough to figure them out themselves. That's how you deal with *any* differences between targets, whether it be learning the differences between the timer peripherals or learning the differences between the cores' strengths.

And it seems to me you greatly exaggerate the differences in these "rules" between different embedded targets. In reality, there is not much difference between C programming for different 8-bit micros, and certainly very much less than the difference between programming for an AVR and a PC.

Your local compiler expert will tell you that if you want a small microcontroller with a nice C friendly architecture, you'll drop the AVR like a hot potato and move to the msp430 (having never given the 8051 a second glance).

Your expert will also tell you that having a single address space (which neither the 8051 nor the AVR have) makes far more difference than having plenty of general purpose registers.

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

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.

"int" instead of a

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

True, there are limits.

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

Thats a very good summary of my opinion.

Think I can make that judgment myself. Harvard architecture is adding complexity,both for the programmer and compiler writer. The MSP430 is a nice architecture, but has other drawbacks like limited addressing space.

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.

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.

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).

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.

The addressing space of the msp430 is without doubt a limitation, but I've seldom needed more than 64k space on a small micro anyway. Beyond that, I'd say an ARM, a new AVR32, a Coldfire, or some other 32-bit processor would normally make more sense.

FWIW, the Computer Engineering degree program at my alma mater (MTU, up 'dere in 'da snow country, you betcha) includes at least one class (EE 3173 - Hardware/Software System Integration) that teaches microcontroller programming in 'C.'

Regards, -=Dave

Is it a compulsory course, though? Also "computer engineering" isn't a BSEE...

I'm in the position of being back at school (since my employer has 100% tuition and books reimbursement with no annual limit; I would be insane not to accept the wads of free cash being flung in my direction) so I spent about four months spanning the end of '04 and beginning of '05 trying to pick a school. Pretty depressing reading the curricula. The school I'm at describes their degree program as "electrical and computer engineering" and you get to pick, to a certain degree where in the spectrum you want to operate.

It's fun being back at school - especially since being 300 years old gives me an advantage over the kids there - but it's scary to think of these same kids being handed a sheepskin and believing that they know anything whatsoever about engineering.

My computer science lecturer told me with a straight face a few weeks ago that there is no reason to learn anything about analog electronics because anything you want can be bought in a black-box chip.

One of Don Vonada's Engineering Maxims from early 1970's:

Digital components are made of analog parts.

It's a third-year class on all three of the four-year plans published by the department, so it's as compulsory as, say, Intro to DSP. I suspect if there were extenuating circumstances, you might be able to work with your advisor to assemble a degree schedule without it, though I don't know why you would.

The "Computer Engineering" degree at MTU is administered by the Department of Electrical and Computer Engineering (in the College of Engineering), which also offers a traditional BSEE degree, rather than the department of Computer Science (in the College of Sciences and Arts). Take that as you will. Obviously, some advanced CS courses, such as Operating Systems Theory, are required anyway.

With the BSCE, you aren't required to take some of the more esoteric EE core curriculum (such as Electro-Magnetics), but you do have to take, for example, Advanced Circuits Analysis.

MTU has some pretty close links with industry, and offer an "Enterprise" option, which is sort of like a co-op on steroids. The University forms small "enterprises" staffed entirely by students. The enterprise is run like a business, and is expected to succeed or fail on its own merits. One of the stated goals is that students graduating from the Enterprise program would be able to join a company, or start their own if they so desired. See

Of course, MTU probably wasn't an option for you in any case...

Regards, -=Dave

Aren't TI supposed to have extended the address in the newest cores ? [Tho I don't think they have large flash silicon yet ?]

The AVR started with a small address space, then added the ECALL/ELPM patches, so it is not hard to do ...

The new TI USB Stick MSP430 debugger looks nice - I see they had to use an 80C51 in there too ;)

-jg

Yup. I gave up on C for PC applications many years ago and switched to Python. I still do C for Linux kernel/driver work and for embedded stuff.

It is if you write your embedded stuff in C. And most of us do.

If you write all your code in 8051 assembly language, then the

At my Alma Mater it was a program and degree within the EE department, but the degree does say BS Computer Engineering. We only had to take one quarter of fields, didn't have to take the motor-generator lab, and only about 3/4 of the analog electronics stuff. Instead, we were required to take quite a few Comp Sci clases, and more digital electronics. I think everybody had to take a microprocessor class with a lab (IIRC, we did Pascal on Z80s using an HP64000 development system and in-circuit-emulator).

When it got my masters in CS/EE, I ran into a few CS faculty who knew absolution nothing about electronics and weren't even what I would consider "computer literate" (they didn't know how to usee-mail). However, they could talk for hours on the theoretical ways to do division.

In article , Colin Paul Gloster writes

In theory but not in practice.

Which c standards?

-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ snipped-for-privacy@phaedsys.org

In article , Ulf Samuelsson writes

If it is so bad why do Atmel push the 8051 and continue to develop them?

I know a lot of 8051 programmers who use C who do not need to check the generated code and hack it so it fits.

In article , John Devereux writes

Actually it is almost impossible to do with Gcc.

However for most for the commercial compilers I know it is easy to get EXACTLY the old version you need.