Robert Rowlands wrote:
> Seems like a few people are interested in this project.

Yes, and they are quite willing to see us cross-post to the PIClist.
Your choice.  If you do post there, I will probably answer.  Post direct
for more direct response.

[this message copied to PIClist for others to enjoy]

> I have to come up with some kind of board design soon, or I will not be
> able to get my project completed in time.

Strange.  You have to design a board?  I would always use wire-wrap or
veroboard, but then, if part of the project is to design a board, I
suppose you have to.  ;-}

> I come up with using timer0 as a counter, whilst looking at the
> frequency counter application notes at www.microchip.com.  However that
> was looking at much higher frequencies.

Yes, I agree.  For me, counting the pulses as they arrive is very simple
in software, because they arrive so slowly.  By comparison, getting a
one second delay in software to work precisely is not trivial.  Hence I
decided to use TMR0 as the time base instead.  It will increment at the
processor clock speed (or some division thereof) without software having
to be involved.

> I take it that if you enable tmr0 which will then increment with each
> pulse from the sensor.  Once tmr0 is enable, then you implement a
> software delay of let us say 1 sec, once that finishes then disable
> tmr0 move it into some memory location for calculations then clear
> tmr0.

Problem is the number of counts you get in one second can be small, like
at 60km/h, and so the accuracy suffers.  Think of the relative error of
each measurement you are taking; pulses and seconds.  At, say, 20 pulses
per second, you have an error of 0.5 pulse, so you get either 19.5 or
20.5, and that is a significant error.  The error in the time base is
trivial.

Increasing the pulse frequency helps ... but remember you are doing that
by adding to the number of magnets on a wheel or something, and each one
has to be positioned just right, whereas with one magnet it can't help
being right.

So I reverse the measurement ... by handling an arriving pulse the error
in the pulse data stream is much reduced ... I'm measuring the time
between n pulses rather than the number of pulses in n seconds.  My time
granularity can be in microseconds if I like, because I'm using a
crystal as the time base.

So, if I get pulses at, say, 100Hz, then I'm counting about 10,000
microseconds between pulses.  A small change in frequency is still
caught.  Unfortunately it means I have to invert the output data, but
hey, that shouldn't be too hard.

> Don't have much of an idea about displaying to an LCD screen, I did
> want a large display for the speedometer.

One can obtain large LCD screens for this.  I think
http://www.rocom.com.au/ have a large two line display on special right
now for $25.  Not sure.

The interfacing is fairly trivial, in my opinion.  You saw the picture I
sent you?  [A draft design for LCD panel, 12 key keypad, and RB0/INT
connected to the sensor.]  You need three control lines and four data
lines to operate an LCD in four bit mode.  In eight bit mode you'd need
another four data lines.

The R/W line is read or write enable.  It is set to 1 for reading.  The
RS line is a register select; there's a control register and data
register.  The E line is an enable, which clocks the data from the data
bus into the LCD's register.  Or out of the LCD to the data bus.

So from the perspective of the microcontroller, you just set up the data
bus, set up the RS and R/W lines, then pulse E up and down once.

In four bit mode, you then push out the other four bits onto the data
bus and throw another E pulse.

You can tell the LCD to position to a cursor address before telling it
to accept characters.  Luckily you just have to send the ASCII codes for
the characters, you don't have to draw the characters yourself.  ;-)

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