Instant Interrupts - Revisited

[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.

[Ioannis]

I am not DT, but for sure it is not recommended in any way to do a call inside the int routine. Think of the delays to go forth and back plus whatever you are going to do inside the sub. Can you make it absolutely sure that the call will be a zap?

I am sure there is another wayto implement your project.

Ioannis

[Darrel Taylor]

I agree with Ioannis.
It's not really recommended, but it is possible.

The worst case scenario is with a 16F PIC.
They only have 8 stack levels, and some of PBP's commands can use 4 of them. Which is why you can only nest gosubs 4 levels deep in any 16F program.

In your main program, it may already be 3-4 levels deep when an interrupt triggers. If you then ReEnter PBP, do a GOSUB and try to run a 4-level PBP command, the stack will definitely overflow.

Using the Software Stack can eliminate that problem.

With an 18F there are several more stack levels, so it's not as much of a problem. And of course, if you write the handlers and subroutines in ASM, it's even less of a problem.
<br>

[sayzer]

Thanks IO.
I already knew about delay issues but it takes approx. 30 seconds for my code to complete int routine. So my code is not time sensitive.

What I needed to know was DT's warnings about deep levels.

Thanks DT, that is what I now need to consider.

---------------------