Re: Using menu with rotary encoder

On Tue, Feb 14, 2012 at 2:50 AM, Markus Dolze <[email protected]> wrote:
> Hi,
>
> a few weeks ago I got a cheap rotary / torque encoder and I wondered if I can use the LCDproc menu with it.
>
> There was some discussion about this years ago (http://lists.omnipotent.net/pipermail/lcdproc/2006-January/010369.html) but I didn't find any final result.

As one of the parties in that conversation, I don't remember any
practical results.  I had not yet done much AVR work, so while I did
discuss using a wee microcontroller, it was before the massive AVR
explosion of the past few years.

> Anyway, hooking up a rotary encoder to the parallel port is no good so I made a little AVR project (another subject of its own).

Indeed.

> Unfortunately the menu system currently requires a menu/escape key and enter key to function properly. Therefore I made a small change that:
>
> a) Changes the order of precedence of the menu and enter key while you are in the menu.
>
> b) If the enter key is the same as the menu key adds a 'back' action to the end of each menu that brings you back one level or exit the menu.

OK.

> Unfortunately it is not possible to have an 'escape' key with this setup so there is no way to cancel input. But this makes menus work with only two keys!

That's certainly a start.

> I thought of using some time based mechanism to simulate an 'escape' event, but that seems to be difficult within LCDd.

Having gone back and read the thread from 2006, have you considered
having the AVR monitor the timing between encoder button presses, and
if it's over 1 second, send back an escape key event?  Don't make LCDd
worry about the timing, let the AVR handle it.  I remember proposing a
single click, a rapid double-click, and a click-and-hold as being
three different "keys".  LCDd wouldn't know or care what the human
pressed and in what order - it just sees three unique keys.

> Patch attached. Your opinion? Do you think it is useful?

Can you provide a pointer to your AVR project?  I am generally in
favor of the idea, but I'd like to see it in action.  I have rotary
encoders (the one I mentioned in 2006 ended up being built into a
Spare Time Gizmos 8051-based MP3 player kit, along with a 20x4 LCD).

One thing in particular comes to mind about this idea - we clearly
have and can support home-grown hardware, but we don't have a way of
really integrating hardware extensions into the project -
specifically, for the rotary-encoder device, presuming it's
open-source as well, how to publish the code and schematics and build
instructions _with_ LCDproc.

In the early days, it was enough to publish ASCII-art schematics and
pinouts for direct parallel-port attachment of HD44780 and some
graphic-controller modules.  Now that any sort of module practically
requires a PIC or AVR between the LCD module and the machine running
LCDd, there are a number of projects out there that one could use,
several of which have LCDproc drivers, but if the creators of those
modules stop supporting their creations and pull down the web pages,
we have drivers for which people can't buy or make the hardware.  If
we create a way to provide at the very least the microcontroller
source code (with permission, of course) with LCDproc, then future
builders would have some place to start to build a compatible
interface if the original was no longer available.

One thing, for example, that would belong in an LCDproc hardware
project repository would be an Arduino sketch that implements the
Matrix Orbital command set so that someone could take an ordinary
Arduino, add an LCD shield, then compile up the sketch using the
standard LCD library with pin definitions to fit their hardware, then
select the MtxOrb driver in LCDd.conf and have an instant DIY
supported LCD module.  I know I've seen Matrix
Orbital-command-set-compatible code out there, or one of us (including
me) could write one specifically for inclusion with LCDproc.

I think rotary encoders are cool and we should support them.  We
should also make it easy for folks to build their own hardware to go
with the software.  We should also support additional types of DIY
hardware as well.

-ethan