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 _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
