Re: [avr-gcc-list] Extremly confusing behaviour... (more detailedexplanation of error, believe me its not a volatile thing)

[David Brown]

Without having compiled the code myself to look at the assembly, I would say
it looks like there is either a compiler bug in the 32-bit comparison code,
or the srf() call is returning a value with 2 in the lowest byte, and
something other than all zeros in the other bytes (whether that is due to a
bug in the compiler or a bug in the srf() code I cannot say - but it is
worth looking into!).

However, I would also say that you should have declared retval to be a byte
variable - assigning the 32-bit result of the srf() call to the byte will
give you the lowest byte.  The AVR is an 8-bit processor - it is much more
efficient (code space and run time) to use byte-sized variables whenever
possible.  It's not just a matter of optomisation - it's also a matter of
simplication, both for the generated code, and for debugging.

David



> Ok, here is what I have found out.  And so I do not confuse anyone, I
> will only paste the actual code that is broken...
>
> Here is the snippet of code I have been having problems with:
>
> do
> {
> delay = 1000;
> while (delay--);
> PORTA |= _BV (PA1);
> retval = srf08_read(1, 0, pingdata, 2);
> PORTA &= ~(_BV(PA1));
> PORTB = retval;
> //printf("%ld ", retval);
> } while (retval != 2);
>
> retval is declared as an int32_t at the top of main, where this snippet
> of code resides.  Its declared as an int32, because srf08_read() returns
> the number of bytes read as an int32 (was not sure if ssize_t was
> declared for AVR, and I was not sure what size it was). The variable
> pingdata is declared as uint8_t pingdata[2]; and is only used as dummy
> storage in this snippet of code, because all I care about is whether or
> not the srf08 sonar module acknowledged the transfer or not (signaled in
> the return value of srf08_ping() as -1 for transfer error, or the number
> of bytes transferred if success).  Oh, and of course, delay is a
> volatile, otherwise the while(delay--); would be optimized away as dead
> code.
>
> The above code does not work as written, and as you can see I put some
> code in to aid in testing.  The PORTA bit twiddling is there to trigger
> my scope on.  The PORTB assignment is there to let me know what the
> lower 8 bits of retval are set to (it should be 0xFF if there was an
> error, or 0x02 if not, so I only need to watch the lower 2 bits of the
> port to check things out).
>
> If I run the code as it is above, I get 0xFF on port B for a few cycles
> (as expected, the sensor does not return data immediately) then I get a
> constant 0x02 (as the sensor is now ready), and my code stays in the do
> {} while(); loop.  Since I am getting 0x02 on the PORTB pins, I would
> have expected it to exit the loop and go on to the code below, but it
> does not.
>
> Now here is the weird part.  If I change the code to this:
>
> do
> {
> delay = 1000;
> while (delay--);
> PORTA |= _BV (PA1);
> retval = srf08_read(1, 0, pingdata, 2);
> PORTA &= ~(_BV(PA1));
> PORTB = retval;
> //printf("%ld ", retval);
> } while ((int8_t)retval != 2);         <-------------- Change made here
>
> Then the code works perfectly!!!!
>
> So basicly I am asking, does GCC have some sort of bug where comparing
> int32_t's are involved, or am I doing something stupid?  Ill accept
> either answer, as long as you do not just say look at the FAQ.  I want
> to know exactly what I did wrong if I did indeed do something wrong.
>
> The code is simple enough, so hopefully someone can point me to my
> error.
>
>
> Thanks,
> Mike
>
>
>
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden
> http://www.avr1.org/mailman/listinfo/avr-gcc-list