On Wed, Jan 14, 2009 at 09:14:20AM -0700, dlc wrote: > > The solution is to NOT call functions from within your ISR. That is > just evil. Get your data in the ISR, put it in a mailbox or buffer > and have a regularly scheduled function handle the details from > outside the ISR. I like to use ring buffers to store data from an > ISR. When using the ring buffer the ISR modifies the "write" pointer, > not the read pointer and the processing function outside the ISR > modifies the read pointer and not the write pointer. This means that > those pointers don't need "push/popped" in the ISR either.
Pointers, or indexes? Don't quite understand the push/popped reference, but if a variable is accessed in both interrupt space and "user" space it needs to be protected so that its uses "atomically". When reading a ring buffer from outside the interrupt one generally compares the head index to the tail index to know if there is data in the buffer. An "atom" in an AVR is 8 bits so if one uses 8 bit indexes then no special care is needed. But if 16 bit pointer that may span multiple 256 byte pages one must block the interrupt before reading the variable that the interrupt might modify. But this is something warranting further study of your specific code. If instructions are used that read the whole 16 bits without possibility of an interrupt between the bytes then no protection is necessary. -- David Kelly N4HHE, dke...@hiwaay.net ======================================================================== Whom computers would destroy, they must first drive mad. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list