Searching \ for '[PIC] constructing a 32 bit timer' 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=time
Search entire site for: 'constructing a 32 bit timer'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] constructing a 32 bit timer'
2005\12\06@210308 by Cristóvão Dalla Costa

picon face
Hello there

Currently I'm using the capture module with a 100 kHz TMR1 clock, but
I need to bump that clock to the megahertz range for increased
precision and for that I need a 32 bit timer.

The obvious way is to set a handler for the TMR1 interrupt and
increment a 16 bit counter for the most significant bits. However
doubts arise as to the accuracy of that method.

How can I be certain that when the TMR1 and CCP interrupts happen
"close enough" that the correct value will be captured? IOW, that if
the TMR1 interrupt happens first the counter is incremented before the
value is captured, and vice-versa? Since PICs only really have one
interrupt it makes things difficult if the second interrupt occurs
between the first and reaching the handling code...

I've come up with the following not-so-errorproof interrupt handler
logic... I'd appreciate very much if any of you could comment on that.
Perhaps someone here has done this before?

if (TMR1F) {
  if (CCP1F && CCP1R > 32767) {
     // consider CCP1 interrupted first before timer overflowed,
     // copy values, clear CCP1F and proceed
  } else {
     // proceed as normal
  }
  counter++;
}

if (CCP1F) {
  // proceed as normal
  // any special handling needed was done in the above block
}


Thanks in advance...

2005\12\06@213724 by Spehro Pefhany

picon face
At 12:03 AM 12/7/2005 -0200, you wrote:
>Hello there
>
>Currently I'm using the capture module with a 100 kHz TMR1 clock, but
>I need to bump that clock to the megahertz range for increased
>precision and for that I need a 32 bit timer.
>
>The obvious way is to set a handler for the TMR1 interrupt and
>increment a 16 bit counter for the most significant bits. However
>doubts arise as to the accuracy of that method.
>
>How can I be certain that when the TMR1 and CCP interrupts happen
>"close enough" that the correct value will be captured?

It's easy to make this 100% error free.

Just look at the rollover flag. If no rollover then the counter
value is okay.

If there was a rollover, then look at the MSB of the captured
number. If a zero, then increment the counter. If it's a 1,
then leave it.

That gives you lots of time to service the interrupt, provided
you don't do anything silly like turning off interrupts for any
length of time or taking very long to service other interrupts.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\12\07@074135 by olin piclist

face picon face
"Cristóvão Dalla Costa" wrote:
> Currently I'm using the capture module with a 100 kHz TMR1 clock, but
> I need to bump that clock to the megahertz range for increased
> precision and for that I need a 32 bit timer.
>
> The obvious way is to set a handler for the TMR1 interrupt and
> increment a 16 bit counter for the most significant bits.

That's going to be tricky because what if a capture happens right after a
timer 1 rollover but before the interrupt routine updates the higher bits?

I usually deal with this by making sure a piece of code gets run more often
than a timer 1 rollover.  This code keeps track of the high byte of timer 1
and adds any new delta to a software counter that can be as wide as you
need.  When processing a capture, update the software counter first just
like you do in the periodic routine.  You then use the counter, the new
value of timer 1 low, and the previous value of timer 1 low to get the exact
counts since the last capture.  As long as periodic routine is run more
often than a timer 1 rollover it all works.  That means it needs to be run a
bit more often than every 65536 instructions (worst case with 1:1
prescaler), so this takes virtually no overhead.  I usually stick it at the
bottom of the main event loop, meaning the software counter gets updated
when the system has nothing else to do.  If you can't guarantee the latency,
use a timer interrupt to set a flag periodically and update the software
counter as a high priority event driven by the flag.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/product

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