PIC versus AVR

There are no show stoppers for using any of these (PIC,AVR, and MSP430), the one I choose for a particular project is the one has the necessary amount of peripherals in the smallest package size, all things being equal I will choose the MSP430 over a AVR, and the AVR over the PIC.

MSP430 is 16 bits, has the highest performance analog I/O (and not surprisingly is the most expensive and biggest in physical size). I prefer the AVR architecture over the PIC, but the PIC is cheaper and has better availability and more choices.

The application chooses the chip for me, though

That's as it should be, of course. A wise engineer knows the relative merits of many different tools and will choose the one that is the best for the job.

I stay as far away from Windows as I can, so I can't say that I've looked deep enough at AVR Studio to answer your question. But I can say that the Atmel team appears to be trying harder than the Microchip folks at providing development tools. And unlike Microchip its actually practical to code and debug an AVR without Windows.

AVR-gcc is a very good compiler. The packager of WinAVR (avr-gcc for Windows) is now an Atmel employee. See above about "trying harder."

I realize in an academic environment at least one stage of the learning process one stays limited to assembler. Once students get used to assembler it can be enlightening for them to study the output of a C compiler. I looked a lot at the output of avr-gcc. It never wrote assembly that I could improve enough to justify the effort to rewrite in assembly. Once or twice I changed a C expression for better assembly output.

Mmm, maybe. I'm currently evaluating avrgcc (with which I have a lot of experience) against IAR and Rowley (with which I have relatively little experience on AVR targets). There _are_ differences.

Are you forced to install in C:\Program Files, or do you mean, you must have write permissions to the EXE host directory ? ( which is slack of them, if true )

-jg

Hi,

You have the FREESCALE famillies too :

16 bits : =====

The IDE CodeWarrior is free up to 16Ko of C code on 8 bits famillies and 32 Ko of C code on 16 bits famillies.

Yvan

"mc" a écrit dans le message de news: WMxAg.42352$ snipped-for-privacy@bignews8.bellsouth.net...

One big difference:

AVRGCC - single stack, does something odd when making function calls.

IAR, Rowley, ImageCraft - separate call and data stacks to prevent the necessity for the above odd thing.

Regards, Richard.

I have both MPLAB and AVRStudio installed in c:\devtools.

Regards, Richard.

And yet people claim the AVR was designed to be C-friendly. I've looked at AVR code generaged by GCC and IAR. The AVR is not C-friendly. It may not be actively hostile like the 8051 or PIC, but it's not C friendly.

Any processor that falls over when you attempt to do any pointer manipulation isn't C-friendly.

That was explicitly the design intent; it's not a claim, but a published fact.

Note that the explicit design intent of the observation platform atop the Empire State Building was for (dis)embarkation of lighter-than-air aircraft.

This is a private school then, right?

Regards, Richard.

Touché.

I should have been whinging about the claim that the AVR _is_ C-friendly. :)

That sure would have been something worth seeing.

Yes, but state schools are not that dissimilar as this includes administartion and staff systems as well.

That's good; that means they're aware of PC operating systems. If they support two, they'll probably support *both* of them better than if they had only supported one, because every OS opens your eyes to important characteristics of other OSes.

That also sounds like a very good move. gcc of course has a long reputation for high reliability.

Yes... this is how you learn what a compiler does.

The latter. Microchip MPLAB requires you to have write permissions in something under C:\Program Files, presumably its own directory. I don't know what it writes there, or whether different users of the same computer will disrupt each other. In order to use MPLAB we have to loosen security on our computers by letting all users write in that directory.

And I call that inept application programming. Microsoft has been recommending against it for, what, 6 years or more?

Exactly! In ours, the user can make a directory of his own on C: and write in it, but if he does, his files will not roam with him to the next computer he logs in on. If we were more fastidious we'd disallow writing on C: altogether, except for the area containing the user's copied profile.

The thing is, UNIX programmers have known for nearly 30 years that ordinary users aren't supposed to write in directories other than /home/username (or what have you).

Have you raised this with microchip ? - it is by no means a unique problem, and they do need to clean up their act, so point all this out to them. If they realise MPLAB is being _removed_ from educational classes because of simply slack SW design, I'm sure they'll move very fast to remedy it. [ well, they should; if they can't be bothered, then they deserve the consequence ]

Would having the project directory on a FLASH drive be a security risk ? - I see they are getting ever cheaper.

-jg

Yes, I've been corresponding with them about this. I'm also pressing them to make the old 62-character path length limit go away, because it is now very common for paths on a Windows system to be that long or longer (C:\Documents and Settings\blahblah\My Documents\PIC projects\myprog.asm). The limit is actually in the .COD file format, which they don't control. You can work around it by first adding a linker script to your project (so the linker will run, rather than assembling directly to HEX) and then turning off COD file generation. I argue that this should actually be the default, since there are more people who need long paths than people who need COD files.

Actually, that's how we did a lot of our projects last year! Flash drive reliability isn't perfect and I urge people to make hard-disk copies often.

I have used both AVR Studio and MPLAB extensively (On Win2000) and AVR Studio has been consistently significantly more flaky and problematic than MPLAB over many years. AVR Studio's editor still doesn't work properly in debug mode FFS!