I would like to count n-coder`s ticks (channel A and B) by use of AVR processor. I think about that such variable is incrementing while rotation of n-coder`s shaft in the right, and variable is decrementing while rotation in the left. I think that counters implemented in AVR can count in one direction only. At the moment i am useing such code:
long int licz = 0;
SIGNAL (SIG_INTERRUPT0) { if (!(inb(PIND) & 8)) licz++; }
SIGNAL (SIG_INTERRUPT1) { if (!(inb(PIND) & 4)) licz--; }
You should be able to do this just using 1 interrupt instead of two. Tie one of the encoder lines to one of your interrupts, and the other to a general purpose I/O and config it for input. When your interrupt handler executes, you know you have motion. Within the interrupt handler, just read the value of the other line and if it is high, you are rotating one way and if it is low, the encoder is rotating in the opposite direction.
I have an example of this on my web site, see the 'servo' project here:
formatting link
This program controls the pulse width (position) of a servo by using a quadrature encoder - turn the encoder in one direction and the servo rotates one way. Turn it the other way and the servo moves the other direction.
At the moment I am on the stage where I am trying to implement debounce. When encoder is not running and there are vibrations, sometimes it counts ticks. I`ve changed my code - now, to count tick it is needed to appear both channels - but it is not enough to avoid influence of vibrations. It is common problem. Do you have any suggestions how to solve it?
I don't think this is very common. What kind of encoders are you using? Optical encoders don't actually make contact physical contact, but instead "light" shines against a disk that has slits in it with a detector behind. When the disk rotates, the detector alternately detects the presence and absence of the light.
If you are actually using encoders with a mechanical contact, I suspect you could use the same technique used to debounce a typical switch. With those, what one usually does is when you get the interrupt saying that contact has been made, you implement a short delay (a few milliseconds or so) before accepting another reading.
But that seems different than false detections due to vibration. If the encoder is not actually turning, but is still gives pulses due to vibration, I'm not sure how you'd deal with that. You may be able to tell if the pulse stream makes sense or not by verifing that the pulse stream is following the rules of actual encoder rotation. For example, if one of the encoder lines is generating pulses, but the other is not, you know that no rotation is actually occuring. In this case, would need to use an interrupt line for each encoder line like you have already done and implement a little state machine to keep track of what's happening. I might be inclined to find another encoder if that was a possibility.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.