timer inaccuracy?

[John H. Edvardsen]

I am trying to measure the pulsewidth of an 55KHz pulse using timer0 (16F84A), this works fine....but what I don't understand is why the numbers jump so much. (from 69 to 87).

What I'm trying to achieve is a filter, which detects 55KHz pulses in very short time. ( < 50us )

Any ideas?

Cheers,

J.H
___________________________
This message was ported from CCS's old forum
Original Post ID: 11882

[PCM programmer]

:=I am trying to measure the pulsewidth of an 55KHz pulse using timer0 (16F84A), this works fine....but what I don't understand is why the numbers jump so much. (from 69 to 87).
:=
:=What I'm trying to achieve is a filter, which detects 55KHz pulses in very short time. ( < 50us )
:=
------------------------------------------------
Give us some more information.

1. Is your code based on a CCS example file ? Which one ?

2. If you're not using a CCS example, then what method
are you using to measure the pulse width ?
Are you using EXT_INT, etc. ?

3. What crystal frequency are you using ?

4. What version of the compiler ?

5. Post your code, if it's not too long.
___________________________
This message was ported from CCS's old forum
Original Post ID: 11895

[John H. Edvardsen]

ex_pulse.c is the example I use....
20MHz, compiler v. 3.142

I've modified the top for using 16f877 like this...
#include <16f877.h>
#device ICD=TRUE
#fuses HS,NOLVP,NOWDT,PUT
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)

and I'm using setup_counters like this:
setup_counters( RTCC_INTERNAL, RTCC_DIV_1 );

Thanks,

J.H
___________________________
This message was ported from CCS's old forum
Original Post ID: 11910

[PCM programmer]

<font face="Courier New" size=-1>:=ex_pulse.c is the example I use....
:=20MHz, compiler v. 3.142
:=
:=I've modified the top for using 16f877 like this...
:=#include <16f877.h>
:=#device ICD=TRUE
:=#fuses HS,NOLVP,NOWDT,PUT
:=#use delay(clock=20000000)
:=#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
:=
:=and I'm using setup_counters like this:
:=setup_counters( RTCC_INTERNAL, RTCC_DIV_1 );
-----------------------------------------------

I did some testing, and I got similar results.
I'm using an 8 MHz clock.

I think it's either partly or completely caused
by latency in the polling loops. If I put in
this statement:

#use fast_io(B)

and then in main(), I put in:

set_tris_b(0xFF);

that shortens the polling loops to only 2 lines of
assembly language instructions. When I do that, the
difference between the nominal times and the "flyers"
is greatly reduced. But, it's still equivalent to
three instruction times, which is what you would expect.
A bit test instruction that doesn't skip, takes one
cycle, and a goto takes 2 cycles, so if it "just missed"
the edge, it would take 3 more cycles.

-----

If the CCS example doesn't work for you, then consider
changing to a PIC that has a CCP module. Use the CCP
to measure the period of your incoming square wave.
The 16F628 has a CCP module, and costs less than a 16F84.</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 11937

[John H. Edvardsen]

Thanks for the advice.

I'm using a 16f870 now with ccp, work great.

CCP use timer1 if i'm not mistaken, I use timer0 for timeout. (eg. if no pulse within timer0 reaches overflow then it resets a port).

There is one problem however,
When the pulse reaches >100KHz, I seem to get the same numbers as with 55KHz, and the routine gets trigged on eg. 110KHz, 166KHz, up to several MHz.

Is there any way of dealing with those?

------------ SNIP --------------
--------------------------------
#include <16f870.h>
#fuses HS,NOLVP,NOWDT,PUT
#use delay(clock=20000000)

long first, second, value;
byte gotfirst;
byte cnt1,cnt2;
byte gotnewdata;

#int_timer0
timer0_isr(){
output_low(PIN_B1);
cnt1=0;
cnt2=0;
value=0;
}

#int_ccp1
void isr() {
set_timer0(0); // reset timeout timer
if(gotfirst>0)
{
second=CCP_1;
gotfirst=0;
value=second-first;
gotnewdata=1;
}
else
{
first=CCP_1;
gotfirst=1;
}
}

main() {
setup_ccp1(CCP_CAPTURE_RE); // Configure CCP2 to capture rise
setup_timer_1(T1_INTERNAL | T1_DIV_BY_1); // Start timer 1
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_1); // Start timer 0

enable_interrupts(INT_TIMER0);
enable_interrupts(INT_CCP1);
enable_interrupts(GLOBAL);

set_timer0(0); // reset timer

while(TRUE) {
while(gotnewdata){

if(value>86 && value<94)
{
cnt1++;
cnt2=0;
}

if(value<86 || value>94)
{
cnt2++;
cnt1=0;
}
if(cnt1>2)
{
disable_interrupts(GLOBAL);
disable_interrupts(INT_TIMER0);
output_high(PIN_B1);
delay_ms(4);
cnt1=3;
enable_interrupts(GLOBAL);
enable_interrupts(INT_TIMER0);
}
if(cnt2>2)
{
output_low(PIN_B1);
cnt2=3;
}
gotnewdata=0;
}
}
}

---------------------

Cheers,

J.H
___________________________
This message was ported from CCS's old forum
Original Post ID: 11957

[PCM programmer]

:=
:=There is one problem however,
:=When the pulse reaches >100KHz, I seem to get the same numbers as with 55KHz, and the routine gets trigged on eg. 110KHz, 166KHz, up to several MHz.
:=
-------------------------------------------------------------

This may be an interrupt latency issue.

100 KHz would give a period of 10 us. You're running
the PIC at 20 MHz, which gives 5 instruction cycles per us.
So 10 us would be about 50 instructions. That's roughly
the number of instructions that are executed in the CCS
interrupt dispatcher and the initial code in your CCP
interrupt routine.

Maybe, as a test, don't use the CCP interrupt. Try doing
a polling loop in main(). Poll the CCP1IF bit in a tight loop.
Then read the CCP and clear the bit. That will get rid of
the interrupt latency.

Also, clear the CCP1IF bit just before you start polling.
___________________________
This message was ported from CCS's old forum
Original Post ID: 11985