Searching \ for '[PIC]: Accurate timing methods' 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/devices.htm?key=pic
Search entire site for: 'Accurate timing methods'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Accurate timing methods'
2003\02\12@162555 by Ian McLean

flavicon
face
Roman,

I wanted to thank you for some excellent code I found on your Website at
http://www.romanblack.com/one_sec.htm.  It certainly takes all the hard work out of
doing accurate timing on the PIC.

I have just spend all night getting my Tmr0 interrupt working properly - a
few gotcha's with saving the context and resetting PCLATH got it working
finally !  It took me a while to realise that if I am using more than one
code page on the PIC, and my ISR sits in the first code page, the call to
the ISR on Tmr0 overflow does NOT set PCLATH to the code page of the ISR -
so if you do not set it yourself at the start of the ISR after saving the
context, and you have call's or goto's in your ISR - your in trouble !

I thought it might be an idea to post this to the list - firstly your Web
server and mail address seem not to be responding this morning ?  And
secondly - esp. for the newbies on the list - if you are looking for an easy
way to do ZERO-ERROR timing from a few milliseconds to a few seconds, then
visit the above address, and have a look at Roman's method of doing it, and
your sorted !

Again thanks
Ian

{Original Message removed}

2003\02\12@180515 by Olin Lathrop

face picon face
> I have just spend all night getting my Tmr0 interrupt working properly -
a
> few gotcha's with saving the context and resetting PCLATH got it working
> finally !  It took me a while to realise that if I am using more than
one
> code page on the PIC, and my ISR sits in the first code page, the call
to
> the ISR on Tmr0 overflow does NOT set PCLATH to the code page of the
ISR -
> so if you do not set it yourself at the start of the ISR after saving
the
> context, and you have call's or goto's in your ISR - your in trouble !

Yup, and more trouble if you don't save PCLATH before clobbering it in the
ISR and not restore it before returning.

I've got a template interrupt routine that automatically inserts the
appropriate PCLATH code depending on whether the particular PIC has more
than one code page or not.  Take a look at the QQQ_INTR.ASPIC module at
http://www.embedinc.com/pic.


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

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\12@185144 by michael brown

picon face
On Wednesday 12 February 2003 03:24 pm, you wrote:

> I have just spend all night getting my Tmr0 interrupt working
> properly - a few gotcha's with saving the context and resetting
> PCLATH got it working finally !  It took me a while to realise that
> if I am using more than one code page on the PIC, and my ISR sits in
> the first code page, the call to the ISR on Tmr0 overflow does NOT
> set PCLATH to the code page of the ISR - so if you do not set it

Nothing "sets" PCLATH except your own code.

> yourself at the start of the ISR after saving the context, and you
> have call's or goto's in your ISR - your in trouble !

What PIC are you using?  Unless you have a large amount of code  (>2K on a 14 bit part), you shouldn't need to put anything into PCLATH to do a goto or call.  The goto and call instructions have an 11 bit operand so they can cover an entire 2K.  It's the adding to PCL directly (like during table lookups using ADDWF  PCL,F) that make handling PCLATH properly so important.  Because PCL is only 8 bits, it needs to obtain the rest of the bits from PCLATH when you use "computed gotos".

I just finished wasting several hours re-learning this myself.  I cut and pasted some old code (that used to work perfectly ;-)  It had a couple of ADDWF PCL,F doo-dads in there which led to all kinds of interesting behavior.  Now it's fixed right.

Key things to save in an interrupt routine that Microchip doesn't really warn you much about:  FSR and PCLATH  Remember interrupts could occur at any time, between any two instructions (let's not get pedantic here folks, KISS).  Eventually, they will.  ;-)  BTW, don't forget to fix RP0, RP1 upon entry to your subroutine, otherwise you can clobber the OPTION reg when reloading TMR0 (yet another "interesting" experience  ;-)

michael

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\18@010837 by Roman Black

flavicon
face
Thanks for the nice words, BUT I must stress that
Bob Ammerman provided the source idea of the zero-
error timing system, I merely tweaked it a bit for
the PIC and wrote up the page.

But I do think the idea is under-utilised, it is
awesome for getting ANY low-freq clock pulse freq
from a PIC with ANY value of crystal. Both pulse
rate (ie one second pulses) and PIC crystal are
2 simple constants that can be changed to suit your
needs.

One example would be for a "clock" or other time-
keeping product, you can manufacture with any value
of crystal bought from surplus suppliers. If you
get a batch of different speed crystals just change
one constant in your code and clock is still 100%
accurate. :o)
-Roman


Ian McLean wrote:
{Quote hidden}

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

2003\02\18@044648 by hael Rigby-Jones

picon face
> -----Original Message-----
> From: Roman Black [SMTP:spam_OUTfastvidTakeThisOuTspamEZY.NET.AU]
> Sent: Tuesday, February 18, 2003 5:59 AM
> To:   .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Subject:      Re: [PIC]: Accurate timing methods
>
> One example would be for a "clock" or other time-
> keeping product, you can manufacture with any value
> of crystal bought from surplus suppliers. If you
> get a batch of different speed crystals just change
> one constant in your code and clock is still 100%
> accurate. :o)
> -Roman
>
Well, as accurate as the crystal anyway :o)

I guess this technique is effectively a phase accumulator so although the
average error will be zero, the output will suffer from some jitter.

Mike

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

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