AVR-Chat

Gentlemen,

Sorry for the confusion on the initial question.  I do understand the various basic aspects of the encoder function and the trade off of IRQ vs poll, etc.

What I am really wanting to do is to build a generic set of polished functions so that the code is clean and easy to reuse in the future as a generic library function set.  And the code covers all the typical variations one is likely to encounter.

As several have suggested, getting a set of code that works for a single application is not hard.  My rookie hack at making the encoder function will be fine for the project in front of me.  

And I believe someone may have a more robust implementation - that would cover a wider range of eventual complications and have considered things that I may not have initially.  

By eventual complications, for example, would be the ability to cover the various types of encoders configurations on the market or a debounce strategy that is robust enough to work with many encoders even if some tend to wiggle onward for what seems an eternity - things like that.

My objective for this question to the Yahoo chat group ("the board") was simply to find out if there may exist already the work done in a vetted and optimized fashion already by seasoned vets of the AVR world.  

Hope that makes sense.

Jeff


From: Steve Hodge 
Sent: Wednesday, December 09, 2009 9:52 AM
To: AVR-Chat@yahoogroups.com 
Subject: RE: [AVR-Chat] Rotary encoder


  
I agree with the other comments. Here's an outline my son sent to me a
couple of years ago. Maybe it will help you write your own code. I was
able to very easily just on what he says below. We were using an Atmel
644P at the time. Steve

--------------------------------------------

Hi,

Rudder encoder is two data wires plus 5V power and ground. We'll need at
least one other wire either for an index on the encoder or some other
absolute positioning signal.

Encoders only change 1 of the two bits at a time - they count in "gray code"
or "in quadrature" rather than normal binary.

So iterating through steps in one direction, the bits will go through this
sequence:

00 01 11 10 00 01 11 00 ...

Contrast this with normal binary counting which would be:

00 01 10 11 00 01 10 11 ...

So what I did was make a lookup table of previous state + current state. The
result is either:

-1 (to the left)

0 (same)

+1 (to the right)

2 (invalid: the encoder jumped two steps which should never happen)

We are working with 4 bits so the table has 16 possible combinations which
represent the following state changes:

00<-00 00<-01 00<-10 00<-11

01<-00 01<-01 01<-10 01<-11

10<-00 10<-01 10<-10 10<-11

11<-00 11<-01 11<-10 11<-11

The values of the table will be:

0 -1 +1 2

+1 0 2 -1

-1 2 0 +1

2 +1 -1 0

Say register R0 contains last reading in bits 2 and 3. The algorithm looks
like this:

Shift R0 two bits to the right so that the last reading moves into bits 0
and 1.

Read current reading into bits 2 and 3

Do the lookup of the memory at the table start address + R0 If result is 2,
signal an error.

Else add result (-1, 0, or +1) to position counter.

Does that make sense?

Matt

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Jeff Blaine AC0C
Sent: Wednesday, December 09, 2009 1:16 AM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Rotary encoder

I have seen a lot of code on handling the rotary encoder. But it seems there
are a thousand approaches spreading over the years on the web. 

Given the popularity of this as an input device now, I hoped the board had a
c-code snip that covered handling the rotary encoder in an IRQ context.

Many thanks.

73/jeff/ac0c

[Non-text portions of this message have been removed]

__________ Information from ESET Smart Security, version of virus signature
database 4672 (20091209) __________

The message was checked by ESET Smart Security.

http://www.eset.com

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]