Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Message

Re: AVR Compiler: which is the best

2004-03-16 by markevans_1

Thanks for all the replys. 

I have written a handful of programs for AVR and PIC in assembly. I 
find once you start to include LCDs (especially graphical ones) to 
the project the code gets quite large quite quickly. So my main 
reason in looking for a higher level compiler is for managability. 
As for language preference, 

I have significant experience in C/C++, java and a bit of BASIC but 
am not adverse to learning a new latest-and-greatest language. The 
main requirement is that there is a large body of freely available 
existing code for the particular compiler-language so I can drop in 
an I2C class, LCD routines etc and not waste my time writing and 
debugging such code. Also I would like to have the option to port my 
code to other micros if the need arises.

Looking back on a few hundred lines of assembly you coded a couple 
of years ago and untangling it is not much fun: even if it is well 
documented. Furthermore, I find the vast bulk of code I have written 
is related to GUI stuff. Output a string or draw a line to an LCD, 
listen for keypresses etc: which requires a lot of code that can be 
reused from project to project and has little need for highly speed 
optermised code. Whenever speed becomes an issue though, I would 
greatly prefer to code in inline assembly, if for nothing more you 
can easily count clock cycles.

I am still a student doing a Computer Science and Engineering 
Degree. After a 3 year degree of CS you know compilers generate 
assembly but are never taught or shown what it is or what it looks 
like: for that matter you are told not to code in it. As for 
engineering, they do introduce you to it, but there is still a heavy 
focus on using C for low level stuff where ever possible.

I understand the reasoning behind it but I still think programmers 
should have an understanding of what a compiler does and how it does 
it to better understand the implementations of the code they write 
in high level languages.

I will download a couple of demos of the mentioned AVR Compilers and 
see which I prefer.

Mark.




--- In AVR-Chat@yahoogroups.com, "Cobb, Quentin" <quentin_cobb@t...> 
wrote:
> This is bound to be a huge thread, ranging from "Real men program 
in
> assembler" to "BASIC is almost like a real programming language 
these days"
> 
> Your mainstream choices are
> 
> Assembler (AVR Studio)
> BASCOM
> GCC
> Codevision C
> Imagecraft C
> 
> If you want to learn how the chip works then use assembler, but 
from the
> tone of your email I don't think that's what you're after.  AVR 
assembler is
> specific to AVR's and not transferable.
> 
> If you know C then you won't like BASCOM, which is almost like a 
real
> language now, but is still BASIC and suffers from the "it's quick 
and easy
> to get started but slow and hard to get finished" syndrome. 
> 
> From your email you're obviously leaning towards C because you 
know it, so
> you'll want to transfer those skills and your question becomes: 
which C
> compiler?
> 
> GCC - Is for Linux, free software aficionados.  It works, isn't 
pretty,
> takes a bit of work to get all the bits up and running, has the 
stuff the
> commercial products have, but not in a ready-to-go hold-your-hand 
package.  
> 
> Imagecraft.  "Industrial Strength" professional, expensive 
compiler.  I
> can't talk much about it as it's beyond my budget so I haven't 
used it or
> seen it used.
> 
> My personal preference is Codevision.  There is a 
free "evaluation" version
> that is code-size limited, but good enough for all but the really 
big
> projects.  Even if you decide to pay for it, it's still very 
reasonable.
> Much easier to set up than GCC, has nice code generating wizards 
that save a
> bit of manual reading the first time you use a feature. Lots of 
code
> libraries.
> 
> ALL these C compilers meet your criteria, (except Imagecraft isn't 
very
> cheap) 
> 
> Good luck
> 
> Q

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.