Searching \ for 'Speedometer Module 16F84/04P' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'Speedometer Module 16F84/04P'.

Truncated match.
PICList Thread
'Speedometer Module 16F84/04P'
1998\11\23@183654 by James Cameron

flavicon
face
This may be useful for newbies dabbling in 16F84 interrupts.

The task I set myself was to produce a module with four connections ...

       +13.6VDC unregulated input
       Vehicle speed sensor input
       RS-232 serial output (TTL level)
       Ground

The module would count the speed sensor pulses and deliver them with a
timestamp as an ASCII line on the serial output that looks like this;

       a,0000000001,0000000001\r\n

In other words, the letter "a" to signify a message type or version
number, a comma, a timestamp in milliseconds (32 bit), another comma, a
speed sensor cycle counter (32 bit), a carriage return and a line feed.

The intention is to produce a data source with good calibration for
further processing by a laptop computer.  Later I'll be adding an LCD
and numeric keypad for local display and limit setting.

The things I learned from designing and writing this were;

       - that using TMR0 as the time base works well, (external timing results
show 99.992%, which is probably measurement noise)

       - that reloading TMR0 can help with serial output code,

       - that reloading TMR0 makes it's use as a time base less easy, but
still practical (my code has a 208 cycle T0IF for 4800 baud, so I add
208 to an accumulator of microseconds until I got 1000 of them, and then
I saved the remainder after subtraction),

       - that reloading TMR0 and insisting on using it as a time base requires
that no other interrupts be enabled, for otherwise the reload can be
delayed,

       - that 32-bit counters are trivial to implement on the PIC,

       - that although I could not figure out exactly what value to reload the
TMR0 with (my code comments are wrong), I was able to adjust the value
based on overnight timings, [where exactly did I go wrong?]

       - that debouncing an input from a recurring T0IF ISR is fairly trivial
(my code uses an ignore timer)

       - that it helps to "schedule" an interrupts-disabled segment of code to
occur immediately after a T0IF, so as to avoid causing the TMR0 to be
reloaded wrongly (hmm, I suppose I could read it, calculate an offset
... anybody do that?)

       - that a startup delay has surprising advantages (when I hit the
"reset" using a breadboard wire, I'd get noise on the serial output
caused by multiple reset events; but restarting the delay is harmless)

       - that continuous asynchronous serial output with only one stop bit can
yield a failure of synchronisation in certain UART receivers, and so
sending an eight bit period of stop bits will fix this, (my code no
longer sends continuously, but the "tx_sync" function is still present)

       - cblock is a neat idea.


Things I learned about my tool set (Linux, Emacs, GPASM, GPSIM, DIY Kit
119);

       - Emacs does colour syntax highlighting, though cblocks look
         "wrong" somehow,
       - Emacs handles the semicolon key for comments automatically,
       - GPASM does not yet warn me about failing to mention the
         destination on many PIC instructions, (I may fix that),
       - Linux may wait for five seconds on open()'ing the printer
         device, presumably because the "printer" is not "ready",
       - The entire sequence of assemble and program can be tied to a
         single keystroke in Emacs,
       - a 386/25 with 8Mb of memory is sufficient for the task,
       - the DIY kit sits nicely above the keyboard on my 386/25
         laptop,
       - with no budget for ZIF sockets, machine pin sockets are fine,
         and holding the chip, mounted in another machine pin socket,
         by finger pressure into the socket works fine.


Code is at http://ftp.digital.com.au:6153/speedo/6.asm

--
James Cameron                                      (spam_OUTcameronTakeThisOuTspamstl.dec.com)

OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH,
COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.

"Specialisation is for insects." -- Robert Heinlein.

1998\11\24@045505 by Wolfgang Strobl

flavicon
face
On 23 Nov 98, 23:25  James Cameron wrote:

> The module would count the speed sensor pulses and deliver them with a
> timestamp as an ASCII line on the serial output that looks like this;

>
>         a,0000000001,0000000001\r\n

Funny. I just finished and testet a similar device last weekend, and reported th
e
results to the "bikecurrent" mailing list (for a slightly modified html version,
see
http://ntklotz.gmd.de/pic/tacho/bikecurrent.htm).

My device is powered by the laptop, so an external 12V isn't required (this is f
or
a bicycle, not for a motorcycle).

I use a 4,194,304 Hz quartz, output binary fractions only, and never reload
the tmr0 register, so my measurements are as accurate as the clock itself.

--
     o      (     .....Wolfgang.StroblKILLspamspam@spam@gmd.de (+49 2241) 14-2394
    /\        *   GMD mbH                       #include
  _`\ `_<===      Schloss Birlinghoven,         <std.disclaimer>
__(_)/_(_)___.-._  53754 Sankt Augustin, Germany ________________

1998\11\24@083332 by Reginald Neale

flavicon
face
>
>I use a 4,194,304 Hz quartz, output binary fractions only, and never reload
>the tmr0 register, so my measurements are as accurate as the clock itself.

Wolfgang:

I am interested: Where do you obtain such a crystal, and what kind of
long-term stability do you experience with it?

Thanks for your attention,
Reg Neale

1998\11\24@094427 by Wolfgang Strobl

flavicon
face
On 24 Nov 98, 13:31  Reginald Neale wrote:

(I wrote)

> >I use a 4,194,304 Hz quartz, output binary fractions only, and never reload
> >the tmr0 register, so my measurements are as accurate as the clock itself.
>
> Wolfgang:

> I am interested: Where do you obtain such a crystal, and what kind of
> long-term stability do you experience with it?

Wrt. first question: got it via mail-order, from the German distributor
"Conrad", it's in their catalog, and a standard component, as it
seems, other similar frequencies, 4.0960 MHz, for example, are
more expensive.

Long-term stability? No idea. The catalog doesn't say anything
about it, it just says "Quarzes (?) for microcomputer, clocks, etc.".


--
     o      (     Wolfgang.StroblspamKILLspamgmd.de (+49 2241) 14-2394
    /\        *   GMD mbH                       #include
  _`\ `_<===      Schloss Birlinghoven,         <std.disclaimer>
__(_)/_(_)___.-._  53754 Sankt Augustin, Germany ________________

1998\11\24@172554 by Scott Dattalo

face
flavicon
face
On Tue, 24 Nov 1998, Wolfgang Strobl wrote:

> On 23 Nov 98, 23:25  James Cameron wrote:
>
> > The module would count the speed sensor pulses and deliver them with a
> > timestamp as an ASCII line on the serial output that looks like this;
>
> >
> >         a,0000000001,0000000001\r\n
>
> Funny. I just finished and testet a similar device last weekend, and reported
the
> results to the "bikecurrent" mailing list (for a slightly modified html versio
n, see
> http://ntklotz.gmd.de/pic/tacho/bikecurrent.htm).

Neat! One idea I had for a speedometer, but (like most of my other ideas)
never implemented was to count the spokes and use the valve stem as the
single-revolution reference. Most valve stems and spokes are metal
(steel), so it should be possible to inductively measure them.

Scott

1998\11\25@054124 by Wolfgang Strobl

flavicon
face
On 24 Nov 98, 14:24  Scott Dattalo wrote:

> On Tue, 24 Nov 1998, Wolfgang Strobl wrote:
>
> > On 23 Nov 98, 23:25  James Cameron wrote:
> >
> > > The module would count the speed sensor pulses and deliver them with a
> > > timestamp as an ASCII line on the serial output that looks like this;
> >
> > >
> > >         a,0000000001,0000000001\r\n
> >
> > Funny. I just finished and testet a similar device last weekend, and reporte
d the
> > results to the "bikecurrent" mailing list (for a slightly modified html vers
ion, see
> > http://ntklotz.gmd.de/pic/tacho/bikecurrent.htm).
>
> Neat! One idea I had for a speedometer, but (like most of my other ideas)
> never implemented was to count the spokes and use the valve stem as the
> single-revolution reference. Most valve stems and spokes are metal
> (steel), so it should be possible to inductively measure them.

Well, when looking at the bits of data I've collected so far with my
device, I notice that there is so little random variation between one
cycle and the next, that I believe the measurement to be already
more exact than necessary with one pulse per revolution.   So
what's the advantage of your design? No necessity for a magnet in
the spokes? Greater distance between wheel and sensor, at least
in theory? And what kind of sensor are you going to use? I'm
curious.

--
     o      (     .....Wolfgang.StroblKILLspamspam.....gmd.de (+49 2241) 14-2394
    /\        *   GMD mbH                       #include
  _`\ `_<===      Schloss Birlinghoven,         <std.disclaimer>
__(_)/_(_)___.-._  53754 Sankt Augustin, Germany ________________


'Speedometer Module 16F84/04P'
1998\12\04@164032 by John Payson
flavicon
face
         - that using TMR0 as the time base works well, (external timing result
s
       show 99.992%, which is probably measurement noise)

         - that reloading TMR0 and insisting on using it as a time base require
s
       that no other interrupts be enabled, for otherwise the reload can be
       delayed,

I would suggest that using "addwf" on the TMR0 register is much
better than reloading it with a constant.  Simply add (259-desired
timer period) to RTCC any time in your ISR and, provided that you
don't dally too long before the add it will work consistently pro-
vided only that the add completes before the next timer tick inter-
rupt is supposed to happen.

Unfortunately this does not work when using the RTCC with a pre-
scalar, meaning it's limitted to triggering interrupts at intervals
which are either <256 cycles or a power of two in length.  While
there are ways of preventing and/or correcting for timing errors
introduced by RTCC writes' clearing of the prescalar, I don't know
of any particularly good ones.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...