Slowing down quadrature encoders

Exactly how fast is that?  IOW, how many ints/sec are you getting, or
are you polling the encoder?


Is it, wouldn't an 18F452 basically drop right in?  AFAIK it's
completely pin compatible.  It would certainly be faster running at
40MHz.


Another PIC or two?  ;-)

Actually, if you want to read quadrature, why not get a micro with a
quadrature decoder built in. The DSP56F80x's in our 'Pod line can read
32 bits of hardware quadrature decoding at 40MHz input.

I think we had a discussion about this a few "which processor"
discussions ago, but there aren't many micros with quadrature, so the
choices are limited, but the DSP56F805's not only have two hardware ones
built in, they also have timers that can be grouped to read quadrature.
In one project I read 6 channels of quadrature inputs in hardware, and
also read velocity of those inputs by timing the pulse widths with
remaining timers.

Having the right processor for the job can make a huge difference.

--
Randy M. Dumse

Caution: Objects in mirror are more confused than they appear.

Something like this, maybe?

http://www.usdigital.com/products/ls7183-ls7184/

or

http://www.usdigital.com/products/ls7166/


JW

These chips would give me more resolution, which would make it worse.
I'm using the external interrupt for 1 encoder and the change-on-port-b
interrupt for the other one. When the interrupt fires I check the
status of the other line to decide to increment or decrement the
counter. At full speed I'm getting interrupts at something like 80khz.
Since a 20mhz pic processes instructions at 5mhz, that gives me about
62 instructions between interupts. And with 2 channels of interupts at
the same time it just swamps everything. I would drop in a 452 except
the LVP is different and my compiler only supports teh 16 series, not
the 18 series. I'm hoping to find some kind of circuit I can place in
between the pic board and the encoder.
Thanks
Ringo

Whoops.  Just the second one (LS1766) would help you out.  Maybe.

With these, you could let the encoders "free run" and poll them when
you feel like it.  It would limit the amount of interrupt driven
overhead and give you better resolution.  Seems win-win to me, but not
sure of your total application.  Dont' know if you have enough i/o to
handle this or not.  Don't remember the pinouts of pic16f877a and too
lazy to go look for it at the moment.

JW

change-on-port-b

That's a bunch of ints/second!  Why such a high resolution?  Is the
encoder on the motor shaft, but there is a reduction gear train
following?  If so, can you relocate the encoder wheel to a place where
it turns slower?  It doesn't seem likely that you really need that kind
of resolution unless your robot is moving several hundred miles/hour.
;-)


The only other thing I can think of is to use a couple of flip flops to
divide channel A by 4, 8 or 16 to slow down the int rate.  You can still
just look at the B channel just like always to determine the direction.
It wouldn't be perfect in theory as it's susceptible to error when the
wheel changes directions, but it may be good enough to get the job done
in practice since you have such a high resolution to begin with.

 
If you have the SPI port free (plus a free I/O bit) I have a dual 8 or 12 bit
quadrature counter design that fits in a Xilinx XC9572XL (about $2.00)

It does require a free running clock at 2x the maximum quadrature count
rate, and 3.3V for the XC9572XL

Its a delta-counter so the count is cleared when read, making it easier
to create larger software counters by just adding the sign extended count
to the (16, 24 or 32 bit) software counter.  

Peter Wallace