dont use function calls in the ISRyou cant use anything that uses interrupts inside the ISR, including importantly, timing functons like millis()
occasional lost interrupts (lost accuracy?)
occasional loss of characters during serial communications
inability to use standard timing mechanisms inside ISRs
inability to use standard comms inside ISRs (makes debugging ISRs much more difficult, may have to resort to flashing LEDs etc)
inaccuracy of timing mechanisms outside ISRs (since the millis() will not be counting while the ISR is running, and will therefore always be running slow, by an undetermined amount)
loss of structure (avoiding function calls), and/or redundant coding (replacing function calls) for fear of using function calls inside the ISR
You can't stop the AVR chip from switching off interrupts before calling an ISR, but you CAN switch them back on again as soon as you're in the ISR (simply make sei(); the first instruction of your ISR.)
In fact you can see that it is the very act of inhibiting further interrupts that is making the writing of ISRs seem difficult - by keeping interrupts enabled, most of the problems evaporate.
There is therefore no guarantee that the ISR will have finished servicing one interrupt before the next interrupt of the same type occurs.
Flashing LEDs are perfectly acceptable
Quote from: kenny_devon on Sep 22, 2012, 03:28 amIn fact you can see that it is the very act of inhibiting further interrupts that is making the writing of ISRs seem difficult - by keeping interrupts enabled, most of the problems evaporate. I'm curious to know what this opinion is based on. Have you done any interrupt-based programming? It's not obvious from your post.
One might ask why the Atmel AVR folks designed the hardware to automatically disable interrupts upon first entering a ISR routine as the default behavior, if it was almost always the best practice to do otherwise?