I'll have to take a closer look at this one later, I did read it in the techref and was intrigued. It appears to take 15 instruction cycles. I suspect a jump table takes more space, but should take less time. Of course, I see that your routine can be optimized further depending on the particular requirements. Thanks for posting a translation, I wasn't looking forward to decoding the routine without clues. :-) -Adam On 1/19/07, =C1lvaro Deibe D=EDaz wrote: > I posted a solution to the encoder problem some time ago > (http://www.piclist.org/techref/postbot.asp?by=3Dthread&id=3D%25quadratur= e%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 oth= er > 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 routi= ne > from the list, so I don't know if anybody used it. I did, and with succes= s. > > 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 > -- = - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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