What I was trying to say was:
ISR(vector){
interruptHandler();
}
interruptHandler() was blindly destroying volatile registers which ISR
should have been preserving since they are the callers responsibility. ISR
was not preserving these registers because it was not aware that these
registers were currently in use. The attitude of the ISR seems to be that
the problem registers should have been stored before the ISR was triggered.
The problem registers are used to carry arguments and return values between
function calls and the ISR can be triggered at ANY time, so any chance of
avoiding this problem is impossible
A solution to the problem would have been:
ISR(vector){
asm("push r18");
.....
asm("push r31");
interruptHandler();
asm("pop r31");
.....
asm("pop r18");
}
or like you said, constrain the ISR to the ISR() macro. But this reduces
abstraction and the ability to test the code.
In my opinion, the best algorithm for an interrupt would be:
ISR(vector){
data=getData();
processData(data)
}
then unit testing can be carried out on processData() and getData() leaving
little testing required for the interrupt itself
--
View this message in context:
http://old.nabble.com/assembly-c-mix-and-interrupts-tp26421328p26570023.html
Sent from the AVR - gcc mailing list archive at Nabble.com.
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
