Sorry, but another interrupt problem

[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

[tbirchall]

OK, I tried adding the 12/2 @NOPs, but it reacted the same. Here is some code:

loop:

nap 0
pause 15

' this works repeatedly just fine
' for index = 0 to 5
' high 7
' pause 250
' low 7
' pause 250
' next

@NOP
@NOP
@NOP
@NOP
@NOP
@NOP

' this works the first button press but never again
gosub callTime

GOTO loop

' my interrupt routine
disable
handleInterrupt:

high 7
pause 250
low 7

INTCON.1 = 0
resume

enable

callTime:

' clear the display
gosub clearDisplay

' show time
gosub displayTime

pause 2000

' clear the display
gosub clearDisplay

return

clearDisplay:

for index = 1 to 2
shiftout LEDData, LEDCLK, MSBFIRST, [index]
shiftout LEDData, LEDCLK, MSBFIRST, [-1]
pulsout LEDLoad, 5
next

for index = 3 to 4
shiftout LEDData, LEDCLK, MSBFIRST, [index]
shiftout LEDData, LEDCLK, MSBFIRST, [%00000000]
pulsout LEDLoad, 5
next

return

displayTime:

' read time from DS1302
GOSUB ReadRTCBurst

' get hours
I = Hours
if (I > 12) then I = (I - 12)
if (I < 8) then
high 0
I = (I - 1)
I = (%01000000 >> I)
shiftout LEDData, LEDCLK, MSBFIRST, [3]
else
low 0
I = (I - 8)
I = (%01000000 >> I)
shiftout LEDData, LEDCLK, MSBFIRST, [4]
endif
shiftout LEDData, LEDCLK, MSBFIRST, [I]
pulsout LEDLoad, 5

' get tens of minutes
I = (Minutes >> 4)
shiftout LEDData, LEDCLK, MSBFIRST, [1]
shiftout LEDData, LEDCLK, MSBFIRST, [I]
pulsout LEDLoad, 5

' get minutes
I = (Minutes & $0F)
shiftout LEDData, LEDCLK, MSBFIRST, [2]
shiftout LEDData, LEDCLK, MSBFIRST, [I]
pulsout LEDLoad, 5

return

---------------------------------
So, did anyone read this far? Sorry for the length. Basically, I'm reading time from a DS1302 and then pumping it out to a MAX7219 LED driver. Part of the time is in LED's and part is in segment displays. The time stuff and display all seems to work fine - if I'm not calling it from after an interrupt.

Thank you again!

-Tom

[CocaColaKid]

Tom, Trying using the insert code option. Make it much easier to read. The command is:

(code)
blah
blah
blah
(/code)

The the () with [].

[Yuantu Huang]

Hi Tom,

You can try goto instead of gosub and change 'pause n' into

for i = 1 to n
pause 1
next i

everywhere except inside of the interrupt subroutinue. Of course, if statements within gosub takes several mill-seconds, then leave it is.

I use the above method in my project and it works. You may try it and let me know the result.

Once again, PBP is very latency interrupt implementation because it must finish the current statement execution before jumping into the interrupt subroutinue. So make sure the jobs within each statement take short time as possible as you can.

[tbirchall]

Ahhhhh! I can't belive it. I'm embarrassed to say it was a leftover line of code from when I was trying to get it working originally. In the displayTime routine, I had a call to LOW 0. This would have changed the pin to be an output and therefore no longer would be triggered by the interrupt button. Doh!

Thank you everyone for all the help. You rock!

-Tom

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