Instant Interrupts - Revisited

[menta]

btw,
If I disable INT (INTCON=0) the LCD shows correctly, but of ocurse interrupts are not working.

[ronjodu]

What I do is turn off interrupts before serial and back on after serial completes. Like this:

sendudp:
        INTCON.7 = 0
        SerOut2 PORTC.6, 84, [$50] 'ask siteplayer to send udp
        INTCON.7 = 1
        udpcount = 0 
        gosub delay
        return

Somewhere in here there is a list of the commands affected by Instant interrupts. I just turn the interrupts off, execute the command and turn the interrupts back on.
I'm not sure if this is the best way to handle things but it's worked well for me so far.
Hope this helps.

[menta]

Well,
What if the interrupts are for the clock ?
Disabling it will cause the clock not to keep going.

[skimask]

Well,
What if the interrupts are for the clock ?
Disabling it will cause the clock not to keep going.

Then add an RTC chip.

[Darrel Taylor]

Hi menta,

Any type of software timed commands like SERIN/OUT, OWIN/OUT, PAUSE, PULSIN/OUT etc, will be disturbed by these types of Interrupts.

That's why there's an ON INTERRUPT GOTO statement. It reverses the situation, so that the PAUSE, SERIN/OUT etc trash the Interrupts instead, which seems more tolerable to people new to PBP, but just drove me crazy. And is why I ended up with DT_INTS.

With Interrupts, you need to use HARDWARE solutions instead of the SOFTWARE timed commands, and in your case the 16F887 has a USART on-board that is NOT affected by interrupts.

So just switch over to HSEROUT, and your problems will vanish.

DT

[menta]

Great, will try this.

[sayzer]

Hi DT,

This question is not related to the current ongoing subject but is about your int routine.

Is it safe (or how safe) to call a subroutine inside your interrupt handler?

Or inside PBP int handler?


Thanks.