"Ulf Samuelsson" <ulf@atmel.nospam.com> wrote in message news:34en7tF4ajp4lU1@individual.net...> > The IAR compiler is generally the one recommended by Atmel Norway, > due to its superior code generation. It has some amazing tricks. > * Global variables in registers. > * Will find identical code pieces and generate subroutines. > There is a free 4 k limited C compiler, but if you want more, > then it will set yuo back a significant amount.Is there a 4k limited version? All I saw on IAR's demo page was that it was 30-day-limited. I haven't downloaded it yet.> On the other hand, I know Richard at Imagecraft is constantly looking to > improve code. > and is planning a free 4 kB compiler himself.Right, I've downloaded that in "release candidate" form (ICC V7 RC4) and there seem to be some problems with the way it installs -- I assume that is just a matter of the way the setup file is constructed. (Sample projects are missing files that ought to be in them, etc.) Also I keep getting the error message "code location 0 already contains a value" from one of the library files during linkage. What does that mean? Wrong version of the library file? Thanks!
AVR compilers
Started by ●January 9, 2005
Reply by ●January 10, 20052005-01-10
Reply by ●January 10, 20052005-01-10
On Sun, 9 Jan 2005 00:38:33 -0500, "mc" <mc_no_spam@uga.edu> wrote:>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 AVRWe 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 <avr\pgmspace.h> ... 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.
Reply by ●January 10, 20052005-01-10
> 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. >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 (www.amtools.net) IDE. With VMLab you can build virtual prototypes and I find it very useful. It automaticly generates makefiles :). And GCC have one of the best support. There is a lot of examples on internet. This one doesn't support JTAG ICE debugging and must be used with AVR Studio software. 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
Reply by ●January 10, 20052005-01-10
On Mon, 10 Jan 2005 08:53:46 +0100, David <david.nospam@westcontrol.removethis.com> wrote:>On Sun, 09 Jan 2005 18:14:39 +0000, Bryan Hackney wrote: > >> Rich Webb wrote: >>> On Sun, 9 Jan 2005 00:38:33 -0500, "mc" <mc_no_spam@uga.edu> wrote: >>> >>> >>>>OK, another deep theological question... >>> >>> >>> Yup. Nothin' like a Sunday to start a religious war. ;-) >>> >>> >>>>What do people think of each of these...? >>>> >> [...] >>> >>>>gcc for AVR >>> >>> >>> GPL, which may or may not be an issue. Active user community. >> >> 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. >> > >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.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
Reply by ●January 10, 20052005-01-10
On 2005-01-10, Rich Webb <bbew.ar@mapson.nozirev.ten> wrote:> Which license is used for the libraries that the AVR gcc port > links with, GLP or the LGPL?It's under GPL with an exception.> (Asking because I genuinely don't > know; I'm a happy ICC-AVR user.)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!!
Reply by ●January 10, 20052005-01-10
> gcc for AVROne 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.
Reply by ●January 10, 20052005-01-10
mc wrote:>>On the other hand, I know Richard at Imagecraft is constantly looking to >>improve code. >>and is planning a free 4 kB compiler himself. >> >> > >Right, I've downloaded that in "release candidate" form (ICC V7 RC4) and >there seem to be some problems with the way it installs -- I assume that is >just a matter of the way the setup file is constructed. (Sample projects >are missing files that ought to be in them, etc.) Also I keep getting the >error message "code location 0 already contains a value" from one of the >library files during linkage. What does that mean? Wrong version of the >library file? > >Thanks! > > >Can you be more specific with the "problem?" Double check the Project->Options->Path to make sure the paths match where you install. I just got the bright idea (ha ha) that I should modify the driver to always look at <install root>\include for headers and <install root>\lib instead of relying just on the settings in those boxes. As for the "code location 0 already contains a value," I thought I fixed that. Anyway, go to Project->Options->Target->Device and you probably have "Custom" set up, which has text address as 0. I thought I changed that to 2 :-) Anyway, location 0 already has the reset vector in the startup code and hence you get that msg. -- // richard http://www.imagecraft.com
Reply by ●January 10, 20052005-01-10
"Richard M." <richard@imagecraft.com> wrote in message news:41E335E9.3030308@imagecraft.com...> Can you be more specific with the "problem?" Double check the > Project->Options->Path to make sure the paths match where you install. I > just got the bright idea (ha ha) that I should modify the driver to always > look at <install root>\include for headers and <install root>\lib instead > of relying just on the settings in those boxes.I corresponded with support today - some of the example projects apparently aren't right. The paths were correct. But I think your bright idea is a good one.> As for the "code location 0 already contains a value," I thought I fixed > that. Anyway, go to Project->Options->Target->Device and you probably have > "Custom" set up, which has text address as 0. I thought I changed that to > 2 :-) Anyway, location 0 already has the reset vector in the startup code > and hence you get that msg.That was exactly it. I thought Application Builder would set the device type in project options; it doesn't. I need to get better at reading this assembly language. It's very nice to be able to see the output of the compiler. Thanks for responding! Michael P.S. How about installing in C:\Program Files? Or do you have components that don't like long filenames? In general, I'm pretty picky about wanting all my application software to follow Windows conventions. So far, I'm pleased to see that you haven't made any of the common big blunders (the most common of which is wanting to write in the install directory at run time; on a secure machine, ordinary users don't have permission to write there). Keep up the good work! -- Michael Covington Associate Director, Artificial Intelligence Center The University of Georgia - www.ai.uga.edu/mc
Reply by ●January 11, 20052005-01-11
Rich Webb wrote:>... snip ...> > 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.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. <http://cbfalconer.home.att.net> USE worldnet address!
Reply by ●January 11, 20052005-01-11
On Mon, 10 Jan 2005 17:18:02 -0800, larwe wrote:>> gcc for AVR > > 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.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.> > 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.
