Re: [avr-gcc-list] Strange issues with 16-bit values

[Brian Neltner]

Hi Bernard,

Thanks for your ideas!

I think that the interrupt handler does exit fine in terms of logic,
because when I downgrade my compiler to 4.2.2, it works fine, so I can
just use the older version until I have more time to deal with it.

I actually have an even stranger issue now. My rand() has stopped
working! I have been successfully using this:

while((newlight=(uint8_t)(rand() % 7))==light);         

for many months to generate a random number different from the previous
random number stored in "light". Now, it generates a random sequence of
seven numbers... and then repeats them forever! always: royal blue,
orange, yellow, red, yellow, blue, yellow, and then back the the
beginning of the sequence!

I downloaded my old hex file off of a working board, and put that on the
new ones, and the old hex file worked fine, and used the same line to
generate the random numbers. And this now happens on both 4.3.0 and
4.2.2! I'm totally at a loss here... I'd blame a watchdog timer, but
I've checked that a dozen times, and the fades are all still smooth --
no halting or glitches from a reset. Gah!

As far as the weird halting goes,

I can imagine the issue being caused by the program being in the
interrupt for toooo long and having stuff from the main loop crawl
forward, but I think that should cause it to just progress very slowly,
not to cause it to halt entirely. The interrupt as I wrote it is, I
believe, guaranteed to spend roughly half of all instructions in the
interrupt, and half of all instructions outside of the interrupt (it
interrupts twice, once staying in the loop to poll with fine timing, and
once to do a single change and exit immediately with a long delay).

I compiled with -Wall and minus a few unused variables there are no
warnings. Although I'm not sure how it could cause the problem, I am
curious why it would be doing 32 bit calculations in the polling. I do
this:

while(TCNT3<(uint16_t)benc_period*224UL/255);

where benc_period is a #define, so it should be cast as a 16-bit
unsigned integer. Do I need to take manual action to tell it to do
16-bit comparison?

Thanks!
-Brian

On Tue, 2008-11-11 at 10:01 +0100, Bernard Fouché wrote:
> I had a quick look... a guess: since the interrupt handler is polling 
> the counter that triggers the interrupt, the mcu may spend its whole 
> time in the interrupt handler. Could you time the interrupt handler? Are 
> you sure that the delay loop is really 'stuck'? I'd rather bet that it 
> crawls because 32 bits calculations in the AVR are much slower than 8 
> bits calculations. If at the same time the main loop gets mcu time only 
> once in a while, that would give the result you get (guessing again!). 
> Also can't you hit overflow situations in the polling code? You perform 
> 32 bits calculations when polling the 16 bits counter, I'm surprised 
> that the compiler does not complain about these. Do you compile with -Wall ?
> 
> Regards,
> 
>     Bernard
> 
> Brian Neltner wrote:
> > Sorry, typo. I was giving example code, not a literal copy of my source.
> >
> >   
> [snip]
-- 
Brian Neltner