Brian Watson wrote:
> Please keep it public.  As a relative beginner, I also would be
> interested in the strategy for developing this code.

Well, alright then, public it is.  Calm down everybody; and I expect no
complaints that we're being too verbose about such a "simple" project.
;-)  Watch out for my ego though.

Since you ask about the strategy for developing ... here's how I worked
on this one ...

        1.  got annoyed that I couldn't trust my speedometer,
        2.  got bored while driving back from the farm,
        3.  allowed my mind to wander,
        4.  literally dreamed up a design in my sleep,
        5.  couldn't continue sleeping the next day, so transcribed it.

However, to be a bit more serious ...

The task breaks down to counting the number of revolutions of the car
wheels over a time period, and mathematically converting the result into
the local speed convention, be it miles or kilometres per hour.

So, we want to count car wheel revolutions and time.

Do we count the number of revolutions per time period, or measure the
time period for a number of revolutions?  I've answered that in my
previous mail; the latter solution is better because it reduces error.

Counting time ... we could do it a number of ways;

        a)  have an external time source that we could query,

        b)  maintain an internal time source linked direct to crystal,
            such as the timer/counter in the 16F84,

        c)  maintain a software delay loop linked to crystal.


Counting the pulses from a wheel sensor could also be done a number of
ways;

        a)  tie it to an input on the chip and watch it like a hungry
            domestic feline using a software loop,

        b)  tie it to the counter, and watch the result,

        c)  tie it to an interrupt input, and count the interrupts.


Now, which of the combinations do you choose?

We have these counting resources;
        1)  the internal timer,
        2)  simple input pins,
        3)  interrupt input pins,
        4)  software timing,

Which ones I chose depended on the frequency of the incoming pulses.
For the time, we have a 1MHz pulse rate.  We could use a software loop,
but it would be difficult to code.  The internal timer therefore seems
best for that, as I have already written about.

For the wheels, we have a fairly low frequency pulse sequence, so we
could use either of the other options, but not the timer/counter,
because we have decided to use it for the time base.  The simplest to
implement seems to be the interrupt input pin, RB0/INT, which has the
advantage of a well known response time over watching a pin.

--

Consider an even simpler most less "accurate" solution ... smooth the
pulses from the sensor, apply to an averaging op-amp configuration, take
the resultant analog voltage, then apply it to an A/D converter and a
display driver.

Then you'd have this nice trim-pot in the design that would let you
"tune" the whole thing, provided you had a reliable calibration
speedometer handy.  ;-(

But we can't talk about that solution here, unless it involves a PIC.
Chuckle.

I'll admit to a bit of prior experience on this one ... I programmed an
80C85 in a Tandy 102 (1985) laptop to watch pulses and to estimate
speed.  On that machine I had only a 256Hz interrupt clock.  There's an
article I wrote on that a few years ago somewhere on the web.  Perhaps
Club 100.  It was mostly in BASIC, with a small bit of interrupt
handling code just to perform the timing.  But it was big and bulky and
so was rapidly submerged and re-used.

--
James Cameron                                    (cameron@stl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800