Roman,

Before working on this section of the code, I wrote a routine which got
data from a serial interface and copied it asynchronously.  It has its
disadvantages, but I liked the fact that there wasn't any dependence on
anything other than my instruction cycles.  The obvious downfall is that
if the timing goes off just a little bit, this offset will be carried
for the entire session.

The reason that I dismissed that option initially (and I don't have a
whole lot of experience here) was because I wanted to make sure that
everything stayed in sync; I wanted to take advantage of the synchronous
clock signal.  However, perhaps you are right.  Maybe I should just use
the first interrupt to start the ball and then go from there.  Given
that my clock frequency is a perfect multiple of the speed at which I am
sending data, if I do take this approach, do you think that after
17301504 cycles it will still be sync'ed?  The device I'm interfacing to
here is a module with a 14.7456 MHz crystal, so I'm not too sure what to
think.

I look forward to receiving your reply!

Regards,
Adam Smith

> -----Original Message-----
> From: adam-request@viratech.com [mailto:adam-request@viratech.com] On
> Behalf Of Roman Black
> Sent: Wednesday, August 07, 2002 3:27 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [PIC]: Four byte counter - best method?
>
> 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.

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