Interruptus Frustratus

[Jerson]

Steve

     
Checkscore:       'Determine if a button is pressed (count is less than average)        
            If timerave[index] - (timerave[index] /50) > timercount[index] and (delay > 1000) then 
               gosub ServiceHardw 'Signal that a button is pressed. 
            endif

Your call to gosub ServiceHardw is the culprit. It nests other subroutines. This is what may be consuming the time. I can recommend you replace the call to gosub ServiceHardw with a bit variable getting set. You then check the bit variable in your mainline code to decide if you need to serviceHardw. It will definitely yield results.

     Checkscore:       'Determine if a button is pressed (count is less than average)        
            If timerave[index] - (timerave[index] /50) > timercount[index] and (delay > 1000) then 
               ServiceHw=1
            endif

In your main, put this

ServiceHw var  bit        ' declarations section

            If ServiceHw then gosub ServiceHw

Jerson

[Byte_Butcher]

Alain, Darrel, Jerson, thanks very much! You guys are great!

Sooo... if "Disable" & "Enable" don't work with DT_INT, what keeps interrupts from occurring during the interrupt handler? I assume that DT_INT must "protect" it's own handler?

Is there a way for me to disable the interrupts during certain subroutines?
When I get the rest of this put together there will be several places where I need to kill the interrupts to perform time sensitive tasks. Is that possible using DT_INT ?
Do I simply turn the interrupts on and off with the GIE bit when I want to? (INTCON.7 = 0) ?

Darrel, thanks for catching the TMR0 interrupt with no handler. I don't know why I keep doing that. I had to change the Timer resource from TMR2 to TMR0 and I enabled it's interrupt unnecessarily. Thanks! Turning TMR0 interrupt off helped but didn't completely cure the problem.

Jerson, please print yourself a pretty gold star and pin it to your shirt for the day!
The call to gosub "ServiceHardw" was indeed the big culprit. I assume that I just had so much stuff inside my interrupt handler that I ran out of time to do anything else before the next interrupt ?
I set a bit to tell when a button is pressed and check it in my main code as you suggested, and it works MUCH better now!

There's clearly a few bugs still to work out before I start adding the rest of my code back in, but it's looking pretty hopeful now.

Thanks again to all of you. What a great resource!


Steve

[mister_e]

Enable/Disable are for PBP ON INTERRUPT GOTO

For DT-INTS you have
@ INT_ENABLE IntSource
and
@ INT_DISABLE IntSource

You could disable all interrupt by clearing INTCON GIE too. Used with care this could work.

[Byte_Butcher]

Enable/Disable are for PBP ON INTERRUPT GOTO

For DT-INTS you have
@ INT_ENABLE IntSource
and
@ INT_DISABLE IntSource

You could disable all interrupt by clearing INTCON GIE too. Used with care this could work.

AHA! Thanks Steve!

When using @ INT_DISABLE to protect a subroutine, does it also protect nested gosubs, or do I need to disable interrupts in each nested subroutine to protect them all from interrupt?

Thanks!

[mister_e]

It protect what's in between DISABLE and ENABLE, so yes if your Gosub are in between them, they will be "protected" as well.

[Byte_Butcher]

It protect what's in between DISABLE and ENABLE, so yes if your Gosub are in between them, they will be "protected" as well.

Excellent. Thanks!




Steve

[Darrel Taylor]

Woohoo! Go TEAM Go!

And just to add more info ...
When a 16F PIC is servicing an interrupt, no other interrupts can occur until the current one is finished. The GIE bit is cleared automatically by hardware at the start of the interrupt. Global ints are then re-enabled when it executes a RETFIE (return from interrupt) at the end of the handler.

So there's no need to try to keep a handler from being interrupted, because it can't.

With ON INTERRUPT, the actual Hardware INTERRUPT was serviced long before it gets to the handler, so you need to disable/enable with those.

[Jerson]

Alain, Darrel, Jerson, thanks very much! You guys are great!
...snip...
Jerson, please print yourself a pretty gold star and pin it to your shirt for the day!
...snip...
Thanks again to all of you. What a great resource!
Steve

Wow, I am thrilled for that. Thank you. I'm sure many more will learn from your problem as they browse this resource. I myself have used this website to learn from DT, Steve (bow) many times before I began to return the favour. It's my hope that you will be able to soon. :thumbs up: