Counting Timer0 and Timer1 overflows without any interrupt handler

[dw_picbasic]

Ah!
Thats right!!...sorry... I forgot the Timer0 is an 8 bit register.
I slipped on that one :-/

Thanks!

[dw_picbasic]

Can I pose another question:
Lets say that the frequency that is being measured within the 1 second gate period is 301234hz
Is it the case that the value that will be captured within T0overflow, RESULTS.[bit16-31] = (301234/256)?
Which (in integer form) would resolve to 1176 overflows of the Timer0 8 bit register?
And then the remainder value of 178, which remains within TMR0 will be loaded into T0value RESULTS.[bit8-15]?
Thanks!!
Duane

[Darrel Taylor]

The prescaler divides by 256, and TMR0 divides by 256.
So the overflows only happen every 65536 counts.

With a frequency of 301234, there will only be 4 overflows, with 39090 remaining.
That's 152 in TMR0, and 178 in the prescaler.

Another way to look at it is to convert the Frequency to a HEX number
#301234 = $4:98B2

Now it's easy to see that there will be 4 overflows, TMR0 will have $98 = 152, and the prescaler has $B2 = 178.

HTH

[dw_picbasic]

Thanks Darrel,
I didn't see the prescaler settings in setup code.
I see "PSA [OPTION_REG.3] set to 0 which sets the prescaller from the WDT to Timer0
But I don't see any settings for OPTION_REG.0, 1 and 2.
Are they there in the code and I missed them?
Thanks!!
Duane

[Darrel Taylor]

On power-up, the default value of OPTION_REG is %11111111.
Which means the prescaler is already set to 1:256.
There is no need to set it again in the code.

[HenrikOlsson]

Hi Duane,
If you look up OPTION_REG in the datasheet, you'll find that it defaults to "all ones", $FF, 255 whichever way you want to look at it.
This means that the prescaler ratio, when assigned to TMR0 defaults to 1:256 - so no need to change it.

/Henrik.

EDIT: Damn, you're fast today Darrel!

[dw_picbasic]

Sweet!!
Thanks!
I had a suspicion that was the case, but I have an old habit of wanting to make sure in the code.
This gives the old dog a new trick!! :-]

[Rufinus]

The prescaler divides by 256, and TMR0 divides by 256.
So the overflows only happen every 65536 counts.

With a frequency of 301234, there will only be 4 overflows, with 39090 remaining.
That's 152 in TMR0, and 178 in the prescaler.

Another way to look at it is to convert the Frequency to a HEX number
#301234 = $4:98B2

Now it's easy to see that there will be 4 overflows, TMR0 will have $98 = 152, and the prescaler has $B2 = 178.

HTH

Hello Darrel,

found your excellent example and i would like to build the same counter based on PIC16F870. From your above post i understand, that with prescaler 256 minimum measured frequency is 65536Hz, otherwise TMR0 will not overflow, or am i wrong? To measure lower frequencies i would have to change the OPTION_REG bits 2-0 , which will set prescaler to 1:2?

P.S. My target measurement range is 1 HZ - 1 MHz.

[HenrikOlsson]

Hi Rufinus,
Sadly Darrel has passed away and is no longer with us.

I'll try to answer your qeustion.
It's correct that with a prescaler of 1:256 the timer will only overflow every 65536 "tick" but that doesn't prevent Darrels code from measuring frequencies lower than 65536Hz. As I wrote in a previous post the two most significant bytes of the 4 byte result will contains the number of overflows (ie "units" of 65536Hz), the next byte is the TMR0 value which is in units of 256Hz and the least significant byte is what's stored in the prescaler, in units of 1Hz. All provided your "gate time" is precisely 1Hz of course.

So, if your input frequency is 125Hz then after the one second gate time there will be 0 overflows, 0 counts in TMR0 and 125 counts in the prescaler. The prescaler isn't readable so the code then "manually" pulses the counter input to find out how many pulses is needed before the prescaler overflows and TMR0 increases. In this example it would take 131 (125+131=256) which, when stored in a byte and negated "becomes" the value 125.

Changing the prescaler won't help you measure the low frequencies. The only way to gain resolution at the lower end is to increase the gate time, count for 2, 5, 10 or whatever seconds instead of 1 and adjust the calculations accordingly.

/Henrik.

[Rufinus]

Holy Christ, i had no idea! So sorry about that.. R.I.P Darrel..

Thanks for fast answer Henrik, but please let me pull my thought together before i can understand your explanation..

[Rufinus]

Hi Rufinus,
Sadly Darrel has passed away and is no longer with us.

I'll try to answer your qeustion.
It's correct that with a prescaler of 1:256 the timer will only overflow every 65536 "tick" but that doesn't prevent Darrels code from measuring frequencies lower than 65536Hz. As I wrote in a previous post the two most significant bytes of the 4 byte result will contains the number of overflows (ie "units" of 65536Hz), the next byte is the TMR0 value which is in units of 256Hz and the least significant byte is what's stored in the prescaler, in units of 1Hz. All provided your "gate time" is precisely 1Hz of course.

So, if your input frequency is 125Hz then after the one second gate time there will be 0 overflows, 0 counts in TMR0 and 125 counts in the prescaler. The prescaler isn't readable so the code then "manually" pulses the counter input to find out how many pulses is needed before the prescaler overflows and TMR0 increases. In this example it would take 131 (125+131=256) which, when stored in a byte and negated "becomes" the value 125.

Changing the prescaler won't help you measure the low frequencies. The only way to gain resolution at the lower end is to increase the gate time, count for 2, 5, 10 or whatever seconds instead of 1 and adjust the calculations accordingly.

/Henrik.

Ok, now i think i got it. It was the last step (remainder in prescaler), which I could not understand.
But it would mean then, that the smallest frequency, which I could measure in one second is 256 Hz.
For lower frequencies i would have to increase sampling time.

Lets say, it is very rare, that one needs to measure frequency below 20 Hz in normal application.
That would mean, that in 1 second sampling time there will be 20 counts in prescaler, which in turn means we would have to provide 256-20=236 counts more to overflow it. So, 236 remaining counts divided by 20 gives us 11.8 seconds! We will need to increase sampling time to 11.8 seconds, in order to measure 20 Hz frequency, or ?!

I think I will have to think about some other algorithm to measure frequencies below 256 Hz, maybe with COUNT command or so. Precision might suffer, but that would be a reasonable compromise. Target would be to keep the one second sampling rate over whole range.

Thanks again Henrik, for explaining.

[Rufinus]

Or "manual counting" in your example is the part of the code, which fills out the precaler by toggling PSCLKOUT for 3uS instead of using actual measured frequency to increase the count? Than it schould be significantly faster, than 11.8 seconds. In fact, it should be just very sligtly over 1 second for 20 Hz, or?