Re: Using menu with rotary encoder

Hi,

On 15.02.2012 17:16, Ethan Dicks wrote:
> On Tue, Feb 14, 2012 at 2:50 AM, Markus Dolze <[email protected]>
> wrote:
>> 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.

This sounds like a simple yet effective solution. To admit, I didn't
thought of that.

> 
>> 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).

Will do, but it needs some cleanup before. Basically I put together some
existing libraries (Peter Fleury's LCD and UART libraries, the rotary
encoder stuff was from some other site) and only a few lines of own code...

> 
> 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.

That's a good point. Actually a number of 'projects' supported by
LCDproc have gone into the attic of time. One may be able to recover
information from The Internet Archive, that worked 95% times I tried.

However, I don't like to distribute hardware project stuff with LCDproc
itself as pulling in code actively developed externally will be quite a
task to handle. We already have hardware related code in the tree which
only a few people are aware of (i.e. docs/Seetron/).

Putting a static archive copy on our web page may be an option.

> 
> 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.
> 

Yes, but there are some exceptions. For example will I not add another
AVR project as we already have some of them. And for the same reason I
made my rotary encoder use the LoS-Panel protocol.

Regards,
Markus