> > The solution is to NOT call functions from within your
> > ISR. That is just evil.
Perhaps. And yet, there are occasions when even the reviled "goto" is
useful, and even correct.
"All generalizations fail at some point. Including this one."
> > 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 [to be] "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".
Which is why there is the <util/atomic.h> macros. Check out:
ATOMIC_BLOCK( ATOMIC_RESTORESTATE )
{
... Mangle pointers
}
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
