Interrupts per second

[emusteve]

Actually, it depends entirely on how long it takes to execute your Interupt Handler code. If you keep triggering interupts before the last one finished, you end up interupting the interupt. Do this too many times and you blow the stack and the thing crashes.

So, the REAL question is: How much time has IFI given us to service an interupt without blowing up their code?

Chow for now,
Steve

[steven114]

I figured that, since the interrupt simply calls a function which increments a variable, I shouldn't have any trouble with that...

[KenWittlief]

Most processors block further interrupts on a pin once the first one has been received

so unless you re-enable interrupts inside the interrupt routine, it will not be able to interrupt the interrupts - usually you enable them in the last instruction before you return, or in some processors, the return-from-interupt instruction itself re-enables them

[emusteve]

True, except you are dealing with two layers of interupts here. The high priority interupt can interupt your low priority interupt. And since we don't know exactly what IFI is doing with their code...

I'm learning a LOT about what doesn't work with this machine.

[steven114]

Originally Posted by KenWittlief

in some processors, the return-from-interupt instruction itself re-enables them

I think RETFIE does this; I seem to remember reading it in the docs...

[Jeff McCune]

Originally Posted by emusteve

Actually, it depends entirely on how long it takes to execute your Interupt Handler code. If you keep triggering interupts before the last one finished, you end up interupting the interupt. Do this too many times and you blow the stack and the thing crashes.

So, the REAL question is: How much time has IFI given us to service an interupt without blowing up their code?

Chow for now,
Steve

Interrupts are disabled while executing an interrupt handler. This is why it's important to keep interrupt routines small, so you don't miss events.