Erik wrote:
Errrrr ... Bob, if "result" is in RAM, and so can't be changed by hardware, and interrupts have not been reenabled (we're in an ISR), then how can "result" be volatile?
It's volatile if Bob has declared it volatile. The compiler doesn't know whether Bob is right or wrong to declare it volatile. Bob is right to declare it volatile if, as well as being accessed in this ISR, it is accessed by non-interrupt code. As I've already mentioned, if that is the case, interrupts should be disabled during the non-interrupt code access.
If memory serves me, here "volatile" is nearly as good as beer, for starting a discussion. :-)
Even on the avr-gcc group, discussions about this keyword unearth all manner of misunderstandings. For some reason, posts by people who know what they are talking about are treated with no more authority than posts by people who are guessing or writing from incomplete knowledge or an inappropriate perspective. In other words, it seems that people can't even recognize the right answer when it is given. That's not beer, that's religion.
We have too few maintainers for the avr port, and the rest of us are grateful to them, but not enough to compete for the job of making a good tool "perfect". Oh, and I wonder if there are more little corner cases than we would like to tackle.
In this instance, avr-gcc is working perfectly.
It doesn't do any harm to keep one's assembler skills honed, and the ISRs are usually short enough to be easily done, barring surprises.
Writing in assembler because you don't properly understand the C language is, in my opinion, a very bad reason for taking longer to do the job and opening up a whole new can of worms in the C-to-assembler interface, which you may not properly understand either.
Graham. _______________________________________________ AVR-chat mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-chat
