Take a look at this code:
One module has:
command result_t CPSSetReceive.setReceive[uint8_t channel](uint32_t id,
uint32_t mask) {
if ((call CANReceive.setReceive[channel](id, mask)) && (call
CANReceive.setReceive[channel + 7](id, mask))) {
...
}
This operation is called with a mas
I'm very skeptical in saying that its a problem with the compiler.
How have you verified that the parameters do not contain the proper
values?
Kevin
On Wed, Feb 27, 2008 at 10:18 AM, José Moyano <[EMAIL PROTECTED]> wrote:
>
>
> Take a look at this code:
>
> One module has:
>
> command result_t CP
If you are checking via he call to Leds.yellowOff(), keep in mind that
if the first call to setReceive[3]() returns FAIL, the if statement
will short circuit and never run the second call, thus never turning
off the yellow LED.
Kevin
On Wed, Feb 27, 2008 at 10:28 AM, Kevin Klues <[EMAIL PROTECTED
;
Para: José Moyano <[EMAIL PROTECTED]>
CC: tinyos-help@millennium.berkeley.edu
Enviado: miércoles 27 de febrero de 2008, 15:33:11
Asunto: Re: [Tinyos-help] AVR GCC compiler problems
If you are checking via he call to Leds.yellowOff(), keep in mind that
if the first call to setReceive[3]() return
> uint16_t number1 = 0x1002;
> uint32_t number2;
>
> number2 = number1 << 14;
This is not a compiler error, but rather an error in your code.
Correct c syntax for doing what you are trying to do is:
number2 = ((uint32_t)number1) << 14;
Now back to your real problem again I'm not inclined
L PROTECTED]>
CC: tinyos-help@millennium.berkeley.edu
Enviado: miércoles 27 de febrero de 2008, 16:10:06
Asunto: Re: [Tinyos-help] AVR GCC compiler problems
> uint16_t number1 = 0x1002;
> uint32_t number2;
>
> number2 = number1 << 14;
This is not a compiler error, but rather an error in your co
> One more thing: Does C support coercion?
Yes C supports coercion, but the problem you have is that you are
really executing two statements in the assignment. Coercion only
happens after the shift has occurred. so first the compiler does
(number1 << 14), then it converts it to a 32 bit number t
On Feb 27, 2008, at 12:11 PM, José Moyano wrote:
Yes, you are right. If so many people is using this compiler, must
be my error. I try hardcoding, and the error continues. Maybe an
optimization problem? I'm using -o0 (no optimization).
That would still be a compiler problem.
One more th
There have been compiler bugs in the past, but as far as I recall they've all
been on msp430-gcc.
The avr-gcc bug database is here:
http://www.nongnu.org/avr-libc/bugs.html
The majority of known bugs are missed optimizations and compiler crashes;
incorrect code generation is relatively unco
t; will be a 16-bit integer.
Janos
From: [EMAIL PROTECTED] on behalf of Kevin Klues
Sent: Wed 2/27/2008 2:27 PM
To: José Moyano
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: [Tinyos-help] AVR GCC compiler problems
> One more thing: Does C support coercion?
Yes C support
Just to amplify on Janos and Kevin's messages a bit when RAM is
corrupted or changing optimization level changes the behavior of a program
the culprit is always one of the following:
- program depends on unspecified behavior e.g.
- order of application of side effects between sequence
Thanks you all for your help. I check the "app.c", and is ok. Later, I load
"main.ihex" with AVR Studio, copy it to notepad, and find the problematic
routine code.
+0A3C: 924FPUSHR4 Push register on stack
[CPSCAN]
+0A3D: 925FPUSHR5
José Moyano <[EMAIL PROTECTED]>
Para: tinyos-help@Millennium.Berkeley.EDU
Enviado: jueves 28 de febrero de 2008, 15:35:43
Asunto: Re: [Tinyos-help] AVR GCC compiler problems
Thanks you all for your help. I check the "app.c", and is ok. Later, I load
"main.ihex" wit
bject: Rv: [Tinyos-help] AVR GCC compiler problems
Below this words, there is the last mail that I sent to tinyos-help. Check the
last two "push" at address 0A4A and 0A4B. The pushed registers,
shouldn't be R18 and R19 instead of R28 and R29? I'm using AT90CAN128, and
T
14 matches
Mail list logo
