OK, another deep theological question...
What do people think of each of these...?
CodeVision C for AVR ImageCraft C for AVR IAR C for AVR gcc for AVR BASCOM for AVR
Any of them notoriously good or notoriously bad?
Integration with AVR Studio and STK500 are desirable.
I only have experience with ICCAVR, and I think it's quite a good compiler. Easy to use, fast, cheap, generates reseonable code, a simple IDE, and works well with AVRStudio. The Application Builder that generates initialisation code is very handy.
Jeroen
Yup. Nothin' like a Sunday to start a religious war. ;-)
Insufficient info.
Great value. Excellent technical support. Source-level debugging with AVR Studio (C statements as comments in the assembler output); programs via the STK500. Active user community. Sensible constructs to accommodate the AVR's Harvard architecture into C's point of view.
Expensive.
GPL, which may or may not be an issue. Active user community.
BASIC?
Not really.
-- Rich Webb Norfolk, VA
[...]
The GPL-ness of GCC is not an issue, and never has been. Support, or rather someone to talk to when you get lonely, might be one.
[...]The IAR compiler is generally the one recommended by Atmel Norway, due to its superior code generation. It has some amazing tricks.
-- 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
This is quite reasonable for a beginner. It comes with a lot of libraries to drive all the peripherals and specific other devices which are often used. To read the temperature from a 1Wire DS18B20 and display it on a 2x16 line LDC display will take even a beginner less than an hour. Apparently it is a lot closer to Standard C than it used to be so porting code to one of the more advanced compilers later on should be fairly easy.
Imagecraft if you are on a budget. (They also have a version that supports the RAMless AVRs properly)
IAR If you have a big budget and want to use the officially recommended compiler by Atmel.
gcc if you want a good quality compiler for free, that can run under most Osses used to develop under. If you are using gcc to develop code for other MCUs, then it can have advantages even over the IAR solution.
Same sort of thing as CodeVision, except that it is a sort of basic. Easy to get going with devices it supports, but if you want to use something they do not support, then it is musch more difficult to expand than a C solution would be.
Of course the above is MHO.
Regards Anton Erasmus
It is for some people, either because they don't understand the gcc licensing and mistakenly think it means their own code must be gpl'ed, or because they *do* understand the licensing and know that this provides the user with a guarentee of availability, flexibility, and reliability that can't be achieved any other way.
gcc can produce some excellent optomised code - it benifits from all the same front-end optomisations and extensions as other gcc ports. It is also cross-platform, which is important to some people. The combination of gcc with gdb and a selection of front-ends is flexible and powerful, but it's not everyone's cup of tea. While the support is enthusiastic and helpful (you are talking directly to the authors on the mailing list), avr-gcc is not as friendly out-of-the-box as, say, ImageCraft (though winavr goes some way towards this).
ImageCraft has always been synonymous with good support and ease of use. IAR has (as far as I have heard - I haven't used IAR tools more than very briefly, and never on an avr) a reputation for generating very small and fast code, but I haven't heard "IAR" and "good service and support" in the same sentence. Being Atmel's favourite compiler may give it some advantages for the end user - the AVR is not, as Atmel claims, "C friendly". It was designed and built as "IAR-C friendly", which is not the same thing.
This one is not very efficient compared to Imagecraft and IAR. Code size was too big to get my approval.
Excellent value and efficient compiler. I never had a problem with using it in a commerical product. Integration with AVR studio is good also.
Embedded workbench IDE tools are quite good. But I think the main reason to buy it is if reliability is a top priority. On performance basis, I found it is equivalent to Imagecraft.
Never tried these.
We have both CodeVision and avr-gcc. I write my code to compile under either (It's not as hard as you probably think).
CVAVR makes things extremely easy -- it'll write your initialization code for you, including a skeletal framework with a "put your code here" comment. It includes an IDE with single-button "check syntax" and "build" commands. It includes a chip programmer that's fairly easy to use, and can be invoked automatically upon a successful build, it provides single-button interface to AVRStudio, it provides libraries for common tasks like LCD interface, it even has a built-in terminal for printf-type debugging. And it's cheap.
avr-gcc generates better code (unless you use a lot of library routines -- CVAVR sacrifices C compatibility for smaller libraries), but requires more work -- you need to learn how to use make, what all the cryptic command-line options do, and find the other utilities you need (like a programmer and simulator). But it's free. And it complies better with the C standard. If you're running Windoze, look for WinAVR, it's a complete installable package for avr-gcc including editor, simulator, debugger, chip programmer, example makefile, etc. in a single download. Makes entry that much easier.
CVAVR has some nice features for dealing with the Harvard architecture of the AVR. For example, to have a table of constants stored in flash, the code for CVAVR might look like
flash unsigned char table[] = {3, 2, 1}; ... result = value * table[idx];
The same code in avr-gcc would look something like
#include ... unsigned char table [] PROGMEM = {3, 2, 1}; ... result = value * pgm_read_byte(&table[idx]);
Similarly, CVAVR gives you an EEPROM storage modifier that lets you read and write EEPROM like RAM (at the source level, anyway...)
eeprom unsigned char calibration; ... calibration = calibrate_instrument(); ... result = measure() * calibration;
Avr-gcc give you library routines to acces EEPROM.
HTH,
-=Dave
-- Change is inevitable, progress is not.
My number one is: IAR - great tool, works with asm and with C/EC++ :) And if You have JTAG ICE it's the best choice. You can debug programs with JTAG with C-Spy debbuger included in IDE. Unfortunetly there are no examples for this compiler. You have to try how to make everything without help :( Download trial version from IAR webpage and they give you new trial license without problem when previous had expried. And when you lern C for IAR compiler You can easily switch to other families that IAR supports ARM,51,etc...
I haven't used ImageCraft and CodeVision because they don't have built in debugger for JTAG ICE.
The next tool is GCC for AVR with Visual Micro Lab
BASCOM AVR - extremly simple, lot of examples and good support. I think it have great programming module (I used it instead of AVR ISP before I bought JTAG :) only for programming). Bascom generates larger files than C or assembly. But if you do only prototyping it's ok. There is a large library that contains many useful functions such as 1-wire, I2C, RS, LCD and simulator for them so prototype can be built in minutes !!! without writing libraries on your own.
BTW my friend uses ImageCraft C compiler and AVR Studio for programming with JTAG. He says that he won't change it for anything else :)
Jaroslaw Pawelczyk
I'm with you all the way and I understand that the GPL is not "viral" (as some large software empires might like people to believe) but that's not the only issue.
Which license is used for the libraries that the AVR gcc port links with, GLP or the LGPL? (Asking because I genuinely don't know; I'm a happy ICC-AVR user.)
To paraphrase RMS's explanation of this: using the LGPL ("Lesser" or (older usage) "Library" GPL) permits using the libraries in proprietary programs; using the ordinary GPL for a library makes it available only for free programs.
For many embedded systems the distinction might be moot, regardless of which license is used, as the cost to the customer may be only "for the hardware" but the firmware is "free."
-- Rich Webb Norfolk, VA
It's under GPL with an exception.
You're free to link libgcc into non-free code and distribute the resulting binaries any way you want:
GPL + the runtime exception (from gcc/libgcc2.c):
GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.
In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable.)
--
Grant Edwards grante Yow! Everybody is going
at somewhere!! It's probably
visi.com a garage sale or a disaster
Movie!!
One thing I REALLY REALLY like about this toolchain is that it's possible to put all the steps - compile, link and flash - in your makefile. In particular, it's possible to put the fuse flags in your make file, so you can "make flash" and get a totally blank chip configured correctly. The absence of a method to specify fuses in the main HEX file is a serious limitation of Atmel's upload systems.
You can also do a one-step flash, EEPROM and fuse setup command with a little makefile tinkering. And if you have suitable external command-line utilities, you can do an auto-read of the cal byte(s) and put them into EEPROM.
You can integrate avrgcc with any programming text editor. uisp - the most common companion ISP program - also supports the STK500 comprehensively, as well as numerous other programming interfaces.
Again, you can put a suitable target in your makefile to set the STK500 up to the correct Vcc and clock speed for your application.
It's very easy to use avrgcc, in fact it has to be the most painless gcc variant I've ever built and used. I can't compare it against any other AVR C compilers, but I like it :) And it works properly and flawlessly under Linux, which is vitally important to me.
... snip ...
Correction - a GPLd library can be used in programs for sale, however the program source must be freely available for at most the cost of reproduction. At the same time the author of a GPLd library can always license it under whatever terms he desires, and thus remove any obligations on the part of the user.
Things owned by GNU and available under GPL do not have this option, because GNU chooses not to so license their property.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
It's worth noting that you can do exactly the same with most other compilers. Sometimes there are restrictions (for example, the trial version of ImageCraft and, I believe, IAR, only run from within their IDE), but most tools have command-line versions. When working with ImageCraft's compiler, I have pretty much the same makefile as when using avr-gcc (up to and including using cpp from gcc to generate dependancy information automatically), and do a "make flash" in the same way.
Absolutely - and a good point to bring up.
There are two areas where the licenses are important for the run-time system. There are the gcc libraries (which cover things like the code generated by multiplication operators, or snippets used for interrupt prologue and epilogues - i.e., routines that are generated by the compiler rather than added by the linker), and the C support library (avr-libc). Another poster has already quoted the gcc library license, which is GPL with an exception to use it unrestricted at run-time. The avr-libc is a modified BSD-style license, starting:
The contents of avr-libc are licensed with a Modified BSD License.
All of this is supposed to be Free Software, Open Source, DFSG-free, GPL-compatible, and OK to use in both free and proprietary applications.
This sort of attitude is the difference between "open source" advocates (who would of preference license a library under the LGPL, giving people the freedom to choose their own license for their own code) and "free software" advocates (who would of preference license a library under the GPL, forcing users to make more code free).
It doesn't make much of a difference to users of embedded compilers like avr-gcc - LGPL'ed code can be dynamically linked to non-(L)gpl'ed code but not staticly linked. The idea is that if you sell a closed-source binary which uses an LGPL'ed library, the end user can update their library and still use it with the binary. That makes a lot of sense on big systems (i.e., desktops or bigger), and means binaries can take advantage of security fixes or improvements in libraries. But you may not staticly link LGPL'ed code to non-(L)gpl'ed code without at least providing unlinked object files (or source code) to the end user as well as the binary. This is far from ideal for most embedded systems outside the hobby and accademic arenas, so in general you must avoid LGPL'ed libraries as well as GPL'ed code.
Of course, the above applies only to target libraries (i.e., the bits running on the avr). Host libraries (as used by gcc itself, for example), are an entirely different matter, and most users will either not care about the particulars of the license, or see the GPL or LGPL as an advantage.
You'll think differently if you use GPL'ed code in your embedded software and your competitor, having bought one of your boards, has the legal right to your source code. The GPL is a two-edged sword.
Plus the nice added bonus of being able to specify the programming cable pinout (at least avrdude allows this). I do use the same cable for two types of CPLDs (with a slightly modified Altera JAM player), ARM ISP functions (with armtool) and AVRs (with avrdude). Making arrangements like this with commercial tools is often impossible.
The quality of the code generated by avr-gcc is not always optimal. However, the overhead is rather slight, and the general optimization capabilities of gcc are good. Also, the quality of the code has improved with new versions of gcc.
It would be nice to see comparisons between different compilers with real-life applications. The unfortunate thing is that the source code optimized for compiler A may be pessimized for compiler B, so making such comparisons is difficult.
- Ville
-- Ville Voipio, Dr.Tech., M.Sc. (EE)
... snip ...
However source code should be optimized for readability and maintainability, and optimization left to the code generator. The results should be quite viable for compiler comparisons.
This does not preclude algorithmic improvement.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
[...]
What you have said here is new and foreign to me. It's late, and I can't think, but I wanted to post a big HUH? as a bookmark for later processing.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.