[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-gcc-list] Help, Compiler ignores some part of the function!
From: |
MuRaT KaRaDeNiZ |
Subject: |
RE: [avr-gcc-list] Help, Compiler ignores some part of the function! |
Date: |
Sat, 3 Dec 2005 12:46:35 +0200 |
Hello,
Thanks for the help. As you stated, the compiler was optimizing and
removing that section of the code.
I'll consider your additional comments on coding style & posting.
I'm compiling with -Wall, but no warning appears for the local variable
"controller", that it is not utilized properly.
Regards
Murat Karadeniz
http://www.onlinefavbar.com/mukas
-----Original Message-----
From: Daniel O'Connor [mailto:address@hidden
Sent: Saturday, December 03, 2005 6:15 AM
To: address@hidden
Cc: MuRaT KaRaDeNiZ
Subject: Re: [avr-gcc-list] Help, Compiler ignores some part of the
function!
On Sat, 3 Dec 2005 08:50, MuRaT KaRaDeNiZ wrote:
> Using WinAVR-20050214, I try to compile the following function, but
> the section between [BOOKMARK1] and [BOOKMARK2] does not get compiled
> without any error indication. İ checked the routine in the .lst file,
> this section is not compiled to assembly. The rest is there. What is
> wrong?
It is being optimised away.
The variable 'controller' has no effect because the last line of the
function is commented out.
Also, the formatting is fairly hard to read. A good convention is to
make #defines all upper case so that you can easily distinguish them.
The preprocessor supports #else too, so you should probably do stuff
like..
#ifdef USE_INTERNAL_ENCODER_CONSTS //destinationVertical given in angles
at the final moving axis ErrorVertical = error = ( DestinationVertical /
enc1_constant ) - encoder; #else //destinationVertical given in encoder
ticks at the motor encoder for the same final motion ErrorVertical =
error = DestinationVertical - encoder;
#endif
If you are going to paste code and error messages and your email client
insists on wrapping them, please send them as attachments. That way they
are _much_ easier to read.
Another style issue - if your function takes no arguments you should
declare it like..
void Foo(void)
{
..
}
Some indenting makes things [a lot] easier to read, eg..
if (foo) {
abc;
def;
} else {
bar;
baz;
}
If you wish to comment out a block of code it is safer to use '#if 0' as
you don't get any problems with nested comments.
I'm not sure if you're compiling with -Wall, but that is almost always
a good idea as the compiler will usually tell you when you make mistakes
even if it feels like it's being too picky :)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C