Post by thread:16C84 interrupts

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.

> 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.BellisTakeThisOuTpsy.ox.ac.uk>

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

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

> Ray Bellis <Ray.Bellis%.....psy.ox.ac.ukKILLspam.....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_OUTTakeThisOuTpsy.ox.ac.uk>

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.

{Quote hidden}> 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. > 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

> > 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 KILLspamfalstaffKILLspamxs4all.nl

{Quote hidden}> From: RemoveMECdB.TSPTakeThisOuTpixie.co.za (Cobus deBeer) > >Thanks for your responses on 16C84 interrupts, everyone. > >This has made things much clearer. > >I am still having some slight timing problems though. > >I have made an LCD clock and it lost 17 secs in 2 hours. > >Surely this is not the accuracy of the crystal? > Two things that can go wrong. > > 1. When you write to the RTCC the precscaler is cleared. You must write to > the RTCC as the first instruction in your ISR. This introduces a constant > fiddle factor that you need to adjust your timing loops by. I solved this > by adding a fixed number of seconds every five minutes. Not a good solution. > > 2. If you access the RTCC in the rest of your code there is a more subtle > effect. (Read 'Many hours of debugging effort') By default the assembler > uses 'Same' as the destination for a register operation. If you want to set > the flags by using the RTCC reg as a source you should use w as the > destination. If you use Same as the destination the write to the RTCC reg > will cause a two instruction resynchronization error to occur (and the > prescaler contents is lost, if its used). We used a pic16c54 as a clock and > discovered this the hard way (no interrupt, we had to poll the RTCC). > > If you use the prescaler it is extremely difficult to load the RTCC and get > precise delays. You have to precompensate (predistort) your timing for the > two instruction cycle error caused by the write to the RTCC and this > introduces a fraction into the calculations which is extremely awkward to > handle. We tried to correct for this effect by loading the RTCC very early > in an subroutine (before any conditional code) and used different values in > the reload to get a fractional value on average. The subroutine was invoked > as soon as we detected the overflow of the RTCC. This failed as well, reason > unknown. We abandoned the 54 at this point. > > The best solution is to use a 4.096 MHz crystal and a PIC with interrupts > and to set the prescaler to generate interrupts at a convenient rate without > ever reloading the RTCC register with values. Count the number of > interrupts. If you load the RTCC with values in the ISR you still get errors > because the amount of time spent before you reach the ISR depends on the > instruction that is executing when the interrupt occurs. If a goto or call > instruction is in progress it takes longer before you reach the ISR and you > lose more cycles from the prescaler when you load the RTCC. If you count > the number of interrupts without touching the RTCC the accuracy seems to be > limited only by the crystal. > > We trim the crystal with a trimcap. Remember to measure the frequency > through a buffer which stays attached to the oscillator or the capacitance > of the leads of the frequency counter will detune the oscillator while you > are adjusting the frequency. > > Regards > > Cobus de Beer > > P.S. Please echo this to the list. It bounces from my location. 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.

In a message dated 95-10-19 06:53:48 EDT, you write: >Matthew Rowe <RemoveMEmattTakeThisOuTATLAS.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

In message <RemoveMEm0t5fOu-0000nZCEraseMEEraseMEdc.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