Searching \ for '[PIC] Newbie seeks better understanding of TMR1 (' 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/begin.htm?key=pic
Search entire site for: 'Newbie seeks better understanding of TMR1 ('.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Newbie seeks better understanding of TMR1 ('
2003\02\18@035857 by Jason Sherlock

flavicon
face
I've been trying to play with the TMR0 and TMR1 timers a bit and while it
seems that I'm on the right track, I'm seeing one thing that I don't quite
understand.  I'm using a PIC16F877 with a 4MHz resonator and I'm viewing all
of my output with an O-scope.

Basically, I'm trying to run with both TMR0 and TMR1 incrementing via the
internal clock without prescaling.  When the timer overflows, my ISR will
clear the appropriate interrupt flag and toggle PORTB:5 (TMR0 interrupt) and
and PORTB:4 (TMR1 interrupt).  The output of PORTB:5 is exactly as I would
expect: a rock-solid (more or less) square wave at 1.95KHz. However, the
output of PORTB:4 is not as nice.  I am seeing a square wave of "roughly"
the frequency I would expect, but the wave keeps shifting across the screen
of the OScope.  Every so often (every two or three cycles) the frequency
fluctuates by +/- a few percent (5 - 10% eyeballing it).  As a result the
waveform keeps expanding and compressing in a seemingly random manner.   I
would like to use TMR1 to make high resolution duty cycle measurements, but
with this kind fluctuation I'm a bit nervous about my accuracy.  Anything
I'm missing/forgetting about?

Thanks.
Jason.

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

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

picon face
{Quote hidden}

How about the fact that you are running two interrupt sources?  If Timer 1
rolls over whilst the PIC is servicing the Timer 0 interrupt then the
toggling of your port bit will be delayed by as long as the ISR takes.

Mike

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

2003\02\18@064135 by Ian McLean

flavicon
face
On the subject of interrupts, I have a another question.

I have found that I had to forego the use of a Timer2 interrupt in an
application because I have LCD routines in my main code body with strict
timing of the strobe pin to get both instructions and data out to the LCD.
No amount of context saving could stop the LCD from doing stupid things when
the interrupt was called.  I assume this is because the interrupt is firing
in the middle of the strobing of the LCD and stuffing up the timing.  My ISR
was doing quite a bit (running a PID loop at the frequency specified by the
Timer2 interrupt).  I thought this was a clever idea, but because I am using
a lot of 32bit floating point in my PID, it takes a good few mS to run, and
changes a lot of registers, which of course need to be saved off and
restored again at the completion of the ISR.  It just became too much of a
pain to try and find what I had missed.

I tried in vain to implement a form of "critical section" in my PIC code by
turning off Timer2 on entry to the routines that service the LCD, and then
turn it back on again afterwards, but that only seemed to fix the problem
half the time.

What can I do to make the interrupt service routine more robust ?

Rgs
Ian

{Original Message removed}

2003\02\18@064548 by ards, Justin P

flavicon
face
Just out of curiosity is the freq for PORTB:4 about 7.62 Hz

Justin
> expect: a rock-solid (more or less) square wave at 1.95KHz. However, the
> output of PORTB:4 is not as nice.  I am seeing a square wave of "roughly"

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

2003\02\18@065837 by Jason Sherlock

flavicon
face
I don't remember exactly, but the number rings a bell.  I'll have to check
tonight when I get home.

{Original Message removed}

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

picon face
{Quote hidden}

Simply disable interrupts around the timing critical section of your code.
On a 14bit core this is as simple as clearing the GIE bit (although check
the datasheet, some olders devices had a slight bug that meant the GIE bit
wouldn't be cleared if an interrupt fired on a the same cycle).

It's usualy a good idea to keep your interrupts as short as possible.  If
you have a task that takes a considerable amount of time, consider setting a
flag in the interrupt and doing the processing in your main loop when the
flag has been set, clearing it afterwards.

Mike

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

2003\02\18@084505 by Ian McLean

flavicon
face
Thanks Michael, that's the trick - too much happening in my interrupt.  I
have changed it to simply set a flag when it fires.  My main loop now checks
the flag, if set it runs the PID loop once, and clears the flag.  I have an
accurate Period/Frequency for my PID again !

It's working fine now, because the ISR doesn't change bulk amounts of
registers or take any time, and the PID loop now runs sequentially with the
LCD updates - no chance of interrupting the LCD routines now for more than a
few mS which does not effect the LCD strobing at all.

Thank you muchly.
Ian.

{Original Message removed}

2003\02\19@070026 by Jason Sherlock

flavicon
face
I think I have things sorted out now, and it appears it was ust my own
laziness that was throwing me off.  Anyway, I was using a digital OScope I'm
borrowing from work to look at my signals.  This scope has a nifty little
autoset button that automagically scales the display depending on the input
signal.  For the TMR0 square wave it worked beautifully.  For the TMR1
square wave it doesn't work at all, but some manual fiddling last night got
the wave form to be more or less stable on the display.  Thanks for the
help.
Jason

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

2003\02\19@132247 by Andrew Warren

flavicon
face
Ian McLean <PICLISTspamspam_OUTmitvma.mit.edu> wrote:

> too much happening in my interrupt. I have changed it to simply set
> a flag when it fires.  My main loop now checks the flag, if set it
> runs the PID loop once, and clears the flag.  I have an accurate
> Period/Frequency for my PID again !

   The next step, of course, is to disable that timer interrupt and
   simply check the INTERRUPT flag in your main loop, rather than
   your user-defined flag.

   Saves time, saves code, saves a register bit.

   -Andy

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

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

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