Searching \ for '16c84 interrupts' 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/ints.htm?key=interrupt
Search entire site for: '16c84 interrupts'.

Truncated match.
PICList Thread
'16C84 interrupts'
1995\10\13@050630 by att%atlas.king.ac.uk%UKACRL.bitnet

flavicon
face
Dear Piclist,
Can anyone give me some pointers to using the RTCC interrupt on the
16C84?
This is how I've got it set up so far.




start       bcf GLOBAL_INTERRUPT    ; disable interrupts

; for a 2.4576MHz crystal, 2457600/256=9600
; load rtcc with 96 giving 100 interrupts/sec

       movlw   b'000111'   ; assign prescaler 1:256
       option
       movlw   .96
       movwf   TMR0        ; set up timer

other stuff . . . .

       bsf TIMER0_INTERRUPT
       bcf TIMER0_FLAG
       bsf GLOBAL_INTERRUPT

loop    goto loop


service movwf   save_w
       movf    status,w
       movwf   save_s
       bcf GLOBAL_INTERRUPT
       btfss   TIMER0_INTERRUPT
       goto    out
       bcf TIMER0_FLAG
       movlw   .96
       movwf   TMR0

       incf    msec
       movlw   .100
       subwf   msec,w
       btfsc   status,c
       goto    out
       clrf    msec

---
interrupt routine . . . .
---

out
       bsf GLOBAL_INTERRUPT
       movf    save_s,w
       movwf   status
       movf    save_w,w
       retfie


Have I missed something? I seem to get interrupts much faster than I
should.

Many thanks.

/\/\att.

1995\10\13@055108 by .Bellis%psy.ox.ac.uk%UKACRL.bitnet

flavicon
face
> Dear Piclist,
> Can anyone give me some pointers to using the RTCC interrupt on the
> 16C84?
> This is how I've got it set up so far.
>
> ; for a 2.4576MHz crystal, 2457600/256=9600
> ; load rtcc with 96 giving 100 interrupts/sec

The embedded control handbook is wrong.  The RTCC counts at
the instruction cycle frequency rather than the oscillator
frequency.

> Have I missed something? I seem to get interrupts much faster than I
> should.

Four times too fast, I think you'll find.

> Many thanks.
>
> /\/\att.

Ray.

--
 Computing Officer, MRC Research Centre in Brain and Behaviour,
    Department of Experimental Psychology, Oxford University
 <http://www.mrc-bbc.ox.ac.uk/~rpb>  <spam_OUTRay.BellisTakeThisOuTspampsy.ox.ac.uk>

1995\10\13@140031 by Scott Stephens

flavicon
face
>Dear Piclist,
>Can anyone give me some pointers to using the RTCC interrupt on the
>16C84?
>This is how I've got it set up so far.
>
>
>
>
>start       bcf GLOBAL_INTERRUPT    ; disable interrupts
>
>; for a 2.4576MHz crystal, 2457600/256=9600
>; load rtcc with 96 giving 100 interrupts/sec

The crystal frequency is divided by four to generate the clock for TMR0, at
that frequency I would load TMR0 with 32 to get 100 interrupts/second.
2.4576/4=614.4
614.4/256=2.4
2.4K/100=24
256-24=232=E8H

>service movwf   save_w
>        movf    status,w
>        movwf   save_s


Use SWAPF intsruction. It won't affect the ZERO flag as does MOVF

ISR     movwf   W_BACKUP        ;
       swapf   STATUS,W
       movwf   STATUS_BACKUP   ;


>        bcf GLOBAL_INTERRUPT

When an interrupt occurs, GIE is cleared. You don't need to clear it. But
when you do, clear it in the following loop:

Lable   bcf     INTCON,GIE
       btfsc   INTCON,GIE
       goto    lable

0therwise, executing an interrupt and RETFIE could re-inable the interrupt
you've just tried to clear.

>---
>interrupt routine . . . .
>---

>        bsf GLOBAL_INTERRUPT

Don't do that. RETFIE will enable GIE on exit. Enabling it early can cause
recursive interrupts, and crash your stack.

>        movf    save_s,w
>        movwf   status
>        movf    save_w,w
>        retfie

       swapf   STATUS_BACKUP,W ;Restore working reg's now that ISR's done
       movwf   STATUS          ;
       swapf   W_BACKUP
       swapf   W_BACKUP,W
       retfie                  ;End of ISR


Disable RBIE and INTE if not in use, otherwise input on RB0, RB4-7 can
result in interrupts.
Good luck.

1995\10\13@164412 by Eric Smith

flavicon
face
>   service movwf   save_w
>          movf    status,w
>          movwf   save_s
...
>          movf    save_s,w
>          movwf   status
>          movf    save_w,w
>          retfie

You will find that this will cause you problems if you start doing
anything in your non-interrupt code that uses the status register.
The problem is that using a movf to restore registers affects the status
register.  You need to change things around to use a swapf instruction:

int:    movwf   save_w
       swapf   status,w
       movwf   save_s
...
       swapf   save_s,w
       movwf   status
       swapf   save_w,f
       swapf   save_w,w
       retfie

This will work on the 61, 71, and 84, but not on parts with bank-switched
registers.

1995\10\14@001844 by John Payson

flavicon
face
> When an interrupt occurs, GIE is cleared. You don't need to clear it. But
> when you do, clear it in the following loop:
>
> Lable   bcf     INTCON,GIE
>         btfsc   INTCON,GIE
>         goto    lable
>
> 0therwise, executing an interrupt and RETFIE could re-inable the interrupt
> you've just tried to clear.

This problem gives me great appreciation both for Microchip's decision to
mimize interrupt latency time by allowing delayed interrupts, and apprecia-
tion as well for other processor designers' decision not to allow interrupts
to be pipelined.  Too bad the PIC doesn't have delayed jumps [using delayed
jumps, a table lookup would be: [line numbers indicate order of execution]

TableLoc:
       movlw   data
4       movlw   data

       ...

TableLookup:
1       addlw   TableLoc
2       movwf   PC
3       goto    NextInstruction
NextInstruction:
5       [code continues here]

Note that while instruction #2 is executing, #3 is being fetched.  Then
while #3 is executing, 4 is being fetched, etc.  Note that if instruction
#4 were a jump, instruction 5 would still be executed, but the next inst-
ruction would be at the target of the #4 jump.

Note that not only would delayed jumps save execution time, but they'd also
remove the need for "retlw" to return a value (freeing up an 8-bit operand
opcode).  They might also simplify the sequencing logic EXCEPT that the
stack would have to be twice as wide [to accommodate two return addresses]
or else tricky bouncing around calls and interrupts would have to be forbid-
den.

> >        bsf GLOBAL_INTERRUPT
>
> Don't do that. RETFIE will enable GIE on exit. Enabling it early can cause
> recursive interrupts, and crash your stack.

BTW, if a normal subroutine wants to enable interrupts upon completion, is
there any objection to using RETFIE?  8051's and 6805's don't like that, but
would the PIC mind?

1995\10\14@134530 by Andrew Warren

face
flavicon
face
Ray Bellis <Ray.Bellis%.....psy.ox.ac.ukKILLspamspam@spam@UKACRL.BITNET> wrote:

>The RTCC counts at the instruction cycle frequency rather than the
>oscillator frequency.
>
> > Have I missed something? I seem to get interrupts much faster than
> >I should.
>
>Four times too fast, I think you'll find.

Ray:

Uhh... If this were his only problem, the interrupts would be happening
four times too SLOW.

-Andy

--
Andrew Warren - fastfwdspamKILLspamix.netcom.com
Fast Forward Engineering, Vista, California

1995\10\16@041938 by .Bellis%psy.ox.ac.uk%UKACRL.bitnet

flavicon
face
> Ray Bellis <Ray.Bellis%.....psy.ox.ac.ukKILLspamspam.....UKACRL.BITNET> wrote:
>
> >The RTCC counts at the instruction cycle frequency rather than the
> >oscillator frequency.
> >
> > > Have I missed something? I seem to get interrupts much faster than
> > >I should.
> >
> >Four times too fast, I think you'll find.
>
> Ray:
>
> Uhh... If this were his only problem, the interrupts would be happening
> four times too SLOW.

Whoops...  get my brain into gear...  You are, of course, correct.

Ray.

--
 Computing Officer, MRC Research Centre in Brain and Behaviour,
    Department of Experimental Psychology, Oxford University
 <http://www.mrc-bbc.ox.ac.uk/~rpb>  <EraseMERay.Bellisspam_OUTspamTakeThisOuTpsy.ox.ac.uk>

1995\10\16@042806 by s.addison%abdn.ac.uk%UKACRL.bitnet

flavicon
face
Ray Bellis <Ray.Bellis%psy.ox.ac.ukspamspam_OUTUKACRL.BITNET> wrote:

>The RTCC counts at the instruction cycle frequency rather than the
>oscillator frequency.
>
> > Have I missed something? I seem to get interrupts much faster than
> >I should.
>
>Four times too fast, I think you'll find.

Ray:

Uhh... If this were his only problem, the interrupts would be happening
four times too SLOW.

-Andy

--
Andrew Warren - @spam@fastfwdKILLspamspamix.netcom.com
Fast Forward Engineering, Vista, California

Steve Addison
University of Aberdeen
Tillydrone Avenue
Aberdeen
Scotland
UK
AB9 2TN
Tel: UK 01224 272889
Fax: UK 01224 272396

1995\10\17@073242 by att%atlas.king.ac.uk%UKACRL.bitnet

flavicon
face
Thanks for your responses on 16C84 interrupts, everyone.
This has made things much clearer.
I am still having some slight timing problems though. Getting to
grips with the fact that TMR0 counts up not down as calculated below,
was part of the solution.

I have made an LCD clock and it lost 17 secs in 2 hours.
Surely this is not the accuracy of the crystal?

> >; for a 2.4576MHz crystal, 2457600/256=9600
> >; load rtcc with 96 giving 100 interrupts/sec


> The crystal frequency is divided by four to generate the clock for TMR0, at
> that frequency I would load TMR0 with 32 to get 100 interrupts/second.
                                       ^^
                                       24 surely?

> 2.4576/4=614.4
> 614.4/256=2.4
> 2.4K/100=24      <-----
> 256-24=232=E8H


My next experiment will be to try 99 in my counter rather than 100 in
an attempt to see if the counting is inclusive i.e. 100 -> 0 = 101
counts rather than 100.

/\/\att.

1995\10\17@110103 by Jerry Ethridge

flavicon
face
{Quote hidden}

For anyone who is trying to create accurate interrupt times
on the pic, you must be aware that when you load the rtcc
with a value, the prescaler is cleared to zero. What this
means is that when the rtcc reaches 0, and your interrupt
service routine starts, the prescaler has continued to accumulate
instruction counts. Lets say that it takes a dozen or so counts
to finally get around to clearing the interrupt flag, incrementing
or decrementing your time counter, and then loading the rtcc with
your preload value. The prescaler has been accumulating instruction
ticks and will be incrementing the rtcc when it rolls over. However
when you preload the rtcc, those ticks get wiped out and reset to zero.
Every interrupt cycle loses time!

The solution is to pick your crystal frequency and your prescaler value
such that you never write to the rtcc. It should be allowed to overflow.
This way, the prescaler is never cleared to zero and no clock ticks are
lost.

Good Luck
Jerry

1995\10\17@124257 by Falstaff

picon face
> > I have made an LCD clock and it lost 17 secs in 2 hours.
> > Surely this is not the accuracy of the crystal?
> >
> > My next experiment will be to try 99 in my counter rather than 100 in
> > an attempt to see if the counting is inclusive i.e. 100 -> 0 = 101
> > counts rather than 100.

> The solution is to pick your crystal frequency and your prescaler value
> such that you never write to the rtcc. It should be allowed to overflow.
> This way, the prescaler is never cleared to zero and no clock ticks are
> lost.

You can also disable the prescaler (by assigning it to thw WDT) and
then it is possible to update the counter.  Note that you need to add
two to the value you write to the counter in this case, because the
counter is stopped for two instruction cycles after writing to it.

Frank

"Mutual respect, even if we disagree."
------------------------------------------------------------------------
Frank A. Vorstenbosch        +31-(70)-355 5241        KILLspamfalstaffKILLspamspamxs4all.nl

1995\10\18@051518 by Matthew Rowe

flavicon
face
{Quote hidden}

Not loading the rtcc at all has resulted in the accuracy I need. It
is now at +5 secs in 15 hours. Much better. Thanks.

/\/\att.

1995\10\18@134706 by Andrew Warren

face
flavicon
face
Matthew Rowe <spamBeGonemattspamBeGonespamATLAS.KINGSTON.AC.UK> wrote:

>Not loading the rtcc at all has resulted in the accuracy I need. It
>is now at +5 secs in 15 hours. Much better. Thanks.

Matt:

I'm glad your problem is solved, but 5 seconds/15 hours is really WAY
short of the accuracy you SHOULD be getting.

5/(15*3600) is...  What?  10,000 parts per million?  Even the cheapest
crystals should be about 100 times more accurate than THAT.  Perhaps
your timing calculations are off...

-Andy

--
Andrew Warren - TakeThisOuTfastfwdEraseMEspamspam_OUTix.netcom.com
Fast Forward Engineering, Vista, California

1995\10\19@162948 by Shel Michaels

picon face
In a message dated 95-10-19 06:53:48 EDT, you write:

>Matthew Rowe <RemoveMEmattspamTakeThisOuTATLAS.KINGSTON.AC.UK> wrote:
>
>>Not loading the rtcc at all has resulted in the accuracy I need. It
>>is now at +5 secs in 15 hours. Much better. Thanks.
>
>Matt:
>
>I'm glad your problem is solved, but 5 seconds/15 hours is really WAY
>short of the accuracy you SHOULD be getting.
>
>5/(15*3600) is...  What?  10,000 parts per million?  Even the cheapest
>crystals should be about 100 times more accurate than THAT.  Perhaps
>your timing calculations are off...
>
>-Andy
>
>

Well, actually, 5 parts in 54000 is a little better than 1 part in 10^4,
which is about 100 parts-per-million, as you say!!   BTW, this has been an
interesting thread, thanx all!  8^)

Shel Michaels

1995\10\20@010643 by Andrew Warren

face
flavicon
face
Shel Michaels <SbmichaelsEraseMEspam.....AOL.COM> wrote:

>Well, actually, 5 parts in 54000 is a little better than 1 part in 10^4,
>which is about 100 parts-per-million [not 10,000 parts per million]

Thanks, Shel... Guess I need to take some remedial arithmetic classes.

-Andy


--
Andrew Warren - EraseMEfastfwdspamix.netcom.com
Fast Forward Engineering, Vista, California

1995\10\26@112544 by Martin McCormick

flavicon
face
In message <RemoveMEm0t5fOu-0000nZCEraseMEspamEraseMEdc.cis.okstate.edu>, Andrew Warren writes:
>I'm glad your problem is solved, but 5 seconds/15 hours is really WAY
>short of the accuracy you SHOULD be getting.
>
>5/(15*3600) is...  What?  10,000 parts per million?  Even the cheapest
>crystals should be about 100 times more accurate than THAT.  Perhaps
>your timing calculations are off...

       You might also want to be absolutely certain that the crystal is
on frequency.  I have seen clock crystals supposedly cut for 8Mhz that were
several kilohertz off.  The mode of the crystal is also very important.
Some crystals are cut for series mode operation and others for parallel.
An NTSC color burst crystal is cut for 3.57945Mhz but will run at 3.68Mhz
or so when put in a TTL clock circuit.

       One nice thing about microcontrollers is that you could just slightly
recalculate the divisors for time-dependent operations providing the crystal
doesn't drift a lot with temperature.  I guess you could even put leap ticks
in the timing routine to tweak it a little.  I think that this is what
UNIX systems do to speed up or slow down their real-time clocks.

Martin McCormick WB5AGZ  Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group

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