Strange results with PBP3 and instant interrupts

[Darrel Taylor]

Like Henrik said, @ 4Mhz the DIG command takes longer than the interrupt period.
But it's a little different than you might think.

The digit number that you request makes a huge difference in the execution time.

@ 4Mhz, DIG 0 takes ~322us, well within the 1ms period.
But DIG 1 has to do another divide, so it takes ~638 uS.
DIG 2 = 950us.
And finally, DIG 3 takes ~1.28ms, obviously too long to be in a 1ms interrupt.
After that, the timer reload leaves it overflowed and it has to count all the way back to 65536 before the next interrupt happens. Which is why it seemed like it was doing 4 interrupts at a time.



These times were measured by wrapping the DIG command with HIGH/LOW statements and reading the pulse width on a scope.

HIGH PORTA.3
    n = Value DIG i    ' this statement causes missed interrupts after four are caught
LOW PORTA.3

After bumping up the oscillator to 16Mhz internal, the commands take 1/4th of the time and everything works within the 1ms.

But since the digit only changes when the variable in the mainloop changes, there's no need to calculate it every time in the interrupt handler.
Setting the segment patterns in the mainloop will reduce the interrupt handlers time significantly. Then the interrupt handler just puts the pattern to the pins.
You could probably run at ~20Khz, not that you would want to. 1Khz is fine and there lots of time left over for the mainlop to use.

---

So that brings us back to how could it work on PBP 2.60 with a 16F, and not on PBP3 with an enhanced core..

Well, I don't think that's possible.
I ran the same program on a 16F886 @ 4Mhz, and DIG took even longer
DIG 0 = 385us
DIG 1 = 760us
DIG 2 = 1.15ms
DIG 3 = 1.54ms

Maybe you were running at a different frequency and didn't remember it?

[R.G.Keen]

@ 4Mhz, DIG 0 takes ~322us, well within the 1ms period.
But DIG 1 has to do another divide, so it takes ~638 uS.
DIG 2 = 950us. And finally, DIG 3 takes ~1.28ms, obviously too long to be in a 1ms interrupt.

OK. Looks like a DIG command takes roughly 325 instructions per digit number. I would not have guessed that. And clearly didn't guess that. 8-)

These times were measured by wrapping the DIG command with HIGH/LOW statements and reading the pulse width on a scope.

Good trick. I'll remember that one. It fits my debug style well.

But since the digit only changes when the variable in the mainloop changes, there's no need to calculate it every time in the interrupt handler.
Setting the segment patterns in the mainloop will reduce the interrupt handlers time significantly. Then the interrupt handler just puts the pattern to the pins.

In the real app, it needs to change dynamically on timer ticks, but I could spend the time in the main loop and precalculate all the digits, I guess, so they're all always current except for the ones where the interrupt happens in the middle of the DIG instruction. That means the pattern will be incorrect on average half the time for DIG 2, 3 in 10 for DIG 1, and 3 in 20 for DIG 0; then the pattern will be corrected on the next interrupt. That's certainly better than always being wrong for DIG 4 and nearly always for DIG 2, but requires some thinking as to whether being wrong for one interrupt period is OK.

Fortunately, this isn't running machinery, so I might get away with it. Otherwise, sounds like I might make it with an 8MHz or higher clock. More system design to do.

So that brings us back to how could it work on PBP 2.60 with a 16F, and not on PBP3 with an enhanced core..
Well, I don't think that's possible. ...
Maybe you were running at a different frequency and didn't remember it?

Maybe. I'll dig out the hardware and look. Could be my idiot tech (that's me... ) put in the wrong crystal, which is more likely than your analysis being wrong here. But it's worth digging out to look at. I'm very familiar with solving problems with the Method of Offsetting Errors.

Thank you for the look at the problem. I have annotated my compiler manual at the "DIG" instruction with "NOTE: execution takes about 325 instructions per digit number." Getting to there has now cost me a couple of days, but knowledge is always expensive, I guess. 8-)