You will probably find that you are not accounting for the execution time of the rest of your code, hence it runs slow. I have run RTC code using the timer and a 3.568Mhz xtal and got no drift over many days. unless your code is very simple/plain path then you need a regular interrupt to keep track of time properly. cya, Andrew... > -----Original Message----- > From: Dean Biddle [SMTP:d.biddle@MAILBOX.UQ.EDU.AU] > Sent: Thursday, March 09, 2000 1:39 PM > To: PICLIST@MITVMA.MIT.EDU > Subject: Why doesn't 1+1=2? > > Hi, > > The timing of the code (infamed by Myke Predko?) at the end of this mail > simulates to the nearest µsecond using MPLAB. However, when executed on a > P16F84 using a 4 MHz 3 pin resonator marked > [4.00 (M x], I loose about 1 second every 10 minutes. Same occurs at > different supply voltages between 3.5 and 6V. > > Presumably this is because of the +/-0.5% error (or greater) in the > crystal > and my too frequent reliance on 1 microsecond being accurate? > > If this magnitude of error is expected for this type of delay code, could > someone please point me to another technique (e.g. TMR0 + prescaler) with > accurate equations which allow accurate pre-calculation of the interval. > > I'm using RA5 hence can't use a 32k crystal for timing. Is there any > other > external timing techniques (sleep or not) for a P16F84? > > Is the life of a microcomputer reduced if it is allowed to continuously > loop > compared to a sleeping chip? > > ; > ; Delay rountine for P16F84 using 4 MHz crystal. Sum individual > expressions > for total and add > ; extra cycles where required > ; > MOVLW 0X00? > MOVWF COUNT1 > MOVLW 0X00? > MOVWF COUNT2 > MOVLW 0X00? > MOVWF COUNT3 > MOVLW 0X00? > MOVWF COUNT4 > DECFSZ COUNT4,F ;2+(3*1)*(COUNT4-1) > GOTO $-1 > DECFSZ COUNT3,F ;2+(3*255+3+2)*(COUNT3-1) > GOTO $-3 > DECFSZ COUNT2,F ;2+(3*255*256+5*255+3+2+2)*(COUNT2-1) > GOTO $-5 > DECFSZ COUNT1,F ;2+(3*255*256*256+5*255*256+7*255+3+2+2+2)*(COUNT1-1) > GOTO $-7