I posted a solution to the encoder problem some time ago
(http://www.piclist.org/techref/postbot.asp?by=3Dthread&id=3D%25quadrature%=
25en
code%25). This solution seems very simmilar to the one you use, but do not
need the ROM table. =


It uses the (two) bits from the previous encoder state and the (two) new
state bits, and do a "cross-XOR" between them (normal XOR, but with the
previous two bits interchanged). The result are two bits. If one of them is
"1", then rotate left. If the other is "1" then rotate right. If both are
"0", no change. If both are "1", this is your skipping situation. Easy to
detect. Easy to follow. Without table.

I can try to translate the (original) Spanish comments in the code (see,
this post is from 1998, the PIC was a 16C54, and I was not using C or other
fancy programming language):

#define encx   PORTA,1    ; Encoder is in PORTA,
#define ency   PORTA,2    ; pins 1 and 2, i.e.
;
; Encoder reading routine (only here for readability).
       clrf    auxint     ; Clears the aux byte,
       btfsc   encx       ; and "put" in it both of the
       bsf     auxint,0   ; bits of the new encoder
       btfsc   ency       ; state ('x' and 'x')
       bsf     auxint,1   ; (this part can clearly be done better)
;
; Variable 'encod' has in its two LSB the previus encoder state. Cross-XOR
is done:
       movf    auxint,W   ; XOR is done between previous
       xorwf   encod,F    ; and new encoder state
                          ; (note auxint only uses the (two) LSB)
;
; Using rotations, the order of the new encoder state bits is reversed
; and stored in encod, to be used in the next iteration...
       rrf     auxint,F   ; I think this part is obvious...
       rlf     encod,F
       rrf     auxint,F
       rlf     encod,F
;
; Work done.
; Put here your motion detection routine. A simple example could be:
       btfsc   encod,2    ; Movement in "x" direction...
       incf    posenc,F   ; ('posenc' holds the position information)
       btfsc   encod,3    ; ...or in 'y' direction...
       decf    posenc,F

In previous posts of the encoder problem, I had no response to this routine
from the list, so I don't know if anybody used it. I did, and with success.

Regards,

=C1lvaro Deibe D=EDaz.

> -----Mensaje original-----
> De: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] =

> En nombre de M. Adam Davis
> Enviado el: jueves, 18 de enero de 2007 21:00
> Para: Microcontroller discussion list - Public.
> Asunto: [EE] Rotary encoders: advanced decoding (skipping codes)
> =

> It occurred to me while I wrote up my latest rotary encoder =

> decoding routine that one could do a small amount of error =

> correction as well.
> I wanted to see if anyone had run into such an attempt =

> before, and had any advice or thoughts regarding it.
> =

> This is concerning a normal rotary encoder with gray encoding =

> - one output is 90 degrees out pf phase from the other, and =

> only one bit changes at a time:
> A B
> 0  0
> 0  1
> 1  1
> 1  0
> 0  0
> =

> My current method takes the previous state (two bits) and the =

> new state (two bits) and concatenates them into a four bit =

> number.  I then use a 16 position RETLW table to return -1, =

> 0, or 1 depending on the 4 bit number.
> =

> Encoder state byte:
> 0 0 0 0 Aold Bold Anew Bnew
> =

> This works great, and is very quick.  My particular method =

> holds the old state in an 8 bit variable, and simply shifts =

> it over two bits when a new state is ready, then chops off =

> the top four bits.
> =

> It occurred to me, though, that if I didn't chop off the top =

> four bits (which are the results of the last two states, or =

> in others words I have three old states and the new state in =

> one 8 bit block) then I could use that history to determine =

> the direction the encoder was going when it skipped bits.
> =

> If the four samples were
> A B
> 0  0 (oldest state)
> 0  1 (older state)
> 1  1 (last state)
> 0  0  (newest state)
> =

> Then this last state change from 1  1 to 0  0 could be =

> counted as 2, rather than thrown away as an illegal change.  =

> This would take a 64 or
> 256 entry table, rather than 16 entries, but it would be just as fast.
>  Faster, even, since I wouldn't have to clear the top four =

> bits every time I got a new sample.
> =

> Of course, I've done the calculations and this shouldn't =

> occur (ie, I'm polling them faster than they should change - =

> no interrupts at the moment), but I'd like to be able to =

> lower the processor speed and the overhead of the polling =

> routine as much as possible.
> =

> I don't see any obvious problems, but I imagine this is not a =

> new idea and there must be a reason why I haven't seen it =

> discussed before.  I can see why this wouldn't be on hardware =

> decoders (event driven state machine, not polling - usually =

> with glitch suppression), and very fast interrupt driven =

> routines might never need it.
> =

> -Adam
> =

> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - - Moving in =

> southeast Michigan? Buy my house: http://ubasics.com/house/
> =

> Interested in electronics? Check out the projects at =

> http://ubasics.com
> =

> Building your own house? Check out http://ubasics.com/home/
> --
> http://www.piclist.com PIC/SX FAQ & list archive View/change =

> your membership options at =

> http://mailman.mit.edu/mailman/listinfo/piclist


-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist