Calc for timing critical offset for PIC w/interrupt

[AlGeorge]

Hi I am using the 32khz T1 internal xtal offered with some Microchip PIC types.
I figure (maybe wrong) but the internal xtal will afford me good stability at lower cost. This oscillator is div 4=8192Hz
My calculation for offset is wrong. I'm trying to achieve a 1 second interrupt, setting value T1 for the main loop. When there is a T1 interrupt, the interrupt contains the following correction code:
sub clockevent
'default timeout 8192cps/ (0.0001220703125*FFFF)=7.9998779296875
'0000/on rollover this is the default value; higher =shorter timeout 'calc=65535-8192=0xDFFF
'0xDFFF+4=0xe0ff allows for 4 cycles calling IRQ and changing offset
TMR1=0x0
TMR1H = 0xe0 '0xDF
TMR1L = 0x03 '0xFF
T1=1
end sub

However the timing over a few hours is out by about 25%. Can anyone advise where I am going wrong?
Tks vm.
Al.

 

[daviddlc]

You didn't mention the PIC model, but for some of them you need to consider the next: (From the spec document):

"If the TMRX register is written to, the increment is inhibited for the following two instruction cycles. The user can work around this by writing an adjusted value to the TMRX register"

 

[AlGeorge]

You didn't mention the PIC model, but for some of them you need to consider the next: (From the spec document):

"If the TMRX register is written to, the increment is inhibited for the following two instruction cycles. The user can work around this by writing an adjusted value to the TMRX register"

Tks; but had allowed for that in 'changing the offset' above.

 

[betwixt]

You still haven't mentioned which PIC you are using. Your calculation looks correct though, at least from a functional point of view although it's difficult to predict what extra code your compiler is adding.

Some PICs have an internal oscillator which runs at 31KHz, is it possible you are using that instead of your crystal? It caught me out once with a real-time clock that lost time at an alarming rate. the clue was that it still worked when I removed the
crystal!

Brian.

 

[AlGeorge]

You still haven't mentioned which PIC you are using. Your calculation looks correct though, at least from a functional point of view although it's difficult to predict what extra code your compiler is adding.

Some PICs have an internal oscillator which runs at 31KHz, is it possible you are using that instead of your crystal? It caught me out once with a real-time clock that lost time at an alarming rate. the clue was that it still worked when I removed the
crystal!

Brian.

Thanks I'd missed your reply. I'm using a development board with 16F690 which has an internal xtal 32.768KHz Osc.
This is from application notes: Timer1 Oscillator
A low-power 32.768 kHz crystal oscillator is built-in
between pins OSC1 (input) and OSC2 (amplifier
output). The oscillator is enabled by setting the
T1OSCEN control bit of the T1CON register. The
oscillator will continue to run during Sleep.

By changing T0 to higher frequency, T1 was effected, so I determined that bit setting Fosc/4 in T1CON was taking T0 as its source. It really is not well explained in the notes - there is mention of osc is stable bit or osc is unstable bit with no explanation of what they mean. So I'm up the creek without a paddle!
Here are my settings:
#config wdt_on, mclre_off,cpd=1,boren=0,cp_off',OSC=HP
'Oscillator control register LFINTOSC/31khz
osccon=b'00000111'
'PU=off,Intedg=Rise,TOCS=internal,TOSE=low-high,PSA 0=int 1=wdt,xxx=PSArateSelect
asm MOVLW b'01001111'
asm option
'Timer1 register
t1con=b'10001101' 'Xtal/32768/4=8192cps (1:1 prescale)'

It would seem you cant have T1 running on xtal osc and T0 running on another freerunning internal osc??

Help appreciated.
Al.

 

[betwixt]

I think you are right. On most PICs you can use two separate oscillators, one for the main clock and T1's own oscillator for other purposes, the '690 doesn't allow you to do that, probably because of the low pin count.

Regardless of the oscillator source, your calculation is still based on a 32768Hz clock which is wrong. The internal oscillator is NOT crystal controlled, it is laser trimmed to be a fairly accurate 31000Hz. So you have two choices, either adjust your calculation so you use 31KHz instead of 32.768KHz or use a higher frequency main clock and divide it using the internal timers and interrupts.

Brian.

 

[AlGeorge]

I think you are right. On most PICs you can use two separate oscillators, one for the main clock and T1's own oscillator for other purposes, the '690 doesn't allow you to do that, probably because of the low pin count.

Regardless of the oscillator source, your calculation is still based on a 32768Hz clock which is wrong. The internal oscillator is NOT crystal controlled, it is laser trimmed to be a fairly accurate 31000Hz. So you have two choices, either adjust your calculation so you use 31KHz instead of 32.768KHz or use a higher frequency main clock and divide it using the internal timers and interrupts.

Brian.

Crikey Brian, what are Microchip doing - they claim it does have an internal 32.768KHz xtal osc. Why should they do this, especially giving an erroneous frequency? If that is indicative of their product, maybe I'd be better looking to Atmel. 31khz would make sense given the anomaly experiencing here. Can you perchance let me know where you got this info?
Thanks kindly,
Alistair.

 

[betwixt]

Page 47 of the data sheet (41262E.pdf) !

I suspect you are confusing the internal 31KHz oscillator with the normal internal clock in LP mode. The idea behind LP mode is that you can connect your own 32.768KHz crystal between OSC1 and OSC2. Most miniature 32.768KHz crystals are designed for real-time clock applications such as wristwatches and battery powered clocks where the drive level is kept intentionally very low to conserve power. LP mode is such a mode.

If you aren't using those pins, you could connect your own crystal but it would also serve as the main processor clock so things might run a bit sloooowwwww.

I'm only guessing but Microchip might deliberately have made LFINTOSC 31KHz instead of 32KHz to stop people using it as a real-time clock source, it avoids all the complaints if it isn't accurate enough!

Brian.

 

[AlGeorge]

Page 47 of the data sheet (41262E.pdf) !

I'm only guessing but Microchip might deliberately have made LFINTOSC 31KHz instead of 32KHz to stop people using it as a real-time clock source, it avoids all the complaints if it isn't accurate enough!

Brian.

I hate being beaten by logic, but the PIC16f690 dev board has got me beat. Ive done all the calculations correctly, and the jolly thing is nowhere near 31khz. Its much lower around 25khz. I've been there before, and never had this amount of trouble with micros. Atmel is starting to sound more attractive!

 

[AlGeorge]

Much later. Ive grown to like the PICs they have some very weird foibles in their memory managment requirements, but bang for buck are hard to beat. Still having problems getting oscillators to play ball as Im using intosc at 125khz with a 256 prescale. You can easily calculate the offset in theory, but in practice, its quite different even allowing for clock cycles within the IRQ call. Another problem is getting nice start and shutdown (sleep) with restart at will. Stack seems to get corrupted. All in the learning curve!!

 

[betwixt]

Only the 10F, 12F and 16F use the banked memory system, the other flavors are linear and easier to visualize. The is a big advantage in banking though, it lets you access any register or RAM address with the contents of any other register. In a chip where the instruction set allows almost any source and destination for operations it makes for very efficient code usage.

I'm glad you sorted out the oscillator problem. I did PM you with some suggestions a while back which I hope were useful.

Brian.

 

[AlGeorge]

Only the 10F, 12F and 16F use the banked memory system, the other flavors are linear and easier to visualize. The is a big advantage in banking though, it lets you access any register or RAM address with the contents of any other register. In a chip where the instruction set allows almost any source and destination for operations it makes for very efficient code usage.

I'm glad you sorted out the oscillator problem. I did PM you with some suggestions a while back which I hope were useful.

Brian.

Hi yes I got ur PM and thought I had sent u the code but dont recall a reply. Its not important now though, as I've sussed out most of whats going on.
With timing, there seems to be a conundrum of operations you need to deal with. I'd thought it was an exact science but so far havent found that.
EG for internal osc you may have:variables
Fosc>TemperatureVar>TimerRegister>Prescaler>IRQ>irqloopdelays>possible dropping of some timer IRQ times due to hardware switching off IRQ for other operations.
Is that about right?
Tks,
Al.

 

[betwixt]

Yes, you sent the code and I replied with some suggestions that might fix it, perhaps the email got lost in the net somewhere. I can dig it out of my archive if you need it.

You are right about the oscillators but the problem isn't severe. The internal oscillator is factory calibrated at (I think) 25C and is quite stable but inevitably there will be some frequency drift if the temperature changes. For most purposes you can ignore it though.

Interrupts are not so much of a problem as the PIC architecture allows interrupts to be processed when time allows provided each is processed before it occurs again. When entering an interrupt routine, the global interrupt flag is automatically switched off to prevent another interrupt occurring while one is already being dealt with, BUT, the flags for other interrupts are still set. This means that as one interrupt finishes and returns (RETFIE) the next pending one will immediately trigger the interrupt system again. Under normal circumstances, an interrupt service routine will be very short so there is plenty of time for all pending ones to be dealt with without slowing the main program down significantly.

I've been working with PICs since the PIC1650 came out about 20 years ago and I don't think I've ever lost an interrupt yet!

Delays due to the instructions entering and leaving loops are inevitable but they normally only influence software delay routines and they are predictable so you can program around them quite easily. Timer interrupts are hardware generated so although there may be delays between the interrupt occurring and your software responding, the interrupt itself is always on time.

Brian.

 

[AlGeorge]

Hi I checked my PM and it was not there. Maybe Id used a disposable email address dont know. Can you PM code to me if possible?

Sounds lke we are of similar vintage. Last time I did any C was a few years ago with 8051/89C55WD which I liked a lot. If you like, do a Google on Alistair George 8051 you will see I was very active in the forums with my design back then.

Unfortunately, the 8051 is nowhere near as price competitive as the PIC and I'd understood by PIC salesmen that 8051 used a lot more current than PIC which is not true, there is an exceptionally low current 8051. Never mind, the PIC is nice. I'd also being toying with Atmel Tiny series, but their leadtime, and response to service requests was so abysmal that they blew it.
Cheers,
Al.

 

[betwixt]

Even more coincidence:

1. our web sites are built with the same program
2. we both run holiday homes

I've never programmed 8051s though, I have used it's cousins, the 8035, 8041, 8042, and 8049. I'm sure I still have some in my 'junk box' but they are probably buried in cobwebs by now.

I didn't actually provide you with code but several suggestions to make it more accurate and fix your 15 hour day problem! I'll dig the original out of the archive and send it again tomorrow. It's a pity we are on almost exactly opposite sides of the World, a Skype chat might be useful.

Brian.

 

[AlGeorge]

I didn't actually provide you with code but several suggestions to make it more accurate and fix your 15 hour day problem! I'll dig the original out of the archive and send it again tomorrow.
Brian.

Hi Brian. Still did not get the code. Hope you have had an excellent Christmas. Cheers,
Alistair.