Searching \ for ' Antwort: [PIC]: External clock...' 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=clock
Search entire site for: 'Antwort: [PIC]: External clock...'.

No exact or substring matches. trying for part
PICList Thread
'[PICLIST] Antwort: [PIC]: External clock...'
2002\05\17@024138 by Martin Buehler

flavicon
face
you have to use one of the timers to do the division by 193, and not the
isr.
an isr is much too slow to handle all these interrupts, coming every 5us
with this design.
so your pulse is now about
                (time, required by the isr) / 5us = pulselength [s]
good luck!
tino




Pic Dude <spam_OUTpicdudeTakeThisOuTspamAVN-TECH.COM>
Gesendet von: pic microcontroller discussion list <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
17.05.02 08:26
Bitte antworten an pic microcontroller discussion list


       An:     PICLISTspamKILLspamMITVMA.MIT.EDU
       Kopie:
       Thema:  [PIC]: External clock...


Somehow my clock ckt seems to be running a lot slower than it should, but
I'm stumped.  Here are some details...

Swapped 32.768 khz crystal/caps for a 1.544 MHz external oscillator, into
an 16F872 circuit.  This is an ECS-200 series oscillator in a 14-pin metal
pkg, but only has 4 pins, and only 3 of those are active -- +ve, gnd, and
out
(which I connected to OSC1/CLKIN).  OSC2/CLKOUT is now open.

Pre-scaler is now 1:8 and ISR routine divides a few times:  first by 193,
then by 25, then by 10, to give me 1-sec pulses.  (There's a reason for
those divisors in case you're wondering -- I can get 0.1 sec pulses I need
for something else).

However, it's running MUCH slower than that -- taking a few minutes to
generate a 1-sec pulse!

Am I missing something here?  I've left the osc config bits to LP, and
verified the ext osc freq with an oscilloscope.  Also, there's a setting
in
OPTION_REG for selecting the source clock for TMR0 to internal or
T0CKI, but I don't think this setting has anything to do with this prob.

Any ideas why I may be seeing these results?

Cheers,
-Neil.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\05\17@115229 by Pic Dude

flavicon
face
Not sure what you mean by "use one of the timers"  I am using
the prescaler in div-by-8 mode, so the ISR gets called at a
freq of 48250Hz.  That's when I divide by 193 in the ISR, etc.
I could adjust the prescaler to div-by-16, but the freq is
not further divisible by any multiple of 2 after that.

So you're suggesting that my ISR does not get completed before
another TMR0 interrupt is generated, so some interrupts go
ignored?

Here is some code sections that better explain what I'm doing...

------------------------------------------------------------
<code snipped>

       CBLOCK  H'20'
<code snipped>
          SCALER0              ; Divide counter for TMR0
          SCALER1              ; Divide counter for TMR0
          SCALER2              ; Divide counter for TMR0
       ENDC


       ORG     0x00
       goto    Init

       ORG     0x04
       goto    ISR


;-------------------------------------------------------------------
;   Initialization section
;-------------------------------------------------------------------

Init:
       bsf     STATUS,RP0              ; Select bank 1
       bcf     STATUS,RP1              ; ...

       movlw   B'00000010'             ; Port B pullups enabled, internal ...
       movwf   OPTION_REG              ; ... clock, prescaler 1:8

<code snipped>

       movlw   D'193'
       movwf   SCALER0         ; Reset TMR0 divide counter
       movlw   D'25'
       movwf   SCALER1         ; Reset TMR0 divide counter
       movlw   D'10'
       movwf   SCALER2         ; Reset TMR0 divide counter

<code snipped>

       movlw   B'10100000'             ; GIE and TMR0 interrupts enableds
       movwf   INTCON

       goto    Main

;---------------------------------------------------------------------
;   Main code routine
;---------------------------------------------------------------------

Main:
       ;----- Ensure that we're in bank 0 -----
       bcf     STATUS,RP0              ; Select bank 0
       bcf     STATUS,RP1              ; ...


       ;----- Primary loop -----
MainLoop:
<code snipped>
       goto    MainLoop

<code snipped>



;-------------------------------------------------------------------
;   Interrupt Service Routine
;-------------------------------------------------------------------

ISR:
       ;----- Save W and STATUS registers -----
       movwf   TMP_W                   ; Save W
       swapf   STATUS,W                ; Get status (w/o affecting status bits)
       movwf   TMP_ST          ; Save status

       ;----- [ Freq. here = 1.544Mhz / (4 * 8) ] -----

       ;----- Divide TMR0 by 193 to get 1/250-sec pulses -----
       decf    SCALER0,F
       btfss   STATUS,Z                ; Reached 0?
       goto    ISRDone         ; Nothing else to be done for now
       movlw   D'193'
       movwf   SCALER0         ; Reset to 193

;       goto    BYPASS1         ; ***** DEBUG *****

       ;----- [ Freq. here = 1.544Mhz / (4 * 8 * 193) ] -----

       ;----- Divide by 25 to get 1/10-sec pulses -----
       decf    SCALER1,F
       btfss   STATUS,Z                ; Reached 0?
       goto    ISRDone         ; Nothing else to be done for now
       movlw   D'25'
       movwf   SCALER1         ; Reset to 25

       ;----- [ Freq. here = 1.544Mhz / (4 * 8 * 193 * 25) ] -----

       ;----- Get and preprocess button -----
       movf    BUTTONS,W               ; Take button states and...
       movwf   BUTTONS_PREV    ; ... hold it as prev buttons
       movf    PORTB,W         ; Get new button values
       movwf   BUTTONS         ; Hold it
       call    ButtonProc
       call    ButtonActions


       ;----- Divide by 10 to get 1 sec pulses -----
       decf    SCALER2,F
       btfss   STATUS,Z                ; Reached 0?
       goto    ISRDone         ; Nothing else to be done for now
       movlw   D'10'
       movwf   SCALER2         ; Reset to 10

       ;----- [ Period here = 1 sec ] -----


BYPASS1:
       ;---------------------------------------------------------
       ;   From this point, all actions occur at 1-sec intervals
       ;---------------------------------------------------------


<code snipped>


ISRDone:
       ;----- Restore W and STATUS registers -----
       swapf   TMP_ST,W                ; Get status (w/o affecting status bits)
       movwf   STATUS          ; Put it back into STATUS
       swapf   TMP_W,F         ; Swap W nibbles (w/o affecting status bits)
       swapf   TMP_W,W         ; Swap W nibbles again and put into W

       bcf     INTCON,T0IF     ; Reset TMR0 interrupt flag
       retfie



       END


Thanks,
-Neil.




{Original Message removed}

2002\05\17@141713 by Pic Dude

flavicon
face
Just tried changing the pre-scaler to 1:32 but this did not solve
the problem -- my guess is that if it works with the 32khz xtal,
then it should work with the 1.544mhz external clock, but just
much faster.  But that's not what I'm seeing here.

Any other ideas?

Seriously confused,
-Neil.



{Original Message removed}

2002\05\17@160633 by Andrew Warren

flavicon
face
Pic Dude <.....PICLISTKILLspamspam.....mitvma.mit.edu> wrote:

> 1.544 MHz external oscillator .... (which I connected to
> OSC1/CLKIN).  OSC2/CLKOUT is now open.
>
> Pre-scaler is now 1:8 and ISR routine divides a few times:  first by
> 193, then by 25, then by 10, to give me 1-sec pulses.  (There's a
> reason for those divisors in case you're wondering -- I can get 0.1
> sec pulses I need for something else).
>
> However, it's running MUCH slower than that -- taking a few minutes to
> generate a 1-sec pulse!

Neil:

Lemme guess... It's taking exactly 4 minutes and 16 seconds per "1-
second" pulse, right?

I think you're misunderstanding how the TMR0 interrupt works.  The
TMR0 register is incremented by the prescaler, but the TMR0 interrupt
doesn't fire until the TMR0 register overflows from 255 to 0... So
your interrupts are actually happening at 1/256 the rate that you
thought.

Does that explain the behavior you're seeing?

-Andy

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

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\05\17@163959 by Pic Dude

flavicon
face
Don't ask -- I think I just need more sleep or something.
As you were typing this email, I realized the flaw.  Switched
back to the 32.768khz crystal, saw the (correct) timing and
was looking at the code for that, when I realized I'm
accounting for the 256 in that code, but not in the 1.544Mhz
code.

I think that train of thought started when I was trying
to find the factors of 1,544,000 Hz for the dividers, and
being non-divisible by 256, I somehow managed to ignore it.

Okay, it's confirmed, I'm brain-dead.

Guess what I really need to do is set TMR0 to 255-193 on
each interrupt cycle and drop my SCALER0 altogether.

Thanks much,
-Neil.



{Original Message removed}

2002\05\17@184258 by Bob Ammerman

picon face
Don't set TMR0, instead add to it.

The correct value to add should be 256-193+2

The +2 is required because the timer update is inhibited for 2 cycles after
the add.

You should do the add instead of the MOVF to avoid problems with interrupt
jitter.

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Pic Dude" <picdudespamspam_OUTAVN-TECH.COM>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Friday, May 17, 2002 4:37 PM
Subject: Re: Antwort: [PIC]: External clock...


{Quote hidden}

> {Original Message removed}

2002\05\17@224815 by Pic Dude

flavicon
face
Bob,

The calculation (adding 2) is straightforward, but what
do you mean by "jitter".  I remember seeing something on
this a while back (either in the archives or on piclist.org),
but never got a clear explanation of jitter.  Care to
add some enlightenment?

The datasheet also states that the prescaler is cleared
whenever TMR0 is written to.  My understanding is that
the pre-scaler "counts" before TMR0 (since it's the TMR0
transition that triggers the interrupt), so I'm wondering
if modifying TMR0 will cause the clock to run slow due
to the prescaler getting reset when it shouldn't?

Does it even matter?  A quick calculation tells me with
a 1:8 prescaler, say for example the prescaler gets reset
to 0 whenever it just hits its 7th pulse from start.
That means that it loses 7*4*osc-period units of time.
It would do this whenever TMR0 gets reset to 193, which
means every 8*4*193*osc-period units of time.  So time
loss ~= 1 pulse in every 222.  That means about 39.5 days
a year.

That's pretty significant, if it really happens.  Does it?
Or am I totally off on the wrong tangent here?

Thanks,
-Neil.




{Original Message removed}

2002\05\17@231558 by Bob Ammerman
picon face
----- Original Message -----
From: "Pic Dude" <KILLspampicdudeKILLspamspamAVN-TECH.COM>
To: <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU>
Sent: Friday, May 17, 2002 10:45 PM
Subject: Re: Antwort: [PIC]: External clock...


> Bob,
>
> The calculation (adding 2) is straightforward, but what
> do you mean by "jitter".  I remember seeing something on
> this a while back (either in the archives or on piclist.org),
> but never got a clear explanation of jitter.  Care to
> add some enlightenment?

I am not sure if it happens with TMR0 or not, but some interrupt sources
have different latencies depending on whether a one- or two-clock
instruction is executing when the interrupt occurs.

> The datasheet also states that the prescaler is cleared
> whenever TMR0 is written to.  My understanding is that
> the pre-scaler "counts" before TMR0 (since it's the TMR0
> transition that triggers the interrupt), so I'm wondering
> if modifying TMR0 will cause the clock to run slow due
> to the prescaler getting reset when it shouldn't?

Yeah, I assumed you were not using the prescaler. This technique will _not_
work with the prescaler at any setting other than 1:1.

{Quote hidden}

No, you aren't off on a tangent. This is exactly the thing that can happen.

> Thanks,
> -Neil.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\05\18@033945 by Pic Dude

flavicon
face
Hmmm... that's not good.  But this is...

"Yeah, I assumed you were not using the prescaler. This
technique will _not_ work with the prescaler at any setting
other than 1:1."

Since I'm only using a 1:8 prescaler, I can change it to 1:1
and change my div-by-25 to div-by-200.

Thanks much,
-Neil.


{Original Message removed}

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