> I've never tried to measure periods by monitoring the inputs. In the
> few projects where I have counted pulses, for example, where I
> monitored a flow meter, I used the Capture or Compare module.

A CCP module in capture mode is ideal for measuring the period between
pulses.  However, no PIC has 12 of these.  Fortunately your pulse speed is
so low that the capture function can be done in software instead of
hardware, which allows any pin to be a capture input.

For example, you're expected period is about 19mS.  If you sample the
inputs every 200uS, then your resolution is a bit over 1 part in 90.  You
probably want better than for displaying speed.  To get better resolution,
you can trade off response time by doing some low pass filtering.  This is
no problem at all since you only need to update the speed value every
500mS.  For example, let's say you measure 92, 93, 92, 91, 92, 93, 93, 93,
92 200uS time slices between successive pulses.  Take these values and low
pass filter them and the result will be sortof an "average" of recent
pulse periods.

> I have a hunch that this type of monitoring
> would be easier in assembly than in CCS C because of the timing
> loops.

Pretty much everything is easier in assembly on a PIC than in C, once you
are familiar with the assembler and have gotten good at it.  The many so
called advantages of higher level languages don't hold water on small
resource limited systems where you are always close to the hardware, in my
opinion.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu