Adam Smith wrote:
>
> The reason I need this routine to be short is because I have to retfie
> in time for the next interrupt (24 instruction cycles per interrupt, 18
> after you consider the 4 instructions it takes for the PIC to go to the
> interrupt vector, etc. and the 2 instructions it takes to retfie).
>
> Speaking of which, does anyone have any experience with this problem?
> If the interrupt takes exactly 24 cycles (counting the two issues
> above), will it always come through, or should I use a maximum of 23 to
> be on the safe side?
>
> (The code that executes in-between interrupts is just an infinite loop.
> This is running on a PIC16F872 @ 3.6864 MHz.)


Hi Adam, maybe you could rethink the basic operation.
Seems you have an event every 24 cycles, and you just
need to count down once per event for a very big number?

You mentioned "endless loop + int every 24 cycles"...
Why use an int?

Why not hard-code the entire sequence, so it ALWAYS
takes 22 cycles, then just put a "goto start" so the
same 24 cycles keeps looping?

Furthermore, You could put the whole code in a
hard-coded block of 48, divided into 2 total events.

Then, the rollover on decf can only happen in the
second half, the "even" decf. So you only have to
ever check rolling-over in one half, freeing cycles
in the first half.

By the same logic you can use a block of 96 or more
(4 decs) which only has to check the rollover once
out of every 4 total events. Then divide your rollover
(carry) code over the 4 chunks. Rollovers don't have
to be immediate, just done before the end. :o)

Don't think less cycles, think "better way to do it".
:o)
-Roman

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.