Hardware Reference
In-Depth Information
For example, imagine you just want to count how many times a button is pressed; simple
code to do this will often fail due to contact bounce. It will appear to record more pushes
than you make. he switch needs what is called
debouncing,
reminiscent of Tigger in
Winnie
the Pooh.
For the simple example of just counting button pushes, a delay of 20 mS after a
push is detected is normally enough to sort things out. However, contact bounce in rotary
encoders can lead to problems of adding extra steps or getting the software monitoring it so
mixed up that it thinks it is being turned in the opposite direction. As the shaft is sometimes
being rotated quite rapidly, using a delay is inappropriate, so you have to consider something
else to give a clean output. Fortunately the nature of the Gray code allows you to reject
bounces.
For any given state of the outputs of a rotary encoder, there are three possible states it could
change to next: one for clockwise rotation, one for anticlockwise rotation and one where it
can't possibly go but might due to contact bounce. his last state is an error state. Figure
15-2 summarises each current state of the encoder and the three states that could follow. So
when you read an encoder, and knowing the last state, if you come across an error state then
all you do is ignore the reading. hat is, do not update the last state with the new reading and
do not indicate a step movement. Otherwise you can indicate that a clockwise or anticlock-
wise motion has taken place and update the last state with the new reading.
Well, you would think that covers it all, but there is one last curveball you have to cope with -
and that is detents. here are two types of rotary shaft encoders with detents, and this is where
the detents are placed in the switch output sequence. Figure 15-3 shows the two methods that
are used. he irst one has the detent in position A - that is, between the clicks the switch goes
through all the transitions available. he order in which these transitions occur tells you if the
click was a clockwise or anticlockwise click. he second scheme has a detent in every other posi-
tion so it comes to rest with either both signals high or both low, but again the transition
between these states tells you the direction. I have not seen an encoder with detents in every
position, so, if they do exist, they are rare. Encoders made by the company Alps tend to have
one detent per sequence, and those made by Bourns tend to have two. In this project I used
Bourns encoders although it is simple enough to use Alps.
A rotary encoder needs quite a bit of looking after from the software point of view, and there
are two ways to do this: with interrupts or polling.
Interrupts
are where the action of the
switch causes the computer to interrupt what it is doing and call a special interrupt service
routine which will handle the change. his is by far the best way of doing things, but unfor-
tunately doing this under Linux is tricky and not very efective. It can be done but often the
interrupts come too frequently for it to cope. he other way is
polling,
which is looking at the
switches as quickly as possible in the code. his is an acceptable solution for this application
as the code spends most of its time waiting for movement from the encoder and the visual
feedback is such that a missing click or two during rapid rotation is not very important.
