Sorry, but another interrupt problem

[Yuantu Huang]

You should initialise the INTEDG bit of OPTION_REG. If you would like to make falling edge interrupt, just add OPTION_REG.6 = 0 after INTCON = %10010000

[mister_e]

This is why i suggest my previous. BTW in the first post PB was connected to VCC and OPTION_REG.6 is set to 1 at start-up wich is already rising edge.

[tbirchall]

Thank you very much. That did the trick. It is really great to have such knowledgable people to turn to. Thanks for taking the time.

-Tom

[tbirchall]

OK, I hate to be a pest but... I got the sample code working, but when I apply it to my real code, it only works once. Basically, what I'm trying to achieve is to have the program wake on interrupt, do something, then go back to napping. This is to save power since it is a battery powered project. So, my loop looks like this:

loop:
NAP 0
PAUSE 1

GOSUB blah
GOTO loop

The idea is that all the interrupt does is to clear the flag, then the code will resume at the next line of code - in this case, the PAUSE statement. If I have a simple HIGH/LOW FOR/NEXT loop that lights an LED, it works perfectly over and over again. If I have my gosub (like above), then it works once and that's it - the interrupt never gets called again. Can someone tell me conceptually what is going on? My gosub has one other gosub nested in it, so I don't think it is too deep. Oh, and blah does have a return and my interrupt routine is wrapped in DISABLE and ENABLE calls. Thank you!

-Tom

[Melanie]

Whilst I prefer to use @SLEEP rather than NAP, I did once experience an anomaly (about three years back - probably PBP v2.42) whereby a couple of instructions following the @SLEEP were not executed properly. I cured the problem (without investigating further due to lack of time) by inserting half a dozen @NOP statements before I resumed with any proper code... the reasoning behind that was if it was going to misbehave and skip a couple instructions then the NOP's would absorb the anomaly and contine as it was intended. Anyhow, it worked for me, might be worth trying to see if it does it for you.

[mister_e]

Out of topic by why people say half dozen?
SIX
3 letters, same mean. sorry. couldn't resist

[Ioannis]

Ooh, come on now, don't be a Scrutz!!

Out of topic by why people say half dozen?
SIX
3 letters, same mean. sorry. couldn't resist

Six means exactly six.

But "half a dozen" displays the authors/speakers feeling about the quantity (which I guess in Melanies case was too many instructions).

Ioannis

[Yuantu Huang]

Hi Tom,

The problem might be caused by gosub, which might take too much time, because PBP uses very latency interrupt implementation, and it never jumps into interrupt subroutinue within gosub. Please read Section 9.2 "Interrupt in Basic" in PBP manual. If you use goto instead of gosub, the problem may be fixed. That is,

change

gosub AAA
...

AAA:
...
return

into

goto BBB
CCC:
...

BBB:
...
goto CCC

If the above does not work, you have no choice but using assembly interrupt.

[mister_e]

FALSE, interrupt will jump from anywhere in your code. gosub or goto make absolutely no difference. Latency will be caused by some function BUTTON,SOUND,PAUSE to name only those.

Personnally, for my design, i've never found a REAL BIG difference between regular and assembly interrupt once the code is properly written.

BTW, post a whole code, not only a snip of it, we will help.