Making a timer, 32.768kHz+555+DT_INT. Good idea?

[financecatalyst]

At every interrupt this is what happens in the INT routine.......so actually the number of instructions to be executed, change. So I am not sure tweaking the timer pre-load value will help.

sec=sec+1
			if sec =60 then
				sec=0
				minu=minu+1
					if minu=60 then
						minu=0
						hrs=hrs+1
							if hrs=24 then
								hrs=0
								days=days+1
									if days=8 then
										days=1
									endif
							endif
					endif
			endif

[Darrel Taylor]

Alain did a modification to the Elapsed Timer for use with a 32768hz crystal.

http://www.picbasic.co.uk/forum/show...5914#post95914

[financecatalyst]

Alain did a modification to the Elapsed Timer for use with a 32768hz crystal.

http://www.picbasic.co.uk/forum/show...5914#post95914

I am using 16F877A, as not being an expert in programming, my code is quiet long. The amended file is for PIC18 devices.

@scalerobotics -These RTC ICs are not available that easy where I am. So I am trying to stay clear of them is possible.

[cncmachineguy]

The number of instructions in your int routine does not matter as long as it doesn't take more then the amount of time to re interupt. I am guessing your int fires every sec (sec=sec+1). So there is plenty of time. What does matter is the time between the interupt firing and the time your routine is actually entered.This number may well be the difference here. What happens is this:
The interupt fires (you think 1 sec has passed or whatever your time base is)
context gets saved
PBP variables get saved (depends on how you set up DT_INT)
and finally you enter interupt routine.

The above can take from 20 - 70 fosc/4 so that could be the out of sync.

Also I don't see where you re-load the timer, Does it just free run and interupt on each rollover? If so the above information prolly IS NOT relevant. As a side note, you could update all the counters within your main code, just set a flag in the interupt so main can see one has occured.

[financecatalyst]

The number of instructions in your int routine does not matter as long as it doesn't take more then the amount of time to re interupt. I am guessing your int fires every sec (sec=sec+1). So there is plenty of time. What does matter is the time between the interupt firing and the time your routine is actually entered.This number may well be the difference here. What happens is this:
The interupt fires (you think 1 sec has passed or whatever your time base is)
context gets saved
PBP variables get saved (depends on how you set up DT_INT)
and finally you enter interupt routine.

The above can take from 20 - 70 fosc/4 so that could be the out of sync.

Also I don't see where you re-load the timer, Does it just free run and interupt on each rollover? If so the above information prolly IS NOT relevant. As a side note, you could update all the counters within your main code, just set a flag in the interupt so main can see one has occured.

There is always something new you learn in this forum.
1) Do you mean that once interrupt happens, the timer actually is still running even when interrupt routine is being executed? So, if this is the case, is it advisable to reload the timer straight away after entering the ISR instead of towards the end?
2)".....Depends on how you set up DT_INT" - Is there more than one way to use DT_INT?
The complete INT routine is below:

T1CON=%00001010 ; Timer 1 settings towards the beginning of the code
counting:
	if a=0 then
		LCDOUT $FE,2,"Day",DEC days,"  ",DEC2 hrs,":",DEC2 minu,":",DEC2 sec
	endif
	if done=1 then
		if a=0 then LCDOUT $FE,$C0,"ON",DEC2 hron,":",DEC2 minon," ","OFF",DEC2 hroff,":",DEC2 minoff
		if  hron=hrs & minon=minu then PortA.5=1
		if  hroff=hrs & minoff=minu then PortA.5=0
	endif
     		sec=sec+1
			if sec =60 then
				sec=0
				minu=minu+1
					if minu=60 then
						minu=0
						hrs=hrs+1
							if hrs=24 then
								hrs=0
								days=days+1
									if days=8 then
										days=1
									endif
							endif
					endif
			endif
TMR1L=0
TMR1H=128
@ INT_RETURN

I thought about doing what you said(set flag in the INT), but it will not be possible because when code leaves the main and enters other sub functions, the counter updates will be missed.
Upto now I was simulating my PIC on a 4MHz clock, just to check if the code was working fine. I just ran into a new problem now when I switch onto 32.768kHz as operating frequency, my simulation has just stopped. LCD screen has gone blank.

[Darrel Taylor]

There's the problem ...

TMR1L=0
TMR1H=128
@ INT_RETURN

By the time it gets all the way through the interrupt handler, another tick or two may have been counted by Timer1.
That gets lost when you reload both bytes of the Timer.

For 32768 crystals, the reload is really simple ...

TMR1H.7 = 1

And it's best to put it at the beginning of the handler.
Although in your case, the handler is fast enough it won't matter were it is.

[financecatalyst]

There's the problem ...

TMR1L=0
TMR1H=128
@ INT_RETURN

By the time it gets all the way through the interrupt handler, another tick or two may have been counted by Timer1.
That gets lost when you reload both bytes of the Timer.

For 32768 crystals, the reload is really simple ...

TMR1H.7 = 1

And it's best to put it at the beginning of the handler.
Although in your case, the handler is fast enough it won't matter were it is.

I did TMR1H.7=1, but the code is not entering the interrupt. I checked it with changing it to TMR0, it works. Am I making a mistake in setting up timer1?