Maker Pro
Maker Pro

AVR Starter

K

Kremmen

Jan 1, 1970
0
Hi, I'm starting (Migrating from 8051, actually) AVR development and would
like to know how freeware C compilers such as smallC and WinAVR rate. I'll
be doing floating point with code less than 8k in size. Are these tools ok
to use, or should I rather buy IAR's compiler (which will ruin my budget and
social life.. ;)
Regards, Chris
 
R

Richard

Jan 1, 1970
0
Kremmen said:
Hi, I'm starting (Migrating from 8051, actually) AVR
development and would like to know how freeware C
compilers such as smallC and WinAVR rate. I'll be
doing floating point with code less than 8k in size.
Are these tools ok to use, or should I rather buy
IAR's compiler (which will ruin my budget and
social life.. ;)

A couple pointers...

Check with http://www.avrfreaks.net - it's a very active community.

Also, there was a thread on comp.arch.embedded 2-3 weeks ago ranting
about IAR's tools, IIRC. Worth checking.
 
H

Hans Müller

Jan 1, 1970
0
I used the avr-gcc for some projects. It's free creates good code if you
use 8 bit variables were possible. The compiled code was allways fast
enough. Yes, you can also do floting point calculations but you need
some space in rom for it (if I remember right it was about 3k for the
floating point libs).
If you have not the highest speed / code sizes requirements there is no
need for assembly language.

hth
Hans
 
G

Ga Mu

Jan 1, 1970
0
Pawe³ Cern said:
Hi,

It is strongly NOT recommended to use C compilers for such 8-bit MCUs.
Result code is VERY unoptimal (long and slow). I suggest using assembler. C
is good idea for smarter devices such as ARM-based microcontrollers.

Paul

I completely agree with Paul! I've been experimenting with the Motorola
HC908 series for the last year and about six months ago I tried using
one of the free C compilers (SDCC). THE CODE WAS TERRIBLE! It was
incredibly bloated and didn't use the entire CPU instruction set. After
two weeks of evaluation, I went back to assembly language. It's the
only way to go with 8-bit CPUs.

Greg
 
R

Rich Webb

Jan 1, 1970
0
I completely agree with Paul! I've been experimenting with the Motorola
HC908 series for the last year and about six months ago I tried using
one of the free C compilers (SDCC). THE CODE WAS TERRIBLE! It was
incredibly bloated and didn't use the entire CPU instruction set. After
two weeks of evaluation, I went back to assembly language. It's the
only way to go with 8-bit CPUs.

Assembly is hardly the "only way to go with 8-bit CPUs" nor is it
"strongly NOT recommended to use C compilers for such 8-bit MCUs."

[pejoratives redacted]

Compiled code may be larger and slower than well crafted assembly
(emphasis on "well") but it's typically faster to write, more likely
to be correct, and also easier to maintain over the life cycle.

Evaluate the relative strengths of each (or Forth, or Basic, or ...) as
it relates to the task at hand, design resources, time constraints, etc.

For the OP: Think about whether you really need floating point or if you
can use fixed point instead.

You might also want to take a look at the Imagecraft C compiler for the
AVRs, ICC-AVR. It's due to turn over to version 7 any day now (I think
that Richard has just released the final beta). There is a window open
now for new purchasers of version 6 to get a free upgrade to 7. There's
also an active user community. Check out the listserver archives at
http://www.dragonsgate.net/mailman/listinfo or the compiler home page at
http://www.imagecraft.com/software/
 
S

spiro

Jan 1, 1970
0
Hi, I'm starting (Migrating from 8051, actually) AVR development and would
like to know how freeware C compilers such as smallC and WinAVR rate. I'll
be doing floating point with code less than 8k in size. Are these tools ok
to use, or should I rather buy IAR's compiler (which will ruin my budget and
social life.. ;)
Regards, Chris

I think its fair to say C is about 4 - 50 times less efficient than
assembler (usually closer to 4 than 50). But I wouldn't say "don't use
C". The flexibility of C code is fantastic (you can quickly extend, add
debug code etc). If you are lucky enough to have a project that has
alot more processing power than needed, then use C. We use an ATMega as
a secondary processor. Its main purpose is to boot the DSP. After that
it simply listens to the spi bus, decodes a few packets and toggles a
few I/O pins. C is perfect for us.
 
G

Ga Mu

Jan 1, 1970
0
Rich said:
I completely agree with Paul! I've been experimenting with the Motorola
HC908 series for the last year and about six months ago I tried using
one of the free C compilers (SDCC). THE CODE WAS TERRIBLE! It was
incredibly bloated and didn't use the entire CPU instruction set. After
two weeks of evaluation, I went back to assembly language. It's the
only way to go with 8-bit CPUs.


Assembly is hardly the "only way to go with 8-bit CPUs" nor is it
"strongly NOT recommended to use C compilers for such 8-bit MCUs."

[pejoratives redacted]

Compiled code may be larger and slower than well crafted assembly
(emphasis on "well") but it's typically faster to write, more likely
to be correct, and also easier to maintain over the life cycle.

Evaluate the relative strengths of each (or Forth, or Basic, or ...) as
it relates to the task at hand, design resources, time constraints, etc.

For the OP: Think about whether you really need floating point or if you
can use fixed point instead.

You might also want to take a look at the Imagecraft C compiler for the
AVRs, ICC-AVR. It's due to turn over to version 7 any day now (I think
that Richard has just released the final beta). There is a window open
now for new purchasers of version 6 to get a free upgrade to 7. There's
also an active user community. Check out the listserver archives at
http://www.dragonsgate.net/mailman/listinfo or the compiler home page at
http://www.imagecraft.com/software/

Perhaps you should re-read the OP. The question was regarding freeware.

[shameless plug ignored]

Greg
 
R

Rich Webb

Jan 1, 1970
0
[snip...snip...]

Perhaps you should re-read the OP. The question was regarding freeware.

Well, it seems to read "or should I rather buy IAR's compiler" so the OP
is clearly considering both freeware and commercial compilers. As he
didn't evidence knowledge of Imagecraft's product, which fills a niche
between the rather expensive IAR offering and non-commercial products, I
thought he might want to take a look at it.
[shameless plug ignored]

Shameless plug?
 
K

Kasper Pedersen

Jan 1, 1970
0
Kremmen said:
Hi, I'm starting (Migrating from 8051, actually) AVR development and would
like to know how freeware C compilers such as smallC and WinAVR rate. I'll
be doing floating point with code less than 8k in size. Are these tools ok
to use, or should I rather buy IAR's compiler (which will ruin my budget
and
social life.. ;)

My viewpoint is from using WinAVR, IAR, and from evaluating Codevision.

CodeVision(low-cost) vs. WinAVR: Maybe I'm just unlucky or it's my coding
style, but my programs compiled with WinAVR is generally 25% smaller and 60%
faster than with CV.

IAR vs WinAVR: I've done a lot of code with both, and we've tried
transplanting projects from one to the other. Again it's probably coding
style dependant but they're pretty close, though we've seen one beat the
other 10%. And that goes both ways.
IAR's initialization code is on the large side, so we usually strip out
static variable initialization.

Never used SmallC, I understand it'll change from free to low-cost.

Assembler: Lots of people have voted for assembler, and to some degree I
agree. I typically end up rewriting 5% of the code to get to the desired
performance.
For floating point though, where you'll be calling libraries already written
in assembly language, it makes miniscule speed difference.

The comments above are for projects lending themselves to C. Some things are
best done in assembler and I'd never try C for those.
As always, blindly writing C code is likely to get you into code bloat; Look
at the compiler's output and figure out what coding style you should use to
make the compiler generate the tight code you really wanted.

/Kasper
 
E

Ewout

Jan 1, 1970
0
Ga said:
I completely agree with Paul! I've been experimenting with the Motorola
HC908 series for the last year and about six months ago I tried using
one of the free C compilers (SDCC). THE CODE WAS TERRIBLE! It was
incredibly bloated and didn't use the entire CPU instruction set. After
two weeks of evaluation, I went back to assembly language. It's the
only way to go with 8-bit CPUs.

Greg

What a nonsense! Just because you had some bad experience with one
particular compiler doesn't meaan that all free compilers are bad news.

We have been using the Gnu C compiler for the Atmel AVR for two years
now, to produce code for our commercially available system, and it is
excellent. It produces code that is absolutely on par with the IAR
compiler for AVR and sometimes even denser code. Also, we can use it on
our Unix system (FreeBSD) which is so much nicer than having to rely on
a crappy Microsoft platform (have had your daily security patch from
Windows Update for the next 'serious flaw in IE' already ?).

Assembly for 8 bit micros is necessary for certain time-critical
routines. For the rest, C is easier, faster and more manageable in
software engineering teams. Try working on assembly files with 20+
engineers - horrendously difficult.

So, go check out gcc at http://gcc.gnu.org and discover the benefits of
the best free compiler in the world, available for 20+ targets and 30+
host platforms.

Sincerely,

E.J Boks
Kiwanda Embedded Systemen
 
C

Christopher X. Candreva

Jan 1, 1970
0
: Hi, I'm starting (Migrating from 8051, actually) AVR development and would
: like to know how freeware C compilers such as smallC and WinAVR rate. I'll
: be doing floating point with code less than 8k in size. Are these tools ok
: to use, or should I rather buy IAR's compiler (which will ruin my budget and
: social life.. ;)

WinAVR is a packageing of the Gnu GCC compiler. Generally speaking, the code
size / performance penalty of C is more than made up by the code being
easier to write, debug, and maintain.

If your doign floating point, I would say the C libraries are already
optimized such that there shouldn't be a performance hit.

You don't mention your application so it's hard to say if C will be fast
'enough'.
 
T

Terran Melconian

Jan 1, 1970
0
be doing floating point with code less than 8k in size. Are these tools ok
to use, or should I rather buy IAR's compiler (which will ruin my budget and

WinAVR is a fancy-packaged version of GCC for the AVR, which I think is
fine as C compilers go. Using C on an 8-bit microcontroller can be a
pretty painful experience generally, but then again doing floating point
in assembly is also pretty painful, so it's just a question of which
kind of pain you like better.
 
K

Kgf

Jan 1, 1970
0
I have written software for the AVR for five years now, and I would advice
using Atmel Studio 3.56 for this. It is a superb enviroment for development
and debugging. By downloading the latest studio4 and use the assembler
with the 3.56 enviroment you also get conditional assembly. Superb!

Regards Karl
 
S

SFC

Jan 1, 1970
0
Maybe you could answer my question. I'm a beginner with the avr proc and
using avr studio (great tool) but simulating a adc interrupt doesn't seem to
do anything. I set the global int. and the adc int bits, set up the adc reg.
to free running etc. but no interrupt. Haven't tested it on my mega8 so
maybe it's only the tool that's not doing it.

SFC
 
Top