[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] optimization flags causes problems??

From: David Brown
Subject: Re: [avr-gcc-list] optimization flags causes problems??
Date: Thu, 17 Apr 2008 15:25:22 +0200
User-agent: Thunderbird (Windows/20080213)

Ramazan Kerek wrote:
Please see my comment on your questions below.

Best Regards

R. Kerek

What compiler flags did you use?
->  -Wall, -gdwarf-2, -std=gnu99, -O0, -funsigned-char,
-funsigned-bitfields, fpack-struct, -fshort-enums

Try compiling with -mmcu=atmega128. Without an appropriate -mmcu flag, the compiler doesn't know which chip you are targeting, and the <avr/io.h> include file will not get the right definitions for the port registers.

Are you actually including <avr/io.h>, or are you defining DDRA, PORTA, etc., manually yourself? If you are, then you've probably defined them incorrectly (such as forgetting "volatile") - you should *always* use the definitions that come with the compiler/library.

If you compile the code you gave, use -O0 and -Os, what is the generated

assembly code?
-I do not know how and where I can get the generated assembly code. I am
new to this environment.

Add something like flags "-fverbose-asm, -Wa,-ahlsd=${basename address@hidden" to the flag line in your makefile.

Incidentally, why are you writing your own eeprom functions rather than using the ones from the library?
-I am trying not be much dependent on the libraries as possible since I
will be more flexible changing my own code.

Sometimes it is useful to be independent of libraries, but other times it is just a waste of effort. The avr-libc is very good - the code is compact and efficient. You can expect that for the same function (and the same sort of implementation), the library code will be at least as good as anything you write yourself. It will also work across the range of avr devices, unlike your routines. So unless you are thinking of using avr-gcc without avr-libc (theoretically possible), or writing code that must work on different avr compilers, stick to the library functions for this sort of thing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]