> > I need to accurately count the time *between* pulses, to get a
> > number that is inversely proportional to the RPM.
> >
> > The TMR0 and the external interrupt is used. (16F84)
> >
> > I've programmed the TMR0 to run with a prescaler of 1:2, so the TMR0
> > frequency should be 1.25 MHz.
> >
> So that would be a 10MHz crystal then?

Yup. Forgot to tell.

> > I want to have a 16 bit counter, so in the interrupt routine I
> > increment a register for each TMR0 interrupt. This is the high byte
> > of my counter.
> >
> > When the external interrupt occurs, I read both the TMR0 and this
> > register. Together they are transferred to another 16 bit variable
> > that is used by the rest of the code. Then the TMR0 and the high
> > byte register is cleared, and I exit the ISR.
> >
> > What troubles me is that I get a lot of jitter on my count value. A
> > lot more than I would expect. The latency of the TMR0 interrupt
> > should not bother me, since in the part of the ISR that handles this
> > I just increment the high byte and then exits. The TMR0 itself is
> > not tampered with.
> >
> > The latency that I get when the external interrupt occurs will cause
> > a little bit of jitter, since I'm reading the TMR0, but it shouldn't
> > be more than a couple of bits, especially since the TMR0 is running
> > at half the instruction cycle.
> >
> > Any good hints?
> >
> > I don't have the code here, but I can post that later if necessary.
> >
> Ok, I did almost exactly this about 6 months back.  It was for a
> digital tachometer which also used software PWM to drive a
> conventional meter movement and had all sorts of bells and whistles
> such as max RPM memory. All on a 16F84 with lots of room to spare.

I'm not running into trouble with space either.

> I didn't bother with the external interupt to detect the ignition
> pulses, I just used polling as the frequency was so slow.  I did use
> TMR0 with another 8 bit register though.  Jitter was a problem.  The
> reason is that you are measuring the period between sparks with a very
> high precision, and engines just do not run at constant speed.  In
> fact even during one revolution the crank doesn't turn at a constant
> velocity.  The fewer cylinders the engine has, the worse this effect
> is.

Yes, that can be a problem, but I see my jitter also when I have a
function generator at a constant frequency connected to the circuit.

> Unfortunately you need 16 bits because of the dynamic range of the
> counter. Unless you use a large counter, it will either overflow at
> low RPM or run out of resolution at higher RPM.  What I did was to
> convert to RPM, and feed the results into a simple (digital) low pass
> filter.  I could get a reading steady to within a few RPM on a 4
> cylinder engine this way. You could lose either one or two significant
> figures depending on your requirements.  A least significant digit
> which constantly changes is very irritating, I'd rather not see it :o)

I also have an IIR low-pass filter that works ok.

The thing I'm building is a shift-light device, but not a
conventional one. It's supposed to be predictive, so that it will
give a forewarning that is time dependant, ie it gives you a warning
at a preset time before max RPM is reached. Conventional shift-lights
is based on RPM, and will warn based on current RPM-reading.

This involves a bit of math, but I got that part figured out. The
problem is that my counter jitters too much, and I can't figure out
why.

I could use polling as you did, but I'm not sure why that should be
better.


_______________________________________________
¯yvind Kaurstad, oyvind@safetel.no

Safetel AS
P.B. 405, N-4067 Stavanger, Norway
Tel: +47 51 81 78 80 (Switchboard)
     +47 51 81 78 82 (Office)
     +47 51 81 78 93 (Fax)