Strange results with PBP3 and instant interrupts

[R.G.Keen]

It gets stranger, if more useful. The real problem with blowing out of the interrupt timing was the
'n = Value DIG i ' statement (which I notice I hosed up posting the source code.)

I moved the "@ INT_RETURN " statement up a line at a time, and when I got above the "DIG" statement, timing was magically as expected. No amount of dinking with the statement and retrying the syntax, limits, whatever would stop this.

When I split the "Value" variable into three digits of one byte each and used an IF array to make decimal counting work in the main loop, and changed to a select statement for the pre-carved-up digits in the interrupt loop, it started working just fine.

Either there is a vaster subtlety than I can see, or the "DIG" math function is broken in some way that interacts with timer1 interrupts.

[HenrikOlsson]

Hi,
The first thing that got my attention was the dual interrupt service routines coupled to the same interrupt source. I see that you're not resetting the flag in the ASM handler so it goes in, reload the timer, returns and immediately goes back to PBP handler - I think that's what it'll do or at least what's it meant to do. Is there any reason for not having the reload code, in ASM, as a block at the beginning of the T1_Handler ISR? Not saying the way you've done it doesn't work but it seams a bit wasteful and I don't think I've seen dual ISR's like that before.

As for the DIG operator I can't say for sure but I'm having a hard time seeing HOW it could interfere with TMR1 or the interrupts. Apparently something strange is going on but I suspect the actual problem is something else than the DIG operator.

I know, not much real help but anyway...

/Henrik.

[Acetronics2]

Hi,

Henrik found it ...

Why not reload timer simply using PBP ???

would only make ONE interrupt stubb.

Past that, I don't think using PBP "bits" into an ASM part is really safe ...

;---Reload Timer1------
ASM
ReloadTMR1
MOVE?CT 0, T1CON, TMR1ON ; 1 stop timer
MOVLW LOW(TimerReload) ; 1 Add TimerReload to the 
ADDWF TMR1L,F ; 1 value in Timer1
BTFSC STATUS,C ; 1/2
INCF TMR1H,F ; 1
MOVLW HIGH(TimerReload) ; 1
ADDWF TMR1H,F ; 1
MOVE?CT 1, T1CON, TMR1ON ; 1 start timer
INT_RETURN
ENDASM

Alain

[SteveB]

R.G,
From a overall perspective, the best way to handle interrupts is to do as little as possible inside them, and let the maid code loop do all the heavy lifting. So along those lines, here are some suggestions:
- Get rid of the the line: "INT_Handler TMR1_INT, _T1handler, PBP, yes"
- Set a flag in the "ReloadTMR1" to track when it has been called
- In you main loop, check to see if the flag has been set
- - if yes, run T1Handler and clear the flag

If your main code loop is really long, you can check the flag a couple of times in the loop.

I don't think using PBP "bits" into an ASM part is really safe ...

Unless you are REALLY careful, and fully understand what's happening behind the scenes at the assembly level, this is good advice.

[HenrikOlsson]

Hi,
While I agree that you shouldn't spend more time in the interrupt than neccessary (ie, don't use any Pause or other commands that "holds" the processor) using the interrupt to set a flag which is then polled and handled in the main routine kind of defeats the purpose of the interrupt in the first place IMHO. You might as well poll the interrupt flag in the main routine and then GOSUB a handler that reloads the timer and resets the flag.

Obviosuly it depends on how often the code is supposed to run and with what latency etc. For example if something is to be run at 1Hz and a couple of ms or whatever worth of "jitter" doesn't matter then having a tick count maintained by the ISR which signals the main routine is a good idea. But if the code needs to run at specific and precise intervals then having it in the ISR is the way to go.

Depending in the application it can also be a good idea to split the tasks between the ISR and the main routine. For example use the ISR to capture and calculate the value, then signal the main routine that a new value is ready and have IT send it instead of holding up the ISR with a HSEROUT or whatever. Even better in this case is of course an interrupt driven TX-routine as well but that's not the point.

/Henrik.

[R.G.Keen]

Thanks for the reading, and the good advice. What you're saying is generally correct, and it is always possible that I have flatly missed something on the return from interrupt.

However, the interrupt scheme is the DT instant interrupts include files; it may be a little roundabout but it works in general. And while interrupts do need to be short and quick, I did use exactly this code, statement for statement, in the 2.60a compiler and it worked perfectly for other PICs.

I do need the preciseness of running the code on the interrupts. I normally use flags to the main routine as Henrik suggests when I can, but this needs the timing precision, and equally important, not having a second interrupt happen while the actions are being taken.

And, as I mentioned, I recoded the logic into other (longer and clumsier) statements, and it started working. That was the one that got me. It appears that the single statement was what was throwing off the timer interrupt. It looked like it made the ISR miss the service interval, and let the timer count through its full 16 bits instead of being reset. And removing that one statement made the longer and clumsier coding work.

[R.G.Keen]

Yet more interesting results.

The "DIG" statement works outside of an interrupt routine and does not interfere with interrupts.
A "DIG" statement inside the interrupt routine sometimes make the timer interrupt miss.

[HenrikOlsson]

Hi,
The only thing I can think of is that the DIG operator (combined witht the rest of the ISR) consumes too many cycles and that the interrupt overruns itself. Can you, just as a test, increase the time between interrupts to say 2ms instead of 1 and see if that takes care of it?

/Henrik.