PIC Capture port question (fundamental)

[DanD]

I havent written any code yet, but i want to make sure i understand how this thing works. I want to measure the time between pulses on the signal i'm feeding into the capture port.

If i'm understanding this right, an event is a rising edge, falling edge, or a mutiple of edges. i want to use the rising edge. (every rising edge).

So when the capture port sees the event, it starts the timer. then when it sees the event again, it stores the timer values in ECCPR1H:ECCPR1L. (16bits). so when i read these values i have a unit of 'ticks' right? and i assume a tick is determined by my clock speed. so if i'm running at 20MHz, then a tick is 0.00000005 seconds.

im measuring pulses from a wheelspeed sensor so i was thinking of doing my math by measure the distance between pulses and from that figuring my MPH. i've found that (.0923/Tpulse(s)) or 923/(10000*Tpulse(s)) should give me my MPH for my tire circumference. so i just need to convert ticks to secods and i'm set.

i chose this option over say counting pulses per second or even half second because that would take too long to get a sample. does this make sense?

So i thought id run this by you guys before i started trying to code it up. thanks!

 

[Papabravo]

You did not say which processor you are using, but from the register names is sounds like a PIC of some description.

I think you may be off on only one point. I think the CCP module records the value of the free running timer on each rising edge. I'm not sure about setting the timer to zero on one edge and capturing the value on the next edge, but I can't be sure unless I know which datasheet to look at.

If you have two rising edge capture values, then the elapsed time is just the twos complement difference. As long as the elapsed time is less than 65536 ticks you will have the number of ticks equal to the period. It is perfectly OK for the timer to roll over from FFFF to 0000. The twos complement subtraction will still give the correct result.

 

[philba]

minor point, the tick rate for PIC16s is 1/4 the clock rate or 200 nS at 20 mhz. assuming no prescale.

PB is right about the ccp operation for PIC16s. I'd use the ccp interrupt to get get the captured time.

 

[DanD]

ah, thanks guys. sorry, its a PIC18F4480.

 

[philba]

ah, so you are use the eccp. that should work ok. you still have to divide the freq by 4 though.

 

[DanD]

hrmm i'm a bit confused at how the overflow of the 16bit result register works.

w/ 16bits i can only hold 65536 ticks. i calculated that at 1MPH (most ticks i'll ever have i guess) there would be 461500 ticks (at Freq/4). too much for the register..

how do i deal w/ this?

should i have two seperate algorithms.. a high speed and low speed. where low speed is pulses per time and high speed that is time per pulse? ack

i have all the code outlined and now instead of calling the capture function, i'm simply sticking a tick value in there. my math for calculating speed is simply:

speed (MPH) = 461500/ticks.

if i set ticks = 461500, i should expect speed to = 1;, however for some reason the display is reporting a '167'. strange. example:

unsigned int ticks=0;
unsigned int speed=0;

ticks=461500;
speed=461500/ticks;

WaitXLCD();
SetDDRamAddr(0x4E); //Second Line B spaced out
WaitXLCD();
putsXLCD(itoa(speed));

the LCD code is used throughout the program and works fine everywhere else so i think it is fine.

what am i missing that makes speed report as '167' instead of '1'. if i directly assign speed=1; the display reports '1' fine.

 

[philba]

Um, are you sure your compiler is properly handling 461500? My guess is that it isn't. You will either need to use doubles or reduce the number of ticks (prescale) you will get at 1 mph. prescale by 8 or more should do it.

by the way, you are going to want to do averaging or some sort of impulse filter to prevent the readout from chattering (flipping between several speeds quickly).