c compiler for atmega?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
A short question...
What is considered as the most stable compiler for Atmega?

--
Thanks,
Frank Bemelman
We've slightly trimmed the long signature. Click to see the full one.
Re: c compiler for atmega?
On Tue, 7 Oct 2003 00:32:58 +0200, "Frank Bemelman"

Quoted text here. Click to load it

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

Re: c compiler for atmega?
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: c compiler for atmega?

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: c compiler for atmega?
On Tue, 7 Oct 2003 10:20:16 +0200, "Frank Bemelman"

[...]
Quoted text here. Click to load it

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.

Re: c compiler for atmega?

Quoted text here. Click to load it

I'm using GCC 3.2.1 - no problems whatsoever.

Tauno Voipio
tauno voipio @ iki fi




Re: c compiler for atmega?

Quoted text here. Click to load it

    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
We've slightly trimmed the long signature. Click to see the full one.
Re: c compiler for atmega?


Quoted text here. Click to load it

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

http://www.abvolt.com

Re: c compiler for atmega?
Quoted text here. Click to load it

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.



Re: c compiler for atmega?


Quoted text here. Click to load it

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.  

Quoted text here. Click to load it

Agreed.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Re: c compiler for atmega?
Quoted text here. Click to load it

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.





Re: c compiler for atmega?


Quoted text here. Click to load it

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

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Re: c compiler for atmega?
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: c compiler for atmega?


Quoted text here. Click to load it

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.




Re: c compiler for atmega?

Quoted text here. Click to load it

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




Re: c compiler for atmega?
Quoted text here. Click to load it

can
*very
Quoted text here. Click to load it
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
We've slightly trimmed the long signature. Click to see the full one.
Re: c compiler for atmega?


Quoted text here. Click to load it
do


Ulf,

 IAR has a good product that stands on its own merits.  In my experience, if
developers are comfortable with GCC then they are going to use GCC no matter
what; if they're not, then the fastest and cheapest way to tool up for the
AVR will be to write a check to IAR.  I don't see any meaningful competition
between the two of them.

But AVRStudio is the software development hub for you flagship uC product.
If you can really only manage to prioritize *one thing* at a time with this
program, then you really ARE crazy..  You'd be better GPL'ing it and
publishing the source.  Then the AVR/GNU crowd would quit whining, Atmel
would get a broader base of support, and IAR's position would really remain
intact.

Regards,



Re: c compiler for atmega?
Quoted text here. Click to load it

this
remain

As I said there is a *big* list of things to do,
I send in new things every week, and I do not belive that protection of IAR
matters here.
Some things gets done, and somethings get on the backburner.

High priority items for AVR studio is AFAI think bug fixes,improving trace
support
code coverage, performance analysis, support of new parts and the new
debugwire emulators.
I do not really know for sure the list, but the guys certainly have plenty
to do.
There are not tons of people

A nice thing which I really would appreciate, is a way to save the fuse
settings
in the ISP popup window. Everyone thinks this is a good idea, but has never
gotten through the eye of the needle.    I'd rather have than the ELF/DWARF,
but then I have both the gcc and the IAR compiler.

Pls Dont forget to read the last row in this email...


--
Best Regards
Ulf at atmel dot com
We've slightly trimmed the long signature. Click to see the full one.
Re: c compiler for atmega?
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it
never
Quoted text here. Click to load it

 The best way to handle this, is to document a standard method for
mapping
this option-Fuse info into the .HEX file.

 That way, it is not single-point SW constrained, and all device
programmer
pathways can access the info.
 It also allows source-code generate/conditional compile control of
option
fuses, and puts all the info into a single file, for best version
control.
 Hex file formats also allow comments, which can further
clarify/document
this.

 Other chip vendors already do this.

-jg

Re: c compiler for atmega?
Quoted text here. Click to load it

This is one reason why it's so bad, because of how old it is!


Quoted text here. Click to load it

Then, if COFF is *so* good, then why does AVR Studio also support
UBROF which is proprietary to IAR? Why has GCC been dropping COFF
support in favour of ELF/DWARF for years?
 
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

I beg to differ.

An obvious example of closing the doors, was that AVR Studio 3 had a
very simple way to call 3rd party compiler, just with writing a
command-line to call.
Now, AVR Studio 4 doesn't have ANY support for calling 3rd party
compilers. There has been reports that it will have it, in the future,
but you'll have to write a DLL (plug-in) to have it call 3rd party
compilers. Why does one need a stupid DLL to call a command-line? And
that feature is supposed to be out "any day".....
 
Quoted text here. Click to load it

In the age of the Internet, location doesn't matter. I've worked with
many Open Source AVR developers to improve the toolset and these other
developers are in:
1. Washington (State), US
2. Colorado, US
3. Pennsylvania, US
4. North Carolina, US
5. Germany
6. Poland
7. Russia
8. Denmark
9. Australia
10. New Zealand
11. Canada
12. England
and many others. Only one have I met in person, and I only know what 2
of these people even look like.

Eric
-------
My views are not that of my employer. Duh!

Site Timeline