0

Where is a comprehensive and authoritative list of commonly used library or built-in methods (functions) that do not work properly in Arduino interrupt service routines?

I am aware of the following:

  • do not use delay()
  • do not use Serial print methods

which are part of Nick Gammon's advice linked here. His TLDR summary is:

TL;DR :

When writing an Interrupt Service Routine (ISR):

Keep it short
Don't use delay ()
Don't do serial prints
Make variables shared with the main code volatile
Variables shared with main code may need to be
            protected by "critical sections" (see below)
Don't try to turn interrupts off or on

however, I am looking for, as I said, a list that is more comprehensive and authoritative.

  • 1
    An authoritive list (for example by the Arduino foundation) would only be able to include libraries developed by this authority. That wouldn't include most of the available libraries. Nobody wants to garantee for a library, of which he is not an author. – chrisl Dec 27 '18 at 22:43
2

... that do not work properly in Arduino interrupt service routines ...

A much safer approach would be to ask what does work properly in an ISR. Considering that my advice was to "keep it short" that would tend to exclude calling any functions except ones which are known to be OK. For example, calling millis() or micros() to find out the current timer values would be OK (bearing in mind that the figures returned by millis() will not increment).

Anything complex enough to be placed in a library would tend to be excluded simply based on that, in my opinion, unless specifically documented otherwise.

So, I wouldn't try to write files, do serial output, do I2C output, drive motors, etc.

Really, what an ISR should be doing is one or more of:

  • Setting a flag (eg. "key has been pressed")
  • Note the time (eg. "Pulse received at this moment")
  • Retrieve some value (eg. what number is in a timer register)

Then the main code, not in an ISR, does something lengthier with that data.

The other thing to be concerned about is: Is a function re-entrant?

Just as an example, if you are doing strcpy in an ISR, is the strcpy function coded to be re-entered? (I don't know the answer just now). If it is not re-entrant, and you happen to be doing a strcpy in the main code, and the ISR also does a strcpy then one of them will be corrupted.


In terms of getting a comprehensive list, that would be almost impossible. Some libraries are no longer maintained. Others might be maintained but change from one month to the next, and the change might affect how they work inside an ISR. This is like the question people ask about "which libraries use which timers or pins?". These questions are difficult or impossible to adequately answer.

3

The basic rule is quite simple, but the list is practically impossible to produce.

The rule is:

  • You cannot use anything that relies on an interrupt to function from within an interrupt service routine.

AVR chips only have one interrupt priority. Only one interrupt routine can function at a time. If an interrupt fires whilst an ISR is currently executing that interrupt will be delayed until the ISR finishes. If that ISR relies on a function that itself needs an ISR to fire (such as millis(), or serial transmission), then it will never get to finish.

A partial list of things to know:

  • You cannot transmit serial more than there is room in the TX buffer for, or it blocks.
  • The time generated by millis() (which delay() relies on) never changes.
  • Servo motors cannot be controlled and will jitter if an interrupt routine takes too long.
  • tone() generated sounds will also jitter since the ISR is delayed while another ISR is executing

And basically anything else that uses interrupts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.