c compiler for atmega?

How do you define stable? I know of the IAR, ImageCraft, CodeVision, and WinAVR (gcc port). They all differ by price, code quality, vendor support, ...

--
Rich Webb   Norfolk, VA

I'm using GCC 3.2.1 - no problems whatsoever.

Tauno Voipio tauno voipio @ iki fi

"Rich Webb" schreef in bericht news: snipped-for-privacy@4ax.com...

Perhaps I should ask 'most popular'. Price is not my first concern, but I like a compiler that behaves (ANSI) as it should and delivers code I can trust. I don't need vendor support, given a reasonable compiler.

--
Thanks,
Frank Bemelman
(remove 'x' & .invalid when sending email)

The IAR compiler is the best for code generation, and Image craft is within

5-10% of that. I believe GCC is not so good for code generation,but I never tried it. Others might have done a comparision.

IAR does releases a few times per year, Imagecraft can give you a fix fairly quick if there is a bug. I do not know how Imagecraft tests, but IAR says it takes 2-3 weeks just to verify a new release. GCC is free, but there may be issues with not getting all info in the debugger. A lot of people is happy with all three.

A lot of people have ideas on how a user interface should work. Your best bet is to get a demo, and try out.

--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

I've played with demos of CodeVision and ImageCraft. Both seem OK and are well thought of by their users. I don't have any hesitation in using either. As with any 8 bit micro compiler, complete ANSI compliance is not something you can expect or would neccesarily want (with a microcontroller like the AVR you need a few extensions to efficiently use the memory space and I/O features).

I'd really like to see a side by side comparison of all of these over a number of applications wrt speed and code size. One day I may be forced to do it myself if nobody beats me to it (I really hope they do, though).

Cheers.

-- Alf Katz snipped-for-privacy@remove.the.obvious.ieee.org

--
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.524 / Virus Database: 321 - Release Date: 6/10/2003

[...]

You probably can't make a wrong choice here. The listed compilers are all good.

I currently use both avr-gcc (WinAVR) and CodeVisionAVR. I've heard good things about Imagecraft, and have had good experience with IAR.

CodeVisionAVR is extremely well-supported, and very easy to use. It comes with several useful libraries (e.g., LCD control, DS1820, LM75). If it has a failing, it's that there is no command-line compiler: you have to load a "project" into the IDE and "build" it.

WinAVR also provides a complete development environment, but a more comfortable one for an OF like myself: command-line, make, etc.

Avr-gcc seems to generate smaller code, but the libraries supplied with cvavr are smaller. This is partly due to the fact that (for example) [s]printf in cvavr is configurable, so you can exclude support for floating-point, etc.

I would suggest that whatever you decide, you get avr-gcc and write your code to work with both. That way, when a deficiency crops up with one compiler or the other, you have a backup. It's saved me twice so far, once in each direction.

Regards,

-=Dave

--
Change is inevitable, progress is not.

They are all stable. But, given the existence of the excellent avr-gcc (e.g the WinAVR distribution), I see no reason to pay for some dongled / protected proprietary one.

--

John Devereux

Thanks to all for the answers. Good to know that these compilers are all pretty sound and solid.

--
Thanks,
Frank Bemelman
(remove 'x' & .invalid when sending email)

IAR for AVR is definitely the leader in both size and speed, and also very handy. On the average projects, it creates somewhat 20% better code if compared to GCC. IAR is EC++ compiler rather then C. However it comes with the highest price tag also.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

This has not been my experience. In my application, IAR code wouldn't fit in the target until I turned up optimization all the way up, and then it generated bad code. The latest Gcc worked fine and fit handily with -o1 optimization. This was (essentially) eC++ on a 90S8515, and the application was encrypting and decrypting a datastream using the TEA algorithm.

Also, gcc gives you *very fine* control when you use inline assembler. I was able to double the performance by redoing the inner loop this way. With IAR, I could not figure any way to do assembler except by adding assembler subroutines.

IAR has much nicer environment, with it's GUI IDE, but you really need a JTAG part or an emulator to take full advantage of this.

That would be interesting to get the real code example and compile it with IAR and GCC. IAR does the good job on common subexpressions elimination and cross call. It is very efficient on the modules of relatively big size. Also IAR model is using the different stacks for return and for variables which is better then GCC one stack model. I observed ~20% difference in the code size on the ~16k executable project for ATMega32. The tip about IAR is avoid the use of library functions if the code size and speed are critical. Self-made functions appear to be better.

Agreed.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

My problems centered on a hand-done implementation of the extended tiny encryption algorithm (David Wheeler and Roger Needham). I saw the same issues when I compiled the GPL C implementation of this algorithm, so it is easily repeatable.

I think that IAR and GCC are probably comparable with their common subexpression elimination capabilities. IAR has cross-call optimization (GCC does not), and this can indeed make a big difference, and the IAR stack model is much better suited to the AVR. In my case though, I had fewer, bigger functions, and most of the stack variables were optimized into registers. This is maybe what helped GCC in my case.

IAR does have an integrated environment, but I see the WinAVR people now have their own nascent GDB-based IDE, including JTAG support. This group seems to be sidestepping AVRStudio, which is a real shame. AVRStudio is still a closed proprietary architecture that only supports IAR. This has forced a lot of business over to IAR, and given the history of Atmel and IAR, I guess this is quid pro quo. But this leveraged proprietary position offers up just the type of barrier to entry that Atmel has spent some real money trying to eliminate, in a uC market that is becoming increasingly competitive. Dangerous waters.

I think the IAR policy is to be a kind of Microsoft of the embedded world.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

IAR.

That is not correct, AVR Studio relies on the COFF file format. This has been around since 1986-87 If I remember correctly. The GNU toolchain uses the ELF/DWARF formats. Anything that generates COFF should run. I have debugged AVR BASIC programs using AVR Studio.

Atmel and IAR, I guess this is quid pro quo.

The fact that one Atmel customers payed IAR $2M to improve AVR code generation to be superior to most other things on the market, may also have had some influence.

Atmel has spent some real money opening up AVR Studio as well. The whole purpose of AVR Studio 4 was just that. The result of this effort is not really here, since there is a lot to do, and the documentation of the interfaces are not published (yet) due to low priority.

An obvious example of the opening up, is the part desciption files which can be used by every tool vendor.

IAR does have an advantage that their development site is not that far from two of Atmels main AVR design centres Trondheim,Helsinki).

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB

COFF will give you rudimentary C and assembler support, but it's inferior and won't even come close to supporting C++. If you want to use C++, you

*could* use UBROFF if you are IAR, but the rest of us are stuck with a dead-end 1986 COFF subset.

The AVR is the only real 8-bit microcontroller with an architecture that can support C++. It is the cheapest part that will do this, and it has a *very nice* C++ port from GNU that is getting better and better every day. But if you want to use this, you're on your own with no help from Atmel.

Like I said, I understand why it's this way, but AVRstudio/IAR is a closed proprietary architecture. Integrate elf/dwarf or publish some internal interface to allow the AVRfreaks crowd to do it, and it'll be open. IAR is busily supporting all of your competitors, and some low end 16-bit parts (ARM, H8S, blackfin) are coming right into your market with full-fledged GNU support. You're *crazy* not to do this.

Would you please tell what prevents to use COFF for C++?

Does it apply to the relocatable modules or absolute modules or both?

Tauno Voipio tauno voipio @ iki fi

PS. Not that I were supporting IAR here - I dropped their tools in favour of GNU tools a couple of years ago.

TV

To get best performance out of your compiler, you should compile your code on maximum optimization and then reduce the optimization level for those cases generating "bad code". You can reduce the optimization on individual files, functions, or sections of code.

I would also be interested in seeing some actual code.

Worth noting is that if you are writing plain ANSI/ISO code (without any memory attributes or other hints to the compiler) it's very hard for _any_ compiler to be *really* efficient. Once you add hints as to where variables and functions should be placed, you improve the code significantly (both regarding space and speed).

That entirely depends on which library functions you are using. For example, the strXXX() functions are usually small and fast, while printf() and scanf() functions usually should be tuned to your specific needs, or avoided if you really don't need all the functionality.

Yes, the inline assembler is lacking in functionality.

I would, however, be very interested in seeing the loop where you doubled performance by writing it in inline assembler.

Best wishes, Mats Kindahl, Senior Development Engineer

--
IAR Systems in Uppsala, Sweden.

Any opinions expressed are my own and not those of my company.

Spam prevention: Contact me at mNaOtSkPiAnM@acm.org or
mNaOtSs.kPindAahMl@iar.se, removing the *NO SPAM* from the address.

application

With

hey Ian,

would you be willing to share your asm TEA implementation. I have been using tea on a AVR but just the compiled C code.

Tried to email you direct but the mail just bounced.

Thanks Ralph

can

*very

if

is

GNU

I am sure that ELF/DWARF is on the "ToDo" list, but the list is pretty long. The priority on the list is driven by general market requirements like this but discussions with key customers can change priorities quickly.

The ELF/DWARF issue is currently competing with things like support for the single wire debug interface introduced in the ATtiny13 and ATtiny2313.

If someone really want EC++, then one option is to pay up. There no money that can get people a Debugwire interface if Atmel does not do it currently.

If Atmel can only do one thing, then it is probably therefore "crazy" to do the ELF/DWARF. Does not make the COFF decision right of course... I'd admit that I also hate it when people are doing the wrong thing....

If everyone pissed of with this limitation, chooses an Atmel AT91 ARM instead, then there is absolutely no reason to do the ELF/DWARF for the AVR ;-)

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB