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

Hi, I am trying to make a timer where you can store 7 days of ON/OFF times. I have simulated the code & it works fine. The problem is keeping the time right. If I use 32.768kHz as an Oscillator + DT_INT on timer 1, very soon the time goes out of sync, because of the instructions in the main program & also in INT routine.
I am considering using DT_INT on external INT, and generate 1 sec pulses on PortB.0 using 555 timer IC.
I would like to know if someone has had the same thought or if there is any other cheaper way to overcome this problem, I don't want to go for expensive RTC ICs.

I think you may just need to adjust the pre load for the timer. If you have access to an O-scope, toggle an output in the INT routine so you can see the actual timing.

Once the preload is correct, you should find the time is spot on.

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.

Code:

---

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

---

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

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

Quote:

---

Originally Posted by financecatalyst

.... or if there is any other cheaper way to overcome this problem, I don't want to go for expensive RTC ICs.

---

How about cheap RTC ICs? The MCP79410 RTCs are under $1.00 in singles. I got a few samples but have not tried them yet. http://www.microchip.com/en_US/techn...ock/index.html Downside is soic is as big as it gets, no dips. Cheapest from Microchip Direct: http://www.microchipdirect.com/Produ...words=mcp79410

Features:
• Real-Time Clock/Calendar (RTCC), Battery
Backed:
- Hours, Minutes, Seconds, Day of Week, Day,
Month and Year
- Dual alarm with single output
• On-Chip Digital Trimming/Calibration:
- Range -127 to +127 ppm
- Resolution 1 ppm
• Programmable Open-Drain Output Control:
- CLKOUT with 4 selectable frequencies
- Alarm output
• 64 Bytes SRAM, Battery Backed
• 1 Kbits EEPROM (128x8):
- 8 bytes/page
- Block/sector write protection
- Protect none, 1/4, 1/2 or all of array
• Separate 64-Bit Unique ID:
- User or factory programmable
- Protected area
- EUI-48™ or EUI-64™ MAC address
- Custom ID programming
• Automatic VCC Switchover to VBAT Backup
Supply
• Power-Fail Time-Stamp for Battery Switchover
• Low-Power CMOS Technology:
- Dynamic Current: 400 A max read
- Dynamic Current: 3mA max EEPROM write
- Battery Backup Current: <700nA @ 1.8V
• 100 kHz and 400 kHz Compatibility
• ESD Protection >4,000V
• More than 1 Million Erase/Write Cycles
• Packages include 8-Lead SOIC, TSSOP, 2x3
TDFN, MSOP
• Pb-Free and RoHS Compliant
• Temperature Ranges:
- Industrial (I): -40°C to +85°C.

Quote:

---

Originally Posted by 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

---

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.

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.

Thanks for posting up about the rtc, I'm digging it.
Happy Holidays.....

Quote:

---

Originally Posted by scalerobotics

How about cheap RTC ICs? The MCP79410 RTCs are under $1.00 in singles. I got a few samples but have not tried them yet. http://www.microchip.com/en_US/techn...ock/index.html Downside is soic is as big as it gets, no dips. Cheapest from Microchip Direct: http://www.microchipdirect.com/Produ...words=mcp79410

Features:
• Real-Time Clock/Calendar (RTCC), Battery
Backed:
- Hours, Minutes, Seconds, Day of Week, Day,
Month and Year
- Dual alarm with single output
• On-Chip Digital Trimming/Calibration:
- Range -127 to +127 ppm
- Resolution 1 ppm
• Programmable Open-Drain Output Control:
- CLKOUT with 4 selectable frequencies
- Alarm output
• 64 Bytes SRAM, Battery Backed
• 1 Kbits EEPROM (128x8):
- 8 bytes/page
- Block/sector write protection
- Protect none, 1/4, 1/2 or all of array
• Separate 64-Bit Unique ID:
- User or factory programmable
- Protected area
- EUI-48™ or EUI-64™ MAC address
- Custom ID programming
• Automatic VCC Switchover to VBAT Backup
Supply
• Power-Fail Time-Stamp for Battery Switchover
• Low-Power CMOS Technology:
- Dynamic Current: 400 A max read
- Dynamic Current: 3mA max EEPROM write
- Battery Backup Current: <700nA @ 1.8V
• 100 kHz and 400 kHz Compatibility
• ESD Protection >4,000V
• More than 1 Million Erase/Write Cycles
• Packages include 8-Lead SOIC, TSSOP, 2x3
TDFN, MSOP
• Pb-Free and RoHS Compliant
• Temperature Ranges:
- Industrial (I): -40°C to +85°C.

---

Quote:

---

Originally Posted by 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.

---

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:

Code:

---

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.

There's the problem ...

Code:

---

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

Code:

---

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.

Quote:

---

Originally Posted by Darrel Taylor

There's the problem ...

Code:

---

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

Code:

---

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?

Quote:

---

Originally Posted by financecatalyst

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?

---

T1CON=%00001010 ; Timer 1 settings towards the beginning of the code

You might want to turn the Timer ON.

Sorry Darrel, I put Timer1 On now, but the problem is still there.

T1CON=%00001011
Further investigation revealed that this bit is the problem. Looks like in the simulation software I need to look into crystal setup again. I tried with this bit cleared and it worked fine.

With that bit cleared, Timer1 is clocked from FOSC/4 instead of the Timer1 oscillator.

What simulator are you using?

I am using Proteus 6.9 (which I am also new to).
Screenshot of the setup is attached.
It is not working with external clock settings on timer 1
I tried changing capacitor values, crystal values but no response.

Hmmm, apparently the Timer1 oscillator doesn't work.

Instead ... exclude the crystal and caps from the simulation, and add a clock generator on the T1OSI input.

http://www.pbpgroup.com/files/Generator.JPG

Set it up like this.

http://www.pbpgroup.com/files/Clock.JPG

Thank you so much for helping me reaching near the completion this project.
Adding the external clock as per the above image, has not solved the problem, I will need to check it on a real hardware from now on. Few last questions please:
1) Please explain my earlier question, that as soon as the interrupt happens, what exactly is happening, my understanding upto now says (please correct me if I am wrong):-
a) Few registers are saved [Which takes some time - Now, I have 15 byte variables, 2 Bit variables & 4 alias for 4 port pins - How do I calculate the exact delay & come up with a value to load into timer1 so I get perfect 1 sec intervals] (my pic is also running on 32.768kHz)
b) As soon as the first instruction is executed in the ISR, does timer1 keeps the value 0 in it untill ISR is executed in full OR it starts incrementing straightaway regardless if it is in ISR or main code. The latter makes more sense to me as I think thats why you advised to reload it as a first instruction in the ISR.

Please help me find answers to the above and hence get perfect 1 sec intervals.

The timer continues counting no matter what the program is doing.

And yes, it does take time to save all the PBP system registers before it gets to the interrupt handler.
But that has no affect on the reload value.

Your problem before was that you were overwriting the timers value with TMR1L = 0.

Here is the program I used with the Digital Clock Generator shown above, and it does keep perfect time.

Code:

---

;--------------------------------------------------------------
wsave        VAR BYTE $70 SYSTEM
INCLUDE "DT_INTS-14.bas"    ; Base Interrupt System
INCLUDE "ReEnterPBP.bas"    ; Include if using PBP interrupts

ASM
INT_LIST  macro    ; IntSource,    Label,  Type, ResetFlag?
        INT_Handler  TMR1_INT,  _Clock,  PBP,  yes
    endm
    INT_CREATE              ; Creates the interrupt processor
ENDASM

@  INT_ENABLE  TMR1_INT    ; enable external (INT) interrupts
;--------------------------------------------------------------
Sec          VAR BYTE
Minute      VAR BYTE
Hour        VAR BYTE
SecChanged  VAR BIT

;--------------------------------------------------------------
ADCON1 = 7
TMR1L = 0
TMR1H = $80
T1CON = %00001011
PAUSE 250
LCDOUT $FE,1

;--------------------------------------------------------------
Main:
    IF SecChanged THEN
        SecChanged = 0
        LCDOUT $FE,$80, DEC2 Hour,":",DEC2 Minute,":",DEC2 Sec
    ENDIF
GOTO Main

;--------------------------------------------------------------
Clock:
    TMR1H.7 = 1
    Sec = Sec + 1
    SecChanged = 1
    IF Sec = 60 THEN Sec = 0 : Minute = Minute + 1
    IF Minute = 60 THEN Minute = 0 : Hour = Hour + 1
    IF Hour = 24 THEN Hour = 0
@ INT_RETURN

---

Thank you very much Darrel. Surely learnt something new in this project.

So, even when variables are getting saved before entering ISR, only lower bit of timer one is getting incremented in that time. Previously I was resetting it again to '0', which I shouldn't do and let it increment to keep it in sync. BUT it does not reach to higher bit of timer1 in such short time, so we only put TMR1H.7=1, which keep everything simple and in sync.

That is why you also said that in my code it does not matter if that statement is in the beginning of the code or end, because the increment does not reach that higher value even after executing some statements in my ISR.

Got it now (Atleast I hope I have this concept cleared FOREVER)

Excellent!

Now you really have "Got It". :)
And described it well.

Cheers,

I made my circuit on my breadboard. It works kind of OK (INT are longer than 1 sec intervals) with TICON=%00001111 the clock still keeps incrementing even when I take out the 32KHz crystal from RC0-RC1.

The clock stops with
TICON=%00001011, seems Interrupts stop happening with this setting. Can someone please put some light on why this could be happening?

Anyone? Should I start a new thread with this problem?

Maybe??
Do you have the Watchdog turned off?

Quote:

---

Originally Posted by mackrackit

Maybe??
Do you have the Watchdog turned off?

---

Observations:
Watchdog is OFF.I just tried it with 4MHz oscillator, everything works fine. Intervals are 1 sec as expected. I took out the 32kHz crystal while PIC was working, it suddenly increased the speed of counting seconds(I WAS EXPECTING IT TO STOP ENTERING IN ISR) i.e. interrupts started happening a little faster. I inserted the crystal back in, the speed became ideal i.e. 1 sec interrupts.
Two questions now please:
1) Why didn't the Interrupts Stopped when I took the crystal out?
2) Why things get slow when I use 32768 Hz crystal as an oscillator for the PIC as well as the timer? 4MHz for PIC increases the current consumption to 2.5mA which is criminal when running on batteries.

Are you saying that you have two 32768 crystals?
The CPU will be running at 8192 hz (FOSC/4).

You might as well run the timer off the main clock then, (saves the power used by the timer1 oscillator), and gives the same accuracy.
T1CON = 1
Reload TMR1H with $11100000, and definitely put it First in the handler.

And change the LCD timing because PBP still thinks it's running at 4mhz.

DEFINE LCD_COMMANDUS 17
DEFINE LCD_DATAUS 1

Quote:

---

Originally Posted by Darrel Taylor

Are you saying that you have two 32768 crystals?
The CPU will be running at 8192 hz (FOSC/4).

You might as well run the timer off the main clock then, (saves the power used by the timer1 oscillator), and gives the same accuracy.
T1CON = 1
Reload TMR1H with $11100000, and definitely put it First in the handler.

And change the LCD timing because PBP still thinks it's running at 4mhz.

DEFINE LCD_COMMANDUS 17
DEFINE LCD_DATAUS 1

---

With recommended settings above i.e. TMR1H with %11100000 can someone please help me understand how many seconds or minutes the clock will be out after a month or an year because it gives me 1.00069 Hz frequency for Timer1

That would gain about 2.5 seconds per hour, which is not good.

Have you set LP oscillator mode in your configs?
Since it worked for you at 4mhz, it's probably set to XT and over driving the crystal.

How are you measuring that frequency?
Is it a high quality frequency counter?
Accurate measurements of low frequencies can be difficult, with large errors.

Quote:

---

Originally Posted by Darrel Taylor

That would gain about 2.5 seconds per hour, which is not good.

Have you set LP oscillator mode in your configs?
Since it worked for you at 4mhz, it's probably set to XT and over driving the crystal.

How are you measuring that frequency?
Is it a high quality frequency counter?
Accurate measurements of low frequencies can be difficult, with large errors.

---

Yes, I change it to LP when driving it with 32 kHz and your advised process to run timer 1 from internal clock (loading TMR1H=%11100000) & XT when 4MHz (with 32kHz attached 4 TMR1).

For frequency, unfortunately I am not equipped with those luxuries, I am just using an Timer Calculator I found in the Forum only. Screenshot attached.

Even with loading 32768 into TMR1, the calculator shows the interrupts 1.00027 Hz.
This is just to seek clarification, it is unlikely that I will be able to use 4MHz for OSC & 32kHz for TMR1.

That calculator is wrong.

Here's the way it works ...
The main OSC is running at 32768 hz.
The CPU is running a 8192 hz (32768 / 4).

Timer1 is loaded with the highbyte of 57344 and will overflow at 65536.
65536 - 57344 = 8192

So the timer overflows exactly 1.0000 seconds every time (depending on the crystal tolerance).

Quote:

---

Originally Posted by Darrel Taylor

That calculator is wrong.

Here's the way it works ...
The main OSC is running at 32768 hz.
The CPU is running a 8192 hz (32768 / 4).

Timer1 is loaded with the highbyte of 57344 and will overflow at 65536.
65536 - 57344 = 8192

So the timer overflows exactly 1.0000 seconds every time (depending on the crystal tolerance).

---

OK, I am now running everything as advised. I synchronised the time with my phone last night. Today appx after 12 Hrs, the phone is appx 6 seconds ahead than the clock. What could be the possible problem?

Financecatalyst, I would first check that the crystal is indeed operating at the proper frequency... (Frequency counter)

Dave Purola,
N8NTA

With Timer1 you'll normally want to stop it, add in your reload value to the existing count (+ whatever time is involved for instructions after stopping it), then restart it. This can throw you off if you're not right on.

This could be a lot easier with Timer2 since it gets automatically reset - so you don't need to mess with reloading the timer.

Here's an example that keeps spot-on with my PC time clock to the second;

Code:

---

DEFINE OSC 4  ' using a 4MHz crystal
 
' setup vars for clock
Time    VAR BYTE  ' accumulates TMR2 to PR2 match counts
Minutes VAR BYTE  ' minutes
Hours  VAR BYTE  ' hours
Seconds VAR BYTE
Match  VAR PIR1.1 ' TMR2 to PR2 match interrupt flag bit
 
CMCON = 7          ' disable comparators
INTCON = 0        ' not using interupts. Just monitoring int flag bits
 
Time = 0          ' clear TMR2 to PR2 match counter
Hours = 11        ' set clock starting hour here
Minutes = 52      ' set clock starting minutes here
Seconds = 0
 
PR2 = 249          ' 249 +1 extra cycle for TMR2 reset = 250*5*16*1uS=20mS
Match = 0          ' clear match flag
 
' setup & start TMR2
T2CON = %00100110  ' 1:5 postscale, 1:16 prescale, TMR2 on
 
Main:
  ' every 20mS the TMR2IF flag is set, and this routine is entered.
  ' Plenty of time to do other stuff.
  IF Match THEN          ' has TMR2 matched PR2? (should happen every 20mS)
      Match = 0          ' yes. clear TMR2 to PR2 match flag bit
      Time = Time + 1    ' increment 20mS count   
      IF Time = 50 THEN  ' 50 x 20mS = 1 second
        Time = 0        ' show time in 1 second intervals
        HSEROUT ["Time = ", DEC2 Hours,":",DEC2 Minutes,":",DEC2 Seconds,13,10]
        Seconds = Seconds + 1
      ENDIF   
      IF Seconds = 60 THEN    ' has 60 seconds passed?
        Seconds = 0
        Minutes = Minutes + 1 ' increment minute count
        IF Minutes = 60 THEN  ' have 60 minutes passed?
            Minutes = 0        ' yes. roll-over minutes 00
            Hours = Hours + 1  ' update hours
            IF Hours = 24 THEN Hours = 0 ' roll-over hours from 24 to 00
        ENDIF ' end IF Minutes = 60               
      ENDIF    ' end IF Seconds = 60
  ENDIF      ' end IF Match
 
  GOTO Main
  END

---

Of course you'll want a 4MHz osc that's right on the money if you need really precise timing.

Quote:

---

Originally Posted by Bruce

Of course you'll want a 4MHz osc that's right on the money if you need really precise timing.

---

He's using a 32768 crystal for the primary OSC.

Not a great idea with PBP since it doesn't support a 32,768 primary osc, but it could still work with;

Load PR2 with 31. Set TMR2 prescaler & postscaler to 16. That would give you 1 second per match period.

Try this with your sim program;

Code:

---

' setup vars for clock
Time    VAR BYTE  ' accumulates TMR2 to PR2 match counts
Minutes VAR BYTE  ' minutes
Hours  VAR BYTE  ' hours
Seconds VAR BYTE
 
Match  VAR PIR1.1 ' TMR2 to PR2 match interrupt flag bit
 
CMCON = 7          ' disable comparators
INTCON = 0        ' not using interupts. Just monitoring int flag bits
 
Time = 0          ' clear TMR2 to PR2 match counter
Hours = 11        ' set clock starting hour here
Minutes = 52      ' set clock starting minutes here
Seconds = 0
 
PR2 = 31          ' 31 +1 extra cycle for TMR2 reset = 1/8192*256*32=1 second
Match = 0          ' clear match flag
 
' setup & start TMR2
T2CON = %01111110  ' 1:16 prescale, 1:16 postscale, TMR2 on
TRISB.0 = 0
PORTB.0 = 0
 
Main:
  ' every 1S the TMR2IF flag is set, and this routine is entered.
  ' Plenty of time to do other stuff.
  IF Match THEN          ' has TMR2 matched PR2? (should happen every 20mS)
      Match = 0          ' yes. clear TMR2 to PR2 match flag bit
      TOGGLE 0            ' toggles RB0 at ~1 second intervals
      Seconds = Seconds + 1
      IF Seconds = 60 THEN    ' has 60 seconds passed?
        Seconds = 0
        Minutes = Minutes + 1 ' increment minute count
        IF Minutes = 60 THEN  ' have 60 minutes passed?
            Minutes = 0        ' yes. roll-over minutes 00
            Hours = Hours + 1  ' update hours
            IF Hours = 24 THEN Hours = 0 ' roll-over hours from 24 to 00
        ENDIF ' end IF Minutes = 60               
      ENDIF    ' end IF Seconds = 60
  ENDIF      ' end IF Match
 
  GOTO Main
  END

---

Thanks everyone.
@Bruce - You are not using DT_INT in your sample code. Would it be possible to use these settings when using DT_INT. Because what you are doing in main, in my code it is done in ISR, because code also has sub_routines to look after, it will not stay in main all the time.

Yes. They can definitely be used with DT_INTs. I was just trying to show you that with Timer2/PR2 match you don't need to reload any timer values. Timer2 interrupts for sure work with DT_INTs.

Any interrupt the PIC has should.

Thank you everyone. I really appreciate the intention to help. But I think I have to give up on using timer for my purposes. Luckily I laid my hands on few DS1307, got them only for £0.55 each which is surely not what I expected them to cost (Everywhere I saw they were min £2-£2.50). They will be with me in few days time. Until then I will be using Proteus.

For this I will start a new thread. Thanks again for the above answers.