I have read many posts about interrupt implementations for an Infrared (IR) receiver.

Not a one seems concerned about the possibility of the IR detector flipping out with continuous spurious interrupts and starving the processor.
Should I be? Should various safeguards be built in to detect these, ie:
interrupts happening too fast, too many in a given time, disable interrupts for a large portion of the gap between messages then re-enable, etc.

 

Meh, I would not be worried, that is one thing the receiver is supposed to be good at. If you start getting many short intervals (and "short" itself somewhat subjective) sure you can shut it down.

I do not know of anyone ever needing to do this, but keeping failure modes in mind has never hurt anyone..

And welcome to the forums!

 

I use a different system.

Instead of using interrupt on pin change I used a timer interrupt that polls the IR sensor signal about three times faster than the shortest pulse width. Basically it then measures each pulse width by the number of ints;
a short pulse is about 3 ints.
a long pulse is about 10 ints.

So if pulse <7 ints it's a 0, >=7 ints is a 1.

Then it was easy enough to decode the 4 bytes of 8 pulses, and check the checksum (they just repeated two bytes inverted) and if all is good the interrupt passes one neat byte back to main, the byte tells which remote key it was (and 0= no key).

 

Thanks for both inputs and the welcoming.
I'm getting back into this field from a long hiatus.
There weren't interweb resources and forums back when I did this before.
Its good to be on board! Its a different world; some things the same
but others very much better. I have a lot to look over here in the long
history of posts which I will grateful for the shared expertise.

Sampling would nicely sidestep the issue and I may choose to do that.

The edge detect is slick (especially for RC5 I think, which I am doing) and
has the potential to be very efficient. Tough choice!

I think all the posts I found were hobby efforts, so it is understandable that they
aren't looking out for commercial quality bullet proofing which might anticipate edge detect interrupts going crazy.

A problem in this are might most likely occur due to a production problem I
guess, perhaps calling for a bit of a power on self test step... which I have not really considered yet.