Which One The Best Compiler For AVR

Go To Last Post
51 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear All,

1.IAR AVR C Compiler
2.ImageCraft C Compiler
3.CodeVision C Compiler
4.WinAVR C Compiler

Rgds
Siswanto

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is your best the same as my best?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Is your best the same as my best?

I think so'
Please forgeted about the price,
because if the reason is the price,
WinAVR will be winner.
we talk about capability of the compiler it self.

Regards
Siswanto

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you will need to read all the comparisons that have been done in the past and compare these to your needs.

LOCK THREAD

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bascom :)

hey, it's great for RAD...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh no, not this again for the ten gazillionth time!

Did you thread search not find 5,000 previous threads on the subject.

The conclusion is ALWAYS "the one *I* use is the best".

(But there's about 10,000 different "I"s who contribute to this board).

I would bang on about why the one I use is the "best" but you are about to get that 50 times over anyway - so I won't.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The conclusion is ALWAYS "the one *I* use is the best".

yes it is always the comiler that i use. Even if i didn't use any other compiler and know nothing about them, i'll go in a fight with anyone that says that there is a better compiler. such questions shouldn't be asked, you will get opinions not solid technical result.

Such threads attempt ppl to reply alot, even if they don't agree with having that thread. Everyone replies to say no i won't reply :shock:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would be nice to find someone relatively unbiased who would
be willing to compile a list of pros and cons of each individual
compiler, some least common denominator that everybody can live
with (even though probably nobody is going to 100 % agree).

That article/thread could then be made "sticky" by the moderators.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Agreed with Jörg

Why not have a seprate forum just devoted for these

Quote:
THE BEST OF
===========
Compilers (all flavour)
Programmers (Printer, Serial, USB, later wireless)
Methodology (The shortest or longest code)
Optimization (If there is a need for fastest or slowest code)

It is only a suggestion.

Ken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At least a comparison chart of 'features'... the commercial compilers seem to get support for new AVRs out quick... maybe there's an incentive to respond to the market quickly... sell more compilers... but there are a few less often used features that appear in some compilers but not others... 64 bit integers? double floats? embedded c++? c99 features?. If you need that, you need to get the compiler that has it. Its harder to assign a score for support, generated code size, generated code speed, user interface, ease of install, etc.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do agree that IAR is the best, of course their compiler is the most expensive by far. One of the best things about IAR is that they use the same interface with all MCU platforms, so it is pretty easy to do AVR one day and then ARM the next day. My biggest gripe about IAR and other C tools for AVR is that they do not have native support for alot of onboard peripherials like timers, ADC, etc... you have to set them up via registers.

The last time I used WINAVR was 2 years ago and it was pretty buggy. Opensource stuff is great because it is free but you can never depend on it 100% to get you where you need to go. Now that avrstudio has native support for WINAVR, I would put WINAVR in 2nd place.

My favorite C compiler of all time was the one that Microchip gave away for free for the PIC18 platform. It was designed by Microchip themselves, was simple yet powerful, and had great support for onboard peripherials. There really is nothing like a compiler made and supported by the MCU manifacturer itself, it just feels so much more complete and sturdy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, can't help myself...

toalan,

You say IAR is "best" but then it doesn't have native support for peripherals, whereas Codevision does have a code builder for AVR peripherals - so how is IAR "best" in that case?

You also say your only experience of WinAVR is a 2 year old "buggy" version but then you put it in 2nd place - how does that work then? How can you recommend a compiler if the last time you actually used it it was problematic for you?

One man's "best" is another man's gravy (or however it is that saying goes?) - this is why the whole thread is pointless.

I know, why don't we all say which model of AVR is the "best" instead?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, so lets take this opportunity to put together a document called "Why isn't any C AVR compiler best?" and make it a "sticky" to refer to when the next one comes along. Here's my first scetch:

Please don't ask "Which compiler is the best?"

We can not give you any meaningful answer. The only thing that will come out of it is a more or less illuminated debate where the one thing that everyone agrees on is that everyone else is wrong. This phenomenon is called "the compiler wars".

Why there is no answer to the question "Which AVR C compiler is the best?"

1. You have to start by defining "best". What aspect are you wanting the compiler to be best in? Running fast? Producing fast code? Producing small code? Having syntactic constructs for AVR/embedded work (ie. must you have things like PORTB.3 = 1; rather than PORTB |= 1<<3;)? What about support for different AVR parts (ie. memory challenged Tinys, very new devices, devices with "huge" flash)?

2. Are we talking about the compiler proper, or are we talking about an IDE solution? Are you confident in setting up build instructions, such as makefiles, yourself or do you want a IDE with wizards and such to make your life easier? Do you want/need automatic code generation, so that you don't have to cram every last detail in the data sheet to get an interrupt service routine written or make your timer tick? Are you prepared to abandon your own favourite editor?

3. To make a meaningful comparison of the output of the compiler (the generated code) we must have a realistic application ported to all the different compilers. Testing a ridicolously small application (eg. "blink-a-LED") will not yield meaningful results as startup code and basic run-time-support will take up almost all of the application and this is a one-off cost that would be relatively much smaller for a realistic app. Although the idea has been aired here a couple of times no-one has volunteered to port a realistic app to to the different compilers. (The closest thing that I know of is that the AVR Butterfly demo application has been ported from IAR to avr-gcc, and I suspect that this isn't a "straight port" but rather one with some change in functionality. This still leaves at least two compilers out of the game.)

If you do a thorough search through the forums you might find descriptions of where a specific compiler behaves extremely bad in a certain situation. If this situation is a cruscial poart of your app, or is the only thing that your AVR will do, then don't choose that compiler. You might also find cases where a certain compiler behaves better than the others in a certain situation. If this situation is all your app will be about then, by all means, choose that compiler. None of those cases will tell you much about the quality of the compiler(s) in general, though.

4. Are we talking about price? With respect to what? Your wallet? Or any of the points above? What is your time worth in money (are you prepared to pay money for things that probably will save time, or are you on a null money budget and can invest time instead)?

Just as you won't get any universally true answers to the question "Which car is the best?" you won't get any universally true answers to the question ""Which AVR C compiler is the best?". Jut as with cars, you will get different answers depending on what demands you have, and just as with cars you will get a lot of highly opinious answers by people who are devoted to the compiler they use. (BMWs aren't that great!).

Can't I ask anything about the different compilers?

Yes you can. If you have a question on how the different compilers behave in a specific situation then you might well get good answers. (You'd have to be very specific, though, or the result will only be another round in the compiler wars. Fellow 'freak Lee Teusch keeps an inofficial count which is closing in on round 100 and have never even been close to a winner.)

But I need to select a compiler...

At least three compilers can be gotten for free, or a very mall amont of money. Some of these will have limitations on how large apps they will build and/or how long they will function.
In the end I suspect that you fall more or less in one of the two categories below:

You are a professional embedded systems developer and need to cram out every last byte/cycle of a pecific AVR as you will manufacture in thousands or more. In such a case you should have resources to allocate for an in-house evaluation of the different compilers. Your competitors won't do this for you, and if you are a bussiness that can't do a satisfactory compiler evaluation yourself you will have to do what all bussinesses do - buy one from someone competent enough to do it for you - or just pick one and live with the consequences.

You are a hobbyist aiming to build one or just a few specimen of your app. In such a case you will probably be much more helped by a toolchain that fits your "modus operandi" and your wallet. Download one of the free or very low priced compilers and start out with that one. If you don't like it - switch to another one. Treat it as a learning experience. There's no such thing as a free lunch, even for a hobbyist.

Still don't believe the question can't be answered?
[This shouln't go in the sticky. I'm writing this just for the fun of it, and to lure Lee out of his hole!]
OK, here's a secret that only a few of us know, and I'll let you in on it for free: The avr-gcc compiler (popularly available in the WinAVR package) is by far the best. It has no significant flaws, it runs on multiple platforms and is absolutely free. There is no way you can go wrong with the avr-gcc compiler. I have used it since I started AVR development as a hobbyist, I love it, and what better evidence can there be!? [And I really hope that you spot the irony...]

--Johan [professional software developer for 25 years, AVR hobbyist for 5 years, ducking]

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So we've had votes for Best for Winavr, IAR, GCC... same as it ever was... Toalan... IAR has the same user interface for all supported micros... so does my compiler Imagecraft! (but there is an order of magnitude difference in the price, so maybe there is some other point of comparison?)

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
...to lure Lee out of his hole!...

OK, you got me. I've just been watching and listening.

Quote:
The avr-gcc compiler (popularly available in the WinAVR package) is by far the best.

The value is infinite, where Value is Worth/Cost. The US$0.01 that it is Worth, divided by the Cost of 0, gives the infinite Value.

Quote:
It has no significant flaws,...

Repeating: "I must hold my tongue, I must hold my tongue, ..."

Quote:
There is no way you can go wrong with the avr-gcc compiler. I have used it since I started AVR development ...

Does selecting this "by far the best" compiler lead to job security? [with apologies; well, at least some.]

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Sorry, can't help myself...

toalan,

You say IAR is "best" but then it doesn't have native support for peripherals, whereas Codevision does have a code builder for AVR peripherals - so how is IAR "best" in that case?

You also say your only experience of WinAVR is a 2 year old "buggy" version but then you put it in 2nd place - how does that work then? How can you recommend a compiler if the last time you actually used it it was problematic for you?

One man's "best" is another man's gravy (or however it is that saying goes?) - this is why the whole thread is pointless.

I know, why don't we all say which model of AVR is the "best" instead?

Cliff

I say IAR is the best because that is the compiler I use and I never ever had any issues with it:) I had no idea that codevision had support for peripherials, wow now I want to use the codevision compiler:) I put WINAVR in 2nd place because I would think that most bugs have been worked out and the free factor.

TY for elightening me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

28 minutes, Lee... What kept you? :wink:
And whats the count up to?

Seriously, apart from me having fun in the last section, what do you think? Could we make a collective effort to get something like this written and posted as a sticky? Is it a good idea at all?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WinAVR is best and anyone who disagrees is allied with the Axis of Evil and shall be dealt with accordingly. :D

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I really like Johan's article.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
I really like Johan's article.

Me too. Something like that should be sticky.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since I have tried all of the compilers listed I say
none of them is best, simply since I have found things i like and dislike in every one of them, some thing is tricky in one and easy in the others and vica versa. And thats the bottomline in all replys in this topic if you read carefully.

Therefor I am more interested in telling you what I don't like!!!

Imagecraft I don like because it cant handle large arrays passing the 64KB boundary in a proper manner without extra care in coding

WinAVR i dont like since everything is a workaround to make it work in a splitted memory architecture (splitt data/flash)

IAR I dont like because support suchs in an inverse ratio compared to price and the new versions have some problem with large tables too

Codevision I dont like since debugging is a mess whith all c-sources/files smashed into one large file making it difficult to find the wanted block when using avr studio (I could actually like codevision if they could fix this mess) also it is more strict than strict with ANSI (love it or hate it).

Youst my 2p

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Z,

Interesting views but perhaps biased by your own particular need to program >64KB AVRs. It may be a generalisation but I guess most folks here are programming the smaller ones so the Imagecraft/WinAVR/IAR limitation may not be an issue for the majority of others.

Again "best" comes back to the question of what's best for YOU (but not necessarily others) which is why it's impossible to say which is "best" - only that they are different.

I'm just wondering what's the "best" car in the world now?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Z,
Again "best" comes back to the question of what's best for YOU (but not necessarily others) which is why it's impossible to say which is "best" - only that they are different.
Cliff

Exactly, Cliff. Youst tried to point that out in a simple manner. Some like the mother, others likes the daughter. I know which one i would chooce.

(Speaking aboute daughters and mothers, the great thing with compilers is that you can try before you buy each and every one of them without causing any troubles, try that with the other two...)

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Codevision I dont like since debugging is a mess whith all c-sources/files smashed into one large file making it difficult to find the wanted block when using avr studio (I could actually like codevision if they could fix this mess)

"One man's meat is another man's poison."

Actually, I find this WYSIWYG approach useful and comforting. But I use almost all debugging in my head rather than with an ICE--is that what you mean by "using AVRStudio"? Some of the "mess" occurs with the global optimization for size, with common chunks turned into subroutines. (I'd suspect that ImageCraft "Code Compressor" can end up with a similar situation.) When I do use AVRStudio it is to simulate a routine or algorithm, and then I tend to stay mostly in the C source mode.

Quote:
it is more strict than strict with ANSI

Quite interesting--I always felt that CV's AVR microcontroller extensions are routinely lambasted for >>not<< being standard.

It is a bit interesting to roll the clock back to the late 1990s. [No hard facts here; rememberance & hearsay. But I don't think the gist is too far off.] AVRs made their appearance, with a few chip models in production. Atmel worked with IAR, which added the AVR target to their dev tool suite. Then, as now, it costs some $$$$ to get a seat.

CodeVision appeared from a one-person, one-product company as a lower-cost alternative. It has evolved since then to be about as feature-rich as the other players.

[Here is where others can help out with dates & putting the history in proper order.]

Somewhere a bit later, ImageCraft (still a one-person shop, but with other compiler targets) added an AVR target to their product line at a price point similar to CodeVision. Roughly 10% to 25% of IAR.

Then, the multi-target multi-platform gcc added the AVR target. The lowest cost alternative, it has recently (the last few years) added/combined with supporting features such as avrdude chip programming and integeration with IDEs to become a full dev system.

A year or two ago, Rowley added an AVR target to their product line. The price point is roughly now gcc/WinAVR; CodeVision; ImageCraft; Rowley; IAR.

In my mind those are the major C players. This topic is actually titled "Best Compiler", not "best C compiler". There may be votes for other languages with compiler products that I am not as familiar with, such as BASCOM.

The resulting competition over the last 5 years has given us compiler users the same benefits as the TurboC/Microsoft/Watcom/IBM/Intel C compiler wars for x86 in the 1980s. One comes out with a feature or performance benchmark, the others react and all the products are better.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> [Here is where others can help out with dates &
> putting the history in proper order.]

> Then, the multi-target multi-platform gcc added the AVR target.

I did some research on that topic. Denis Chertykov's original
patch and web pages are still available. Based on the information
present there, the first AVR port of GCC must have appeared by end
of 1999 (November or early December).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at:

http://www.atmel.com/products/AV...

does anyone know anything about the following C compilers:

Dunfield (DDS Micro C - DKAVR)
Ron Kreymborg (SCC AVR)
Claus Kühnel (can't actually see where the compiler is?)
SPJ Systems (C - AVR)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
> [Here is where others can help out with dates &
> putting the history in proper order.]

> Then, the multi-target multi-platform gcc added the AVR target.

I did some research on that topic. Denis Chertykov's original
patch and web pages are still available. Based on the information
present there, the first AVR port of GCC must have appeared by end
of 1999 (November or early December).

However, I will add that AVR GCC was mainly restricted to Linux and FreeBSD for a long time after their introduction in 1999. I know that there was at least one Windows distribution of it on AVR Freaks in mid-2002, but it didn't have support for the ATmega128 yet. The WinAVR distribution was introduced in November of 2002.

Eric Weddington

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I say IAR is the best because that is the compiler I use and I never ever had any issues with it:)

TY for elightening me.

WELL

I say my wife is the best woman in the world.
(I've been married once).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As to C standards... how can compilers for Harvard architecture micros be totally "standard" when C and its libraries were conceived before dual-address-space micros were popular (or even existed)?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
As to C standards... how can compilers for Harvard architecture micros be totally "standard" when C and its libraries were conceived before dual-address-space micros were popular (or even existed)?

C was designed to be hardware independent, so it shouldn't matter at all what hardware it is running on.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> how can compilers for Harvard architecture micros be
> totally "standard" when C and its libraries were conceived
> before dual-address-space micros were popular (or even existed)?

C has been doing much of its evolution on the PDP-11, and later
versions of that machine became Harvard in that they divided the
instruction and the data memory space (so they had two 64 KiB segments
per task rather than one -- an ATmega128 with external RAM offers
more!). That's been called "split I&D", I guess if you google for
that you might find a number of pointers.

However, the big difference is that they simply didn't need any copy
operations over from instruction to data memory space. *That's* what
makes our life complicated: our instruction memory space is much
cheaper than our data memory space, so we'd like to switch between
both, and rather keep certain data in our instruction memory space.
That's exactly what original C has not been designed for. (The
"Embedded C" standard technical report addresses multiple memory
spaces, and some other things.)

However, supplying language extensions doesn't automatically make an
implementation (i. e. a compiler + library) non-conforming, and that's
been the meaning of "non-standard" here. Extensions are allowed by
the standard (and some of them, like asm() even listed as commonly
provided extensions). But there's one thing about them: in order to
be recognized as C, they should abide to the C syntax. Thus,
extensions like __flash, several #pragma's, or GCC's __attribute__
declarators don't violate the standard. However, implementing
something like PORTB.4 to access PORTB4 is a different thing: in the C
syntax, a dot followed by a digit can only happen as part of a
floating-point constant. In all other cases, the dot must be followed
by an identifer which cannot start with a digit. Thus, an
implementation that allows PORTB.4 is no longer conformant with the
standard (whatever [in]convenient and [in]logical to the user that
might appear).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
stevech wrote:
As to C standards... how can compilers for Harvard architecture micros be totally "standard" when C and its libraries were conceived before dual-address-space micros were popular (or even existed)?

C was designed to be hardware independent, so it shouldn't matter at all what hardware it is running on.

I beg to differ - the issues with hacks to GCC and the proprietary add-ons in the AVR-specific compilers are mostly to add new storage classes - for pointers to atomic types in flash, string pointers in flash, all vs. those stored in RAM.

I was programming PDP-11s in assembly when I moved to C. My brain one day realized that K&R C is just a portable assembler influences by the PDP-11's, i.e., the auto-increment/decrement.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As an example, the common idiom

while (*cp2++ = *cp1++)
    ;

would compile to something like

L10: movb (r1)+, (r2)+
     bne L10

Truth, goodness and beauty from a generation ago.

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Youst a few answers

theusch wrote:
Quote:
Codevision I dont like since debugging is a mess whith all c-sources/files smashed into one large file making it difficult to find the wanted block when using avr studio (I could actually like codevision if they could fix this mess)

"One man's meat is another man's poison."

Actually, I find this WYSIWYG approach useful and comforting. But I use almost all debugging in my head rather than with an ICE--is that what you mean by "using AVRStudio"? Lee

"Debugging in my head" is something I do as a part of my code check (reading carefully through all written code to find logical flaws). After this process I use studio/jtagICE to verify that everything works as expected on final. While doing this I like to have the files seperated in stead of merged. Thats all.

theusch wrote:

Quote:
it is more strict than strict with ANSI

Quite interesting--I always felt that CV's AVR microcontroller extensions are routinely lambasted for >>not<< being standard.
Lee

I guess I had a bit rush writing that specific thesis, sorry for that, but what I observed during a port from IAR to CV was that CV complained on several things which IAR ignored (correctly). Like for example initializing an automatic variable in a function with a non constant, this was correctly accepted by IAR but statet as an error by CV. ANSI allows this for automatic variables but not for non-auto. var. therefor I wrote "more strict than strict". Sorry for the missleading.

However, i guess this is a bit off topic.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
i guess this is a bit off topic

Not really IMO, given the opened-ended "best" nature of the OP.

(The following is only my views, and may not reflect reality :) )

While CV continues to get closer and closer to standard C, AFAIK it has never claimed to be ANSI/ISO compliant. There are differences in both commision and omission. It was a tool put together some years ago to create a microcontroller C compiler for the few AVR models of the time, and give embedded programmers like myself a C tool to write AVR programs. IMO that is a hair different than re-targeting a standard C compiler for the AVR target.

So a few of the sins of commission: From the start, CV supported the PORTB.4 syntax which has been roundly hammered as non-standard and never will be. In retrospect, perhaps CV would have used PORTB.B4 and then everything would have worked out. But PORTB.4 sure feels comfortable when writing the first '8535 app 6 years ago, my first AVR app, since that was/is the syntax often used in the datasheets and other written material about AVRs.

I don't think that the flash, eeprom, and bit storage classes are totally conforming. There was some syntax swapping a few releases back. But, again, I as the microcontroller programmer that wants to put a value into the flash or EEPROM, or use a register bit as a fast flag, can simply

flash unsigned char prompt["Hello world!");
eeprom unsigned char ee_version = 0x11;
bit flag_complete;

It gave us the tool(s) to do in C what we would have done in ASM to do the microcontroller programming. [That is really the gist of my whole reply: My goal was to write a microcontroller program fast & tight, but using a high-level language.]

I don't believe that the "interrupt [ABC] ..." syntax is conforming. But again, fairly straightforward, and AFAIK each compiler brand is a bit different in this area and portable programs need to have an adjustment header.

A couple of sins of omission:

CV didn't handle complex/nested data well. It is getting much better; I don't know whether it is fully conforming now or not, but it is close. By this I mean nested combinations of arrays/structures/unions. Again this wasn't a problem in my Mega8-class apps; I just didn't need to build these types of complex structures as I did when writing C cross-compilers on a PC, for example. But it could certainly be a problem porting an app with complex structures to a Mega128 app with external memory.

And there is your situation with automatic variables with initializers. This has certainly been a problem in the past. Again, it is getting better. I just write my new code with a separate initialization line and fuggeddaboudit, but it could certainly be a problem when porting code.

I find that I can write tight & fast apps with CV, and it gives me many toos tailored to AVRs. But I program alone, on typical Mega8-sized apps up to Mega32/64. A team working on a bigger-than-Mega16 app, and porting code and sharing libraries and such, may not find the CV model to their liking. If we dig through the Compiler Wars threads you'll find that I can usually come up with a CV solution as tight/fast as the other touted compilers. YMMV; that's why we have these threads. ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll argue that CV at its low price is the best choice for students/hobby and some commercial apps. The tradeoff, IMO is that you shouldn't attempt esoteric coding in C for $3 micros. Indeed, I'll argue that for a humble little 8 bit micro, you should use really simple and obvious C code.

Let's not leave out the merits of the Tiny memory model with 8 bit RAM pointers. CV has this and it saved a lot of flash space for the small chips in my use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> flash unsigned char prompt["Hello world!");

I'm a bit surprised about that approach, as (except for the
"flash" keyword) the standard basically already offers
everything needed for that:

flash unsigned char prompt[] = "Hello world!";

Btw., printable chars should always be "char". That's what
all the str*() functions expect.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Btw., printable chars should always be "char". That's what
all the str*() functions expect.

There is something about old dogs and new tricks, Jorg. Years & years ago, I was burnt doing an app with "weird" characters above 0x7f on the PC character set. Yes, the str*() functions like those types of pointers. But I find I rarely include in my AVR apps. String work is usually for displays (for me), and I find that I end up building the character "images" piecemeal. So I want to work in unsigned and force character comparisons to be unsigned.

I'll probably keep doing it that way. ;) I've never use a signed display character; if it is negative does it show up in inverse video?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

as (except for the
"flash" keyword) the standard basically already offers
everything needed for that:

The use of the "flash" keyword in CV has been refined a bit over the years. For the example shown and most other work it is interchangeable with "const" as you'd probably use it.

I started to switch, but came back to using "flash" and "eeprom" for variables/strings that reside in those memory spaces in my AVR apps, and reserve use of "const" for its other meaning(s). Just the way I've decided to do it for my CV apps as my convention. Style Wars can get even more interesting than Compiler Wars. :)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
... String work is usually for displays (for me), and I find that I end up building the character "images" piecemeal. So I want to work in unsigned and force character comparisons to be unsigned.

I'll probably keep doing it that way. ;) I've never use a signed display character; if it is negative does it show up in inverse video?


Some have used a negative value to mark the end of a string.

We had an application which had to send a lot of strings to a 14-segment
fluorescent display that would have taken way too much memory had we
stored them in the normal way. As the display couldn't show lower
case, we could get away with 96-character ASCII, or rather,
64-character as it was only a one-line display.

We packed three characters to a 16-bit word by shifting between two
32-element character sets like a baudot teletype. Three characters x
five bits/character left the word's sign bit. We used that to mark the
end of the string and eliminated the end of string characters. I wrote
a quick and dirty TECO macro to convert our ASCII source strings to
this double-mutant-32 character set. In the end, we were able to
pack three characters into the space of two with little effort and code.

I believe every piece of software and hardware we used on that project
is extinct. :)

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

Btw., printable chars should always be "char". That's what
all the str*() functions expect.

I never liked K&R's idea that the char type can or should be a signed type. It's OK for 7 bit ASCII where there are never negative values. But a character sensibly is not an arithmetic entity.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
It would be nice to find someone relatively unbiased who would
be willing to compile a list of pros and cons of each individual
compiler, some least common denominator that everybody can live
with...

Something beginning like this? It's a bit dated.

AVR Freaks Articles:
WHICH C-COMPILER SHOULD I CHOOSE?
By ADAM JOHNSON, March 2002
UNOFFICIAL COMPARISON OF AVAILABLE C - COMPILERS FOR THE AVR

Stan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> something beginning like this?

I like Johan's article above *much* more.

> It's a bit dated.

At least the GCC part is completely out of date, and partially has
never been correct at all. (E. g. AVR-GCC never ran under MS-DOS.
Well, maybe, unless you say that Win98 is just MS-DOS and nothing
else.) The example given might have compiled under AVR-GCC during its
infant days, many years ago. It's completely broken these days, and
has been for years, without the author having any apparent interest in
fixing it (even though he obviously updated other parts of the text).

If the information about the other compilers is in similar shape, this
article should not be trusted by anyone. Too bad, there's no option
to link some discussion to that page, so the innocent newbie might be
trapped by it.

Finally, it lacks a serious comparision of at least IAR EW, which has
been a known player under the AVR C compilers straight from the
beginning.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> The use of the "flash" keyword in CV has been refined a bit over the
> years.

Sorry, I've been unclear here. I wasn't referring to the "flash"
keyword itself (though IAR's naming "__flash" is less prone to collide
with the application's name space), but rather to the use of a
completely non-standard initializer construct like:

> flash unsigned char prompt["Hello world!"];

when the fully standard (except for "flash") one:

> flash unsigned char prompt[] = "Hello world!";

would have worked quite fine. Both are supposedly yielding the same,
but if your code is full of the former, you might need an advanced
editor (like one that fully implements regular expressions) to convert
the code to another compiler that doesn't understand that syntax.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but rather to the use of a
completely non-standard initializer construct like:

> flash unsigned char prompt["Hello world!"];

when the fully standard (except for "flash") one:

> flash unsigned char prompt[] = "Hello world!";

Did I really write that first one?!? Yes, I did. I meant the second, of course. I must have been too busy flaming to watch what I was typing. :) And I didn't even balance [ and ).

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
...
Somewhere a bit later, ImageCraft (still a one-person shop, but with other compiler targets) added an AVR target to their product line at a price point similar to CodeVision. Roughly 10% to 25% of IAR.
...
Lee

"Nope" on couple counts: if you check the release logs, ImageCraft AVR compiler was commercially released one month before CV, and of course, ICCAVR was our FOURTH compilers, after ICC11, ICC12 and ICC16. 2nd, we have outgrew a one person company many moons ago.
// richard

Richard Man http://imagecraft.com

Beyond Arduino - When you're ready to get serious...
JumpStart C Tools, The Better Alternative.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Which AVR C compiler is the best?" interms of code size. how much the code size differs between IAR-c and AVR-gcc. for the same application.

I AM USING atTINY2313 FOR MY PROJECT BUT FLASH PROGRAM MEMORY 2K IS NOT SUFFICIENT FOR MY APPLICATION.

I NEED AVR MICROCONTROLLER HAVING 4K FLASH WITH PIN COMPATIBLE TO ATTINY2313.

PLEASE SUGGEST THE HIGHER VERSION OF ATTINY2313 WHICH IS HAVING 4K FLASH. I WOULD LIKE TO KNOW THE COST OF THIS ATTINY2313.

REGARDS,
SRINIVASA REDDY.......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use the device compare fetaures here at avr freaks
https://www.avrfreaks.net/index.p...

There is no pincompatible devices for t2313, but tiny25/45/85 has 2k/4k/8k flash respective, so if you can live with the lower pin count , t45 or t85 will be a better choice. You might get samples from Atmel for free, cheaper than that you wont get it, or find your sales contact from here http://atmel.com/dyn/general/con...

For your compiler question the answer is there is no answer since differenties in performance is highly dependent on application and coding skils. Also, IAR is a High cost variant and gcc is indeed the lowcost.

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Flamewar! Maybe someone could start a thread and add a poll to it, to see which one is more popular. Either way there is no chance that we'll agree on the BEST compiler. It's like asking for the best linux distribution, yummiest ketchup brand, or funniest yoke...

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dagg wrote:

or funniest yoke...

Obviously Ostrich yokes are the biggest, so they must be the funniest too!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sigh!
--
There are 10 kinds of people. Those who can search forums and ready sticky posts before they post useless posts themselves, and those who cant.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.