PDA

View Full Version : Question for Mr. Darrel Taylor and Mister-e Timer1 Reload



mikebar
- 9th July 2014, 23:50
Good morning,
I'm trying to understand the purpose of the slider "Reload (Instr. Cycle)" anyone can see into the fantastic tool named Pic MultiCalc made by Mister-e.
The reason why I'm trying to fully understand it is because I'm trying to setup Timer1 to interrupt each 100ms.
So, having a 20Mhz oscillator and using Pic MultiCalc - Timer Helper, with a "Reload Instr. Cycles" of (default) 7 and a Prescaler of 8, I've got the value of 3036 with an error of 0.001% to pre-load Timer1.
So, the Timer1 really interrupts each 100.001 ms.

I've used the very good Darrel's Instant Interrupt and it works like a charm.
BUT now here is the problem.

I need a very precise time-base, precise at least for 24 hours continuously.
Doing the math, in 24 hours are 60 * 60 * 24 = 86400 seconds.
With a 0.001% error, in 24 hours I'll have 86400 - 0.001% = 86399.136.
Doing integer rounding to show on a display, I'm loosing about 1 second per day.

I know that the "reload" is used to "compensate" the time "loose" to get to the interrupt and to reload the Timer1 register.
Playing with that slider, I've seen that I could land to 0.0% error if "Reload Instr. Cycle" is 2 or 8.

That said, the whole question is: how to estimate the correct value to be used as input for that slider? How to calculate the time needed for that task? Is the default value of 7 for what reason?

Also a little request to Mister-e: Pic MultiCalc on Windows7 have all the captions of the labels and text on the buttons that overflow the boundaries of the button or label (see picture).
The reason is of course Micro$oft bad habits. In Windows7 the standard font get bigger than XP.
Could you please increase the size of the labels and the buttons in order to fit it, or just use the Tahoma font (even a little smaller just to be sure...)
THANK YOU A LOT for your good tool and help.

Mike
7378

Demon
- 10th July 2014, 01:10
I'll let Mr E know.

Robert

Normnet
- 10th July 2014, 01:52
I would step through the interrupt with MPLAB SIM to more accurately determine the time involved for interrupt reload.
I think interrupt reload is the time or instructions used on interrupt to again restart the interrupt.


Norm

richard
- 10th July 2014, 02:08
typical timer1 reload example in asm
; All interrupts are disabled
CLRF TMR1L ; Clear Low byte, Ensures no
; rollover into TMR1H
MOVLW HI_BYTE ; Value to load into TMR1H
MOVWF TMR1H, F ; Write High byte
MOVLW LO_BYTE ; Value to load into TMR1L
MOVWF TMR1H, F ; Write Low byte
; Re-enable the Interrupt (if required)
this is 7 instructions when you include the enable/disable interrupts

another thing to consider is that your typical xtal is only accurate to about 50 parts per million , so unless your xtal is in a temperature controlled oven your expecting too much, fudging the preload is not a proper solution.

pedja089
- 10th July 2014, 02:11
One instruction to jump to interrupt, one to stop timer, 2 to load TMR1H, 2 to load TMR1L, and 1 to enable time. So that is 7 instruction. So if you need 8, just add @ NOP.
But you say that you use DT_Int, so you probably use more than 7 instruction. You need to check dissembly of hex file to count how instruction is used between int vector, and timer reload. Also, this depending on clock source for that timer. This is case if clock source is from OSC/4. If you have 32768Hz crystal, then your Reload cycle is 0. Because TMR clock is much slower than interrupt. So probably 1 clock cycle for tmr last longer then all instruction to reload timer.

Your interrupt error is 0.001%, but crystal error are probably 1-5%, so that small error won't contribute much to overall time precision.
EDIT:
richard type faster than me :)

mikebar
- 11th July 2014, 10:01
Thank you all for your answers.
Really appreciated.

Richard, you said that "fudging the preload is not a proper solution". Could you please suggest what could be a better approach to the problem?
What I "really" need is not to show an increment or a loss of even 1 second while the clock is running for EXACTLY 24 hours continuously.
Of course, if the suggested approach give good results beyond the 24 hours, that's great!

Thank you again for your help.
Regards.
Mike.

richard
- 11th July 2014, 11:20
if using the appropriate reload and preload as calculated is not keeping good time then it means you xtal frequency is slightly off (as pedja089 suggested 1 to 5 % error is to be expected) , you might try trimming the capacitors on the crystal (might take a bit of experimenting if you haven't got a frequency counter) , changing the preload + or minus 1 will probably be too coarse an adjustment . you need to keep in mind that xtal ocillators aren't atomic clocks and that the osc frequency will be temperature dependant and will drift over time .
another possibility is adding or subtracting the "error" say once per day, this was used in a slicon chip magazine project (pic toc )many years ago and was suprisingly good at time keeping .

mikebar
- 11th July 2014, 11:29
Ok, thank you Richard.
I'll try to get a freq meter and see what exactly going to the oscillator.

The chip I'm using is PIC 18F4685. What about to connect a 32768Hz watch quartz in order to feed the Timer1?
I've had no experience yet with this approach so I don't know yet what exactly I'm talking about.
All I need is to interrupt each exactly 100ms. It is possible to have that using the Timer1 feeded by an external source? And if so, using what setup?

Thanks in advance.
Regards,
Mike.

pedja089
- 11th July 2014, 11:51
10Hz interrupt is problem to derive from 32768Hz. 16Hz or 32Hz etc isn't problem. To get 1sec just count 16 interrupts, and that is all.
I posted RTC code, with external crystal, 32 interrupts per second, and it consumes less than 10uA if you put pic in sleep mode.

mikebar
- 11th July 2014, 11:59
NICE!
Where I can see that code?

Thank you.

pedja089
- 11th July 2014, 13:04
I can't find that topic...
Here is cut/paste from my code for PIC18LF14K50
DEFINE OSC 4
Define INTHAND myint ' Define interrupt handler
DEFINE NO_CLRWDT 1

OSCCON=%01010110
OSCCON2.2=0
OSCTUNE.7=1
OSCTUNE.6=1
REFCON0=0
REFCON1=0
ADCON1=0
ADCON2=0
ANSEL =0
ANSELH=0
CM1CON0=0
CM2CON0=0
SRCON0=0
SRCON1=0
WPUA=0
WPUB=0
WDTCON=0
SLRCON=0
RCON.7=0
RCON.6=0
UCON=0
IOCA=0
IOCB=0
T0CON=0
T1CON=%00001111
T2CON=0
T3CON=%00000110
INTCON=192
INTCON2=0
INTCON3=0
PIR1=0
PIR2=0
PIE1=1
PIE2=0
IPR1=0
IPR2=0
porta=0
portb=0
portc=0
trisa=255
trisb=255
trisc=255




'RTC_________________________
Seconds VAR BYTE bankA
Minutes VAR Byte bankA
Hours var byte bankA





clear

GoTo OverInt ' jump over the interrupt handler and sub
ASM
myint
movlb .0
;If PIR1.0 =1 then
BTFSS PIR1,0
GOTO End_RTC
MOVLW .252 ; TMR1H=252
MOVWF TMR1H
CLRF PIR1 ; Clear TMR1 int flag
INCF _Ticks,F
;if ticks>31 then
MOVLW .31
CPFSGT _Ticks
GOTO End_RTC
INCF _Seconds,F
CLRF _Ticks
; if seconds > 59 then
MOVLW .59
CPFSGT _Seconds
GOTO End_RTC
CLRF _Seconds
INCF _Minutes,F
;if minutes > 59 then
MOVLW .59
CPFSGT _Minutes
GOTO End_RTC
CLRF _Minutes
INCF _Hours,F
;if hours > 23 then
MOVLW .23
CPFSGT _Hours
GOTO End_RTC
CLRF _Hours
End_RTC
;Do your other stuff here
retfie FAST
ENDASM
OverInt:

Main:
@ Sleep
'program starts here 32 times in sec
goto Main
This is example for PIC's that have fast return stack, and saves and restores WREG, STATUS and BSR registers...

mikebar
- 11th July 2014, 14:12
Thank you a lot.

pedja089
- 11th July 2014, 14:40
Just one more thing that I had to deal with...
Selection of crystal and capacitors from OSC pins to ground is critical to get accurate clock. I tried one by one from 10 to 47pF, and best results are with 47pF. But that will depend from board layout and used crystal.
My suggestion is that you buy a lot of crystals, and select appropriate capacitor for it. And use that combination from now.

mikebar
- 11th July 2014, 14:51
Thank you pedja089,
looks to be a challenge...

pedja089
- 11th July 2014, 14:59
I'm glad that I could help.
Good luck:)

Normnet
- 12th July 2014, 17:43
Mike

You may wish to use a 32.768 kHz watch crystal.

Following from the PIC18F/LF1XK50 (http://ww1.microchip.com/downloads/en/DeviceDoc/41350E.pdf) datasheet:

11.6 Using Timer1 as a Real-Time Clock
Adding an external LP oscillator to Timer1 (such as the
one described in Section 11.3 “Timer1 Oscillator”
above) gives users the option to include RTC functionality
to their applications. This is accomplished with an
inexpensive watch crystal to provide an accurate time
base and several lines of application code to calculate
the time. When operating in Sleep mode and using a
battery or supercapacitor as a power source, it can
completely eliminate the need for a separate RTC
device and battery backup.

Norm

mikebar
- 13th July 2014, 19:44
Thank you Norm, that looks interesting.

What about NEVER stop Timer1 into the ISR while setting TMRL=<some preload value> and TMRH=<some preload value> in that order?
This approach will be evil or could work?

Thanks.

Normnet
- 13th July 2014, 20:08
mikebar

I'm not sure about the interrupt question.
Also see Run-Time Calibration of Watch Crystals (http://ww1.microchip.com/downloads/en/AppNotes/01155a.pdf) and Software Real-Time Clock and Calendar (http://ww1.microchip.com/downloads/en/AppNotes/01303A.pdf).

Norm

mikebar
- 13th July 2014, 20:56
Thank you Normnet,
both very interesting reading.

This will put some light. I hope :-)

Thanks again.
Mike.