[sdiy] dave smith *instruments*

[Eric Brombaugh]

On 02/01/2010 10:57 AM, Antti Huovilainen wrote:
> On Mon, 1 Feb 2010, Tom Wiltshire wrote:
>
>> So if someone turns the rotary encoder really quickly, you can't
>> update the LCD before the encoder has moved again. This leaves you
>> having to choose between letting the LCD update finish before you
>> check the rotary encoder again (e.g. ignore the encoder) or check the
>> encoder but don't always bother to update the LCD if it's going too
>> fast (e.g. ignore the LCD).
>
> The correct way is to use a fastish (~500 Hz) timer interrupt to read
> the encoders and update the internal counters. Then the actual
> processing & display code can deal with them at whatever rate is
> appropriate. This way the worst that can happen is that some values are
> skipped over.

That's a good way to go if you want high resolution. A somewhat simpler 
approach with less resolution is to hook one of the encoder phases to an 
IRQ. When you get an interrupt, debounce and check if rising or falling. 
If rising, the state of the other phase indicates if you need to 
increment or decrement the controlled parameter. Exit without update if 
falling.

If you're using encoders with detents this yields one pulse per detent 
which is probably all you really want. If you've got continuous encoders 
then Antti's suggestion is probably the better approach since it allows 
the rotation to stop anywhere and still take advantage of every 
transition on both phases.

As far as priority, I agree that the encoder update should always come 
ahead of the LCD update. Who cares if the display lags a few ms behind 
the actual parameter change? The effect on the sound is more important, 
and if it's changing quickly all you see is blur anyway.

Eric