Slowing down quadrature encoders

wrote

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? ;-)

Something like this, maybe?

or

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

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.