[solved] Wrong calculation for timers?

[LytseFlap]

Why is the only thing of the PIC that gives me a headache called timer?

Theory:
Timers are filling up their own registers. This can be a 16 bit or a 8 bit long value. Each increment takes ((Fosc/4)/ some activated prescaler/interrupt prescaler)^ -1 seconds. By prefilling the register the time wille be shorted. Filling up the register quarter full wil shorten the time with a quart.

So here I go.
Fosc 10 MHz (crystal).
Needed time for an overlow is 65 us.
Filling up speed is 2,5 MHz.
Every (1/2,5) * 10^-6 seconds -> 1/2,5 us the value of the register will be increased by one.

65 us / 1/2,5 us -> 65 us * 2,5 us = 162,5. Let's say it takes 65 us for 163 increments.


I want to use Timer1, this is a 16 bits register. The maximum value is 65535. I only use 163 of 65535, so the register will be set up with the value of 65535 minus 163 gives 65372.

CCS

[Ttelmah]

A couple of comments first.
The timer actually 'overflows', at 65536 (wraps back to zero), so this is the value you should use as the basis of your calculation, rather than 65535.
There is a problem that may hit you if your processor tries to do anything else, which is the latency, and overhead associated with the interrupt. This may well make the approach you are showing 'impractical' in a system doing anything else...
Aside from the first comment, your calculation is right. If you are seeing too short a time (half the expected value), then it would suggest that either the system you are using to measure the pulse is 'out' by a factor of two, or that the crystal frequency is really 20MHz, not 10MHz. This can happen with some high gain crystals, where the oscillator on the PIC, produces sufficient drive, for the crystal to run on the next overtone above it's normal design frequency. Hence I'd start with a really simple 'software' test, of setting a pin, generating a delay for a known time (1mSec say), clearing the pin, and repeating. Time this, and verify that the processor crystal is generating the expected frequency.
Now, on the 'secon' comment, you would get a far more repeatable pulse, with less processor overhead, by taking advantage of the CCP module, to clear the timer (CCP_COMPARE_RESET_TIMER), and setting CCP1 to 162, will give a more reliable output stream.
So I'd say that your current problems are being caused by something else in hardware, rather than a calculation problem over the timer, but the approach you show, will result in a lot of processor overhead, and may perhaps be better approached using the CCP module.

Best Wishes

[LytseFlap]

Thanks for the info. It stimulated me of another possible problem. The crystal is oke (with some difference ofcourse) and the IC is not dividing the signal by two.
So I asked myself; is the scope I use working correctly?
And indeed, he wasn't. I took a second scope and this one gives a value of 75 microseconds. Not 100% correctly but a far more correcter value.

Then I made a second test. This one with the usage of use delay_us(50). The first scope gives a value around 24 us and the second one a value around the 50,5.

Then I discovered that de CAL button of the first scope is broken. It's not connected to the scope. You can easily pull it out of the scope!

Conclusion : The scope has got an error around the 2.

Shame on me, but I'm a student. ;)

About the CCP. I'm only using this snippet to set the timer correctly. Then I implement it in the big source. The orignal signal has to generate an output like this: 1001 when inactive; 0001 when active. Long story, I'm regenerating a joystick of an electic wheelchair.

So, now to regenerate the signal from the joystick with a good working scope!

[Ttelmah]

Glad you have found it.
In a sense, the good thing was that what you posted, put you in the position of having 'confirmation', that your signal should not be out by a factor of two, unless something else was wrong, so you went 'looking', and found it. As such, you were in a situtation that _everybody_ here, will either have met in the past, or will run into in the future... :-)

Best Wishes

[Kenny]