Hi Adam, ok you only need to worry about cumulative
timing errors, so you can make this work.

Unfortunately you picked a clock of 24 cycles per
event, not 32 cycles! That would make it much easier.
24 is not a good binary number. :o)

I would suggest sync locking to timer0, but maybe not
every event, maybe every 2,3,4 etc depending on your
code.

Ie, send your 4 bits, one bit at each 24 ticks.
The whole thing takes 96 ticks. Plenty of room for
your 4 bits sent, and 4 decs, with only one test of
counter rollover needed.

(96 ticks is 0110 0000 on timer0)
Then near the end of the 96 ticks, just wait for
bits 5 and 6 of timer0 being set.

You can CHEAT here as bit 6 will be guaranteed to
be set, it was set at tick 64, ages ago. So you
only need to test bit 5 of timer0!

Once tick 96 is detected (bit 5!), just clear bits
5 and 6 of timer0. This keeps the lower timer0 bits
intact so you get ZERO timer error. You will get no
cumulative errors at all, you only need to check
rollover once per 96 ticks every 4 bits, and you
have no overhead for interrupt handling etc. :o)

I often fine timer0 is MORE useful WITHOUT interrupt.
-Roman


Adam Smith wrote:
>
> 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.

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