Searching \ for '[PIC]: Four byte counter - best method?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/time.htm?key=count
Search entire site for: 'Four byte counter - best method?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Four byte counter - best method?'
2002\08\07@152746 by Barry Gershenfeld

face picon face
If you otherwise have the time, how about figuring out
beforehand that you will reach zero on the *next*
interrupt, and leave yourself a flag for that.
Check at the top of the i.s.r. and you know
after a single test.

Barry

At 01:55 PM 8/7/02 -0500, you wrote:
{Quote hidden}

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


2002\08\07@153424 by adam

flavicon
face
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.)

> {Original Message removed}

2002\08\07@153824 by Andrew Warren

flavicon
face
Barry Gershenfeld <spam_OUTPICLISTTakeThisOuTspammitvma.mit.edu> wrote:

> If you otherwise have the time, how about figuring out
> beforehand that you will reach zero on the *next*
> interrupt, and leave yourself a flag for that.
> Check at the top of the i.s.r. and you know
> after a single test.

   Before you even start to do things like that, though, it might
   be helpful to re-read the data sheet and notice that DECF doesn't
   affect the Carry flag.

   -Andy

=== Andrew Warren -- .....aiwKILLspamspam@spam@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

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


2002\08\07@155109 by adam

flavicon
face
Whoa!  Thanks for pointing that out...

*sigh* I guess that's another instruction...

movlw 0x01

and then use subwf.  Here is my current version...I made an optimization
at the end which saves two instructions (assuming the counter != 0,
since if it is zero we don't need to worry about timing), but in light
of the decf problem we're at 8 instructions not counting retfie...:

       movlw 0x01
       subwf T_FL0, f
       btfsc STATUS, 0 ;test carry flag
       subwf  T_FL1, f
       btfsc STATUS, 0
       subwf  T_FL2, f
       btfsc STATUS, 0
       decfsz T_FL3    ;requires that T_FL3 be one larger than normally
       retfie
       bcf INTCON, GIE

> {Original Message removed}

2002\08\07@155946 by Barry Gershenfeld

face picon face
At 02:33 PM 8/7/02 -0500, 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).

Sorry.  I read it as "instructions before the [single instr]" rather
than "before the retfie".

I think that if you have that close of a time constraint, that this
may not be the way you want to do it.  (I also know you want to see
if you can do it...and I also know that if it works, then, it works :)


>(The code that executes in-between interrupts is just an infinite loop.
>This is running on a PIC16F872 @ 3.6864 MHz.)

Ok, on the chance that the interrupt must be short, but that
the time from "timeout" to actually doing that "one instruction"
is not so critical, use your "infinite loop" time to offload some
of that decrementing or checking.

Barry

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


2002\08\07@162942 by Roman Black

flavicon
face
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.


2002\08\07@164012 by adam

flavicon
face
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 removed}

2002\08\07@165458 by Roman Black

flavicon
face
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:
{Quote hidden}

> > {Original Message removed}

2002\08\07@174810 by Olin Lathrop

face picon face
{Quote hidden}

Does the foreground infinite loop call any subroutines?  If not, then you
could re-enable interrupts in the interrupt routine.  That causes the
interrupt routine to restart when a new interrupt occurs.  In other words,
an interrupt condition becomes a GOTO 4.  Of course if this happens all the
time, then the foreground loop will never get any cycles (so I guess it
doesn't matter if it can't use the stack).


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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


2002\08\08@025708 by adam

flavicon
face
Hi Roman,

Thanks for your response.  What purpose would timer0 serve?  Since it
runs off of the clock, and the clock drives execution, couldn't I
control timing just as easily (or, easier, in my opinion) by used nops
and such to time things?

I am thinking of processing two bits on each interrupt, such that the
interrupt fires one half of the times that it should; this should allow
it to stay in sync.  Do you agree?

Thanks again for your help!

Regards,
Adam Smith

> {Original Message removed}

2002\08\08@054410 by Roman Black

flavicon
face
Adam Smith wrote:
>
> Hi Roman,
>
> Thanks for your response.  What purpose would timer0 serve?  Since it
> runs off of the clock, and the clock drives execution, couldn't I
> control timing just as easily (or, easier, in my opinion) by used nops
> and such to time things?

Timer0 frees you from ANY long term error. You
soon get tired of counting cycles and adding nops,
especially when you want to tweak things or add
things... Just let timer0 free-run in the background,
and just test bit 5.


> I am thinking of processing two bits on each interrupt, such that the
> interrupt fires one half of the times that it should; this should allow
> it to stay in sync.  Do you agree?

Sure, that is 100% better than your original version
with one interrupt and one bit every 24 cycles.

Can you tell how you are making an interrupt every 24 or
48 cycles? If you are clearing timer0 to get that 24
count, there is no need for that or the int handling.
Just let timer0 free-run, check for a high bit, make
your event, and just clear the high bit. The low bits
are intact and timer0 is never upset and never loses
count.

My best suggestion is still the "96 ticks" system
below, should give you a heap of free processor time.
:o)
-Roman


>
> Thanks again for your help!
>
> Regards,
> Adam Smith
>
> > {Original Message removed}

2002\08\08@122617 by Mike Mansheim

flavicon
face
>  Before you even start to do things like that, though, it might
>  be helpful to re-read the data sheet and notice that DECF doesn't
>  affect the Carry flag.

Interesting you mention that.  This is true for the 16 series, but NOT
for the 18 series.
I used a slightly modified version of John Payson's binary to decimal
routine from piclist.com on a 16 series chip - when I moved the code to
an 18 series chip, it didn't work.  It turned out that it was because
DECF now affected the carry flag.
So, I thought, sure would be nice if the instruction DIFFERENCES between
the series were documented somewhere, rather than just me discovering
them by slogging through the data sheets.  Then, hmmm, I wonder if
Microchip did exactly that.  From the back of the data sheet, with a
little poking around that obtuse website, and presto:  AN716.  Covers
the instruction differences and a lot more!  Of course, this is for the
'C' series; an 'F' series equivalent would be nice (and may even exist),
but this one is helpful.
Could have saved some time by looking for this first - my bad!

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...