Searching \ for '[PIC]: Timer0 Interrupt Timing' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'Timer0 Interrupt Timing'.

Exact match. Not showing close matches.
'[PIC]: Timer0 Interrupt Timing'
2001\06\21@014231 by

Hi,

Although I've been using PICs for a while now, I'm not feeling good while
using TMR0 overflow interrupt.I've given a formula below which I have
derieved and I think it's correct. can someone tell me if there is any error
in it? The formula is for obtaining the frequency at which TMR0 interrupt is
called.

(Fosc /4)
Fout= __________________________
(256-TMR0Val) * Prescaler

Fout      :- The frequency of TMR0 Calls
Fosc      :- The External Clock frequency of the PIC
TMR0val   :- The value which will be loaded into TMR0 reg on Overflow
Prescaler :- The Prescaler Value

THe first noticable problem is that there is no compensation given for the
loss of prescaler counts when TMR0 Reg is reloaded with a new value. Does
anyone have a better formula ?

Thanking You,

Jeethu Rao
http://www.jeethurao.com

--

Jeethu, there is a method ( Steinhart ? method ) for no errors timing
generation. A wile ago, Roman Black promised an example with this method
on his site, maibe it was just a promise... I don't know.
Here is the story of that method posted by Roman :

Hi Guys, I've implemented a version of Bob's
zero-error one second timer. I added two changes
and the whole thing fits in just a handful of
instructions. It will give perfect results with
any crystal speed (that divides evenly by 4).

Basic theory: (example 16MHz crystal, 4MHz instruction)
* put one second value in 24bit var (4,000,000 ticks)
* the TIMER0 int is every 256 instructions
* every int we subtract 256 from value
* when value gets <0 we generate the one second event,
and add another 4,000,000 ticks to var

It has zero cumulative error and zero short-term
average error. There will be a max error per second
of 256 instructions (64uS at 16MHz crystal).

The two changes I made from Bob's idea are;
* subtracting a set value of 256 (1x mid-byte)
* adding an extra 256 ticks at the start.

The first change means that instead of doing a
proper 24bit subtract every int, you just need
to dec the mid byte of the var, (and do carry test
and dec msb if needed). Very fast and small code.

The second change means the var never goes below
zero, instead our <0 test simply becomes a <256
test.. This is very quick, we just test that
msb=0 AND mid=0.

This condition means that now to add the 4,000,000
ticks to the variable again we are guaranteed that
msb and mid bytes are 0, so we can simply load
the two values from literals straight into the
msb and mid bytes. We no longer need a proper
but this is only one byte add and one carry test.
If carry, we can just inc the mid byte, as it's
value is guaranteed.
The whole thing is very small and quick as there
are no real 24bit add/subtracts needed. :o)

-----------------------------------------------------
My code is specific to my app but here is the
psuedo code:

initialising: (assuming 16MHz crystal, 4MHz clock)
set TIMER0 to generate int every 256 clocks
put 4,000,000 in 24 bit var
add another 256 to var (inc mid byte)

int handler:
save off status/w

dec mid byte (subtract 256 from total value)
check carry and dec msb if needed
(that was our entire 24bit subtract!)

now test for msb=0 AND mid=0 (detect <256)
if not, goto int exit (very quick int in most cases!)

(here we have detected 1 sec event)
generate 1 second event

(now we do the add 4,000,000 again)
load msb value into msb (msb was guaranteed 0)
load mid value into mid (mid was guaranteed 0)
add lsb value to whatever is left in lsb
if carry, inc mid
(that's our whole 24bit add done!)

int exit:
restore status/w
-----------------------------------------------------

There are a lot of good things about Bob's system.
Any crystal can be used, if it gives x instructions/sec.

It will also work great for other timing periods,
like my datalogger that needs an event at 2Hz, 4Hz, 8Hz,
selectable. I just change the total value of ticks
added to the 24bit var. This can be done on the fly
with no problems.
Quirky thing? With my 16MHz crystal, the clock is 4MHz.
So a one second period is 4,000,000 ticks. This just
happens to be 3D 09 00 in 24bit hex. Notice the lsb
is zero. This means that there will be NO ERROR on a
one second period. No jitter, as the only jitter with
this system is the lsb averaging. That was good luck,
I found it by accident! :o)

The jitter is not a big problem as with most crystals
it will be a short term average. With a 8MHz crystal,
(2,000,000 ticks) one second will be 128 ticks late,
the next second will be perfect. A 2-cycle average
with zero average error. A 4MHz crystal gives 4-cycle
average with every 4th second perfect.

On Thu, 21 Jun 2001, Jeethu Rao wrote:

{Quote hidden}

--
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

Thanks Vasile, hey it's almost finished. :o)
It will be posted tomorrow night.
-Roman

Vasile Surducan wrote:
{Quote hidden}

--
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

>              (Fosc /4)
> Fout= __________________________
>        (256-TMR0Val) * Prescaler
>
> Fout      :- The frequency of TMR0 Calls
> Fosc      :- The External Clock frequency of the PIC
> TMR0val   :- The value which will be loaded into TMR0 reg on Overflow
> Prescaler :- The Prescaler Value
>
> THe first noticable problem is that there is no compensation given for the
> loss of prescaler counts when TMR0 Reg is reloaded with a new value. Does
> anyone have a better formula ?

The prescaler does not get reset when TMR0 is loaded, so this mode isn't
useful with the prescaler.  You can still use timer 0 without the prescaler
to interrupt a fixed number of instructions > 256 in the future.  First,
"compute" the delay time in instructions DIV 256 and MOD 256, which are just
the high and low byte of the 16 bit number, respectively.  Use the low byte
to start out timer 0, then count the desired number of timer 0 overflow
interrupts.  This method causes the short interrupt to happen first since it
may happen very quickly.  The remaining interrupts will happen with 256
instruction between them.

********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinembedinc.com, 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

Jeethu Rao <jeethujeethurao.com> wrote:

>              (Fosc /4)
> Fout= __________________________
>        (256-TMR0Val) * Prescaler
>
> Fout      :- The frequency of TMR0 Calls
> Fosc      :- The External Clock frequency of the PIC
> TMR0val   :- The value which will be loaded into TMR0 reg on Overflow
> Prescaler :- The Prescaler Value
>
> THe first noticable problem is that there is no compensation given for
> the loss of prescaler counts when TMR0 Reg is reloaded with a new
> value. Does anyone have a better formula ?

and Olin Lathrop <PICLISTmitvma.mit.edu> replied:

> The prescaler does not get reset when TMR0 is loaded, so this mode
> isn't useful with the prescaler.

Olin:

I assume that you meant to say that the prescaler DOES get reset.

Jeethu:

It's possible to compensate for the prescaler-reset if you're clever.
See the message I posted back in 1997; it's at:

http://www.piclist.com/postbot.asp?id=piclist\1997\03\27\145834a

-Andy

=== Andrew Warren --- aiwcypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
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

>
>     http://www.piclist.com/postbot.asp?id=piclist\1997\03\27\145834a
>

This really ticks me off. I do not like the piclist site or its policies
or its snoopyness. There are less intrusive methods of preventing email
address mining. Why, for instance, do you need my phone number??

Also, what's this crap about reserving the right to sell data? I never
gave piclist.com any right to profit from me, no matter how benign the
intent. I also never gave piclist.com permission to use or edit my works
and then sell them.

There are things in there I wrote and did not give permission to sell.

Grrrr....

-Bob Blick

--
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

At 10:27 AM 6/22/01 -0700, Bob Blick wrote:
> >
> >     www.piclist.com/postbot.asp?id=piclist\1997\03\27\145834a
> >
>
>This really ticks me off. I do not like the piclist site or its policies
>or its snoopyness. There are less intrusive methods of preventing email
>address mining. Why, for instance, do you need my phone number??
>
>Also, what's this crap about reserving the right to sell data? I never
>gave piclist.com any right to profit from me, no matter how benign the
>intent. I also never gave piclist.com permission to use or edit my works
>and then sell them.
>
>There are things in there I wrote and did not give permission to sell.
>
>Grrrr....
>
>-Bob Blick

I feel like I've just been shrink-wrapped.

--
Dave's Engineering Page: http://www.dvanhorn.org

I would have a link to http://www.findu.com/cgi-bin/find.cgi?KC6ETE-9 here
in my signature line, but due to the inability of sysadmins at TELOCITY to
differentiate a signature line from the text of an email, I am forbidden to
have it.

--
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

Hi Bob,

I just registered using only my email account, and the application
apparently went through. I have'nt tried to access the archive yet,
but some while ago it was no joy without the bio, so something has
changed, or been fixed.

regards, Jack

Bob Blick wrote:
{Quote hidden}

--
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

Bob Blick <PICLISTmitvma.mit.edu> wrote:

> >
> >     www.piclist.com/postbot.asp?id=piclist\1997\03\27\145834a
> >
>
> This really ticks me off. I do not like the piclist site or its
> policies or its snoopyness.

Ok, Bob, here's the post from 1997:

Kalle Pihlajasaari <PICLISTMITVMA.MIT.EDU> wrote:

> > adding to (or subtracting from) TMR0 is the best way to reload
> > it, for exactly the reason you describe.
>
> If I am not mistaken, this 'benefit' would be almost lost if you
> had other than a 1:1 prescaler as the prescaler value would be
> cleared and lost.

Kalle:

Yes and no.  It should be possible to write some clever code to
determine EXACTLY when the TMR0 register increments... Using that
code, you could reload TMR0 without losing the prescaler state.

I'm taking a lunch break anyway... Maybe I can come up with an
example.  Here:

; Enter this section with TMR0 between 128 and 255, inclusive,
; and the prescaler divide-by-ratio set to divide-by-4.

WAITFOR0:

BTFSC   TMR0,BIT7       ;WAIT FOR TMR0 TO OVERFLOW.
GOTO    WAITFOR0        ;

; AT THIS POINT (SINCE OUR "WAITFOR0" LOOP HAS A RESOLUTION OF 3
; CYCLES), THE TMRO:PRESCALER REGISTERS CAN BE EQUAL TO ANY OF
; THE FOLLOWING COMBINATIONS:
;
;     TMRO  PRE
;      00    2
;      00    3
;      01    0

BTFSS   TMR0,BIT0       ;IF TMR0 = 01, WASTE 2 CYCLES.
GOTO    \$+1             ;OTHERWISE, WASTE 3 CYCLES.

; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO ONE OF THESE:
;
;     TMRO  PRE
;      01    1
;      01    2

GOTO    \$+1             ;WASTE TWO CYCLES.

; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO ONE OF THESE:
;
;     TMRO  PRE
;      01    3
;      02    0

BTFSS   TMR0,BIT1       ;IF TMR0 = 02, WASTE 2 CYCLES.
GOTO    \$+1             ;OTHERWISE, WASTE 3 CYCLES.

; AT THIS POINT, TMR0:PRE CAN ONLY BE EQUAL TO:
;
;     TMRO  PRE
;      02    2

GOTO    \$+1              ;WASTE TWO CYCLES.

; TMR0 ALWAYS INCREMENTS FROM 02 TO 03 RIGHT HERE.

MOVWF   TMR0             ;THE RELOAD VALUE BECAUSE THESE TWO
;INSTRUCTIONS TAKE 2 CYCLES TO
;2-CYCLE SYNCHRONIZATION DELAY.
;WHEN TMR0 STARTS INCREMENTING
;AGAIN, IT WILL BE AT -EXACTLY- THE
;MOMENT THAT TMRO:PRE WOULD HAVE
;ROLLED FROM 03:3 TO 04:0.

Of course, I haven't tested the above code -- I just typed it into
this message, so it may have bugs -- but you get the idea.  Similar
code can be written for any porescaler divide-by ratio.

-Andy

=== Andrew Warren - fastfwdix.netcom.com
=== Fast Forward Engineering - Vista, California
===
=== contributing to the PICLIST Fund.  Details are at:
=== http://www.geocities.com/SiliconValley/2499/fund.html

=== Andrew Warren --- aiwcypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
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

> I assume that you meant to say that the prescaler DOES get reset.

Oops, yes, that's what I meant to say.  That's why you can't set up a
reliable periodic interrupt with timer 0 at other than multiples of 256
instructions and still use the prescaler.  Normally, without the prescaler,
you would add an offset into timer 0 each interrupt, but won't work because
you don't know what the prescaler was when you did the add.

********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinembedinc.com, 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

Vasile,
I almost understood your method, but where does the Prescaler value go?
You did'nt write anything about that. Could you please tell me a more
refined version of your algorithm to find out the TMR0 period ?

Thanking you,
Jeethu Rao
http://www.jeethurao

{Original Message removed}
Jeethu Rao wrote:
>
> Vasile,
>         I almost understood your method, but where does the Prescaler value go?
>         You did'nt write anything about that. Could you please tell me a more
>         refined version of your algorithm to find out the TMR0 period ?
>
> Thanking you,
> Jeethu Rao
> http://www.jeethurao

Hi Jeethu, I put the whole procedure and complete
code samples up on this web page:

http://centauri.ezy.net.au/~fastvid/one_sec.htm

The code will run as it is, flashing a led, and
the prescaler setup is clearly shown.
:o)
-Roman

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

{Quote hidden}

I just read that and it didn't seem like a big deal to me.  Maybe that's
because I just always assume that I've lost control over anything I send to
a public email list or newsgroup.  If I want to retain some rights to
something, I post it on my own web pages with suitable copyright notices,
then only reference it by URL on a public list.  That way I have complete
control and it's easier to update and maintain.  For example, see
http://www.embedinc.com/pic.

********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinembedinc.com, http://www.embedinc.com

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

At 10:23 AM 6/23/01 -0400, Olin wrote:
> > > >     www.piclist.com/postbot.asp?id=piclist\1997\03\27\145834a
> > > >
> > >
> > >This really ticks me off. I do not like the piclist site or its policies
> > >or its snoopyness. There are less intrusive methods of preventing email
> > >address mining. Why, for instance, do you need my phone number??
> > >
> > >Also, what's this crap about reserving the right to sell data? I never
> > >gave piclist.com any right to profit from me, no matter how benign the
> > >intent. I also never gave piclist.com permission to use or edit my works
> > >and then sell them.
><snip>
>I just read that and it didn't seem like a big deal to me.  Maybe that's
>because I just always assume that I've lost control over anything I send to
>a public email list or newsgroup.  If I want to retain some rights to
>something, I post it on my own web pages with suitable copyright notices,
>then only reference it by URL on a public list.  That way I have complete
>control and it's easier to update and maintain.  For example, see
>http://www.embedinc.com/pic.

Piclisters and Piclist owners should note that just because a program is
posted on PICLIST doesn't necessarily mean that the copy is no longer owned
by the expressing party.

Under current USA copyright law, it is not necessary to mark the copy with
a copyright. The copyright can be imposed and perfected at a later date.

Otherwise simply playing or singing a song would lose the author all rights
to the music. How many times have you heard a "copyright notice" line at
the end of a concert?

Collecting and selling email posts and contained programs may end up
Piclist in the same place Napster did! The Piclist owners should have
obtained copyright releases from members when they signed up, or get them
now from the posters that are being copied.

Of course, this only applies to the possible damages from copyright
infringement, not proprietary property. Those rights are lost upon the
public utterance of the contents of the email.

If the book and CD do not generate profits (e.g., sold for cost), the issue
is probably a moot point.

================================================================
Robert A. LaBudde, PhD, PAS, Dpl. ACAFS  e-mail: rallcfltd.com
Least Cost Formulations, Ltd.            URL: http://lcfltd.com/
824 Timberlake Drive                     Tel: 757-467-0954
Virginia Beach, VA 23464-3239            Fax: 757-467-2947

"Vere scire est per causas scire"
================================================================

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

Roman,

Your 1 sec timer code is really cool. I think I'd better be off using a
modified
the TMR0 reg.

My application is for a "Smart" UPS based on 16f877 using its PWM output.
So, if it is to work as planned, it must execute the target routine 3200
(50Hz * 2 * 32 times) times.

Won't the Interrupt being called so very often (every 256 cycles)
severely reduce the MIPS available to Non ISR Code ?
I know this is quite a wierd question. But I just asked it out of curiosity.

So as per the calculations given in your page,
Xtal_Freq = 2,000,000 Hz (20 Mhz)
reqd_Freq = 3200 Hz
Therefore, the 24bit value = 1562 (.5 ignored)
(Am I right with it ?)

And can you please tell me a straightforward method to calculate the jitter
?

Thanx a lot!

Jeethu Rao

{Original Message removed}
Hi Jeethu, the one-second timer system is really
better suited to longer periods.

Once you start talking 3200 Hz I think maybe you
will be better off dedicating a timer/counter and
using that to generate an int. ie, set it for the
3200 Hz period, then it generates an int, then reload
it for the next time.

Whatever system you use, at 3200 Hz any procedure or
test is going to use a significant percntage of your
timeslice. If its only 10% or 20% then your design
has probably been done well. Timeslice issues can
get very complex, really it depends on what task is
most important...
:o)
-Roman

Jeethu Rao wrote:
{Quote hidden}

> {Original Message removed}

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