> > 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.
> >
> And this is with a nice clean square wave into the INT input?  I was
> going to suggest that noise may be a problem.

It can't be.
I even have two different signal genaerators. One of them has sweep
capability so that I can test an "acceleration".

> > > 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.
> >
> So you work out the slope of the current (delta RPM)/Time and then
> extrapolate the RPM in x seconds?  That's pretty cunning.

That is correct. When you got it figured out the math is pretty
straightforward. If the sampling interval was constant it would have
been easy, but my sampling interval is increasing with RPM which adds
a bit to the complexity of the task.

> > I could use polling as you did, but I'm not sure why that should be
> > better.
> >
> I'm wondering if you have a potential problem with interrupt
> priorities. Posting your ISR code would be helpfull. What level of
> jitter are you seeing?  Is it always the same or does it vary with the
> input frequency (RPM)?

If I don't find my problem tonight I will post the ISR tomorrow. I'm
at work now and don't have the ISR handy.

The jitter is somewhere in the range of 5-6 bits, and that should
actually make the task of finding the error easier. It's really a lot
of jitter, so there must be some huge mistake somewhere.

Working off mind the ISR looks like this:

org 0x04

 ...
 context save from Microchip databook.
 ...

 btfss INTCON,T0IF              ;Timer interrupt?
 goto nex_chk_1

 incf TIMER,1                   ;Yes, increasing high byte
 bcf INTCON,T0IF                ;Clearing timer interrupt

nex_chk_1

 btfss INTCON,INTF              ;RPM-interrupt?
 goto end_handler

 movf TMR0,0
 movwf TIMER_STR                ;Saving TMR0 in low byte
 clrf TMR0

 movf TIMER,0
 movwf TIMER_STR+1              ;Saving TIMER in high byte
 clrf TIMER

 bsf STAT,0                             ;Sets a status bit to indicate that a new
                                                ;count value is ready

 bcf INTCON,INTF                ;Clearing external (RPM) interrupt

end_handler

 ...
 context restore from Microchip databook.
 ...

 retfie


What could go wrong here?
The main code is running in an loop polling the STAT,0 bit.
When it gets set the math is performed and the STAT,0 is cleared
again, and it goes back in the polling loop.

The TIMER_STR:2 variable is the count value used in the math.

If both interrupts occur simultaneously both will be serviced in turn
without leaving the ISR, since I'm checking the INTCON,INTF flag
after serviceing the timer interrupt.

If the timer interrupt occurs after the "btfss INTCON,T0IF"
instruction above I will get some extra jitter since it is not
rechecked until the ISR has ended. I tried correcting for this by
checking this bit within last part of the ISR, and if it was set I
would increase the TIMER register manually before storing it in
TIMER_STR+1. I also cleared the interrupt so that it would not cause
a retrig.

I still fail to see what's wrong here. Some jitter is bound to
happen, but not very much, I would think.


-¯yvind


_______________________________________________
¯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)