Menus on 16x2 line LCD.

I have built a control panel having 2 x 16 char LCD, 16 button numerical

keypad controlled by 68HC11. I have a series of menus for entering process settings. The menus are navigated using up, down, left and right

arrows - similar to mobile phone menus. Mostly the menus consist of a title on the upper line and editable numerical value on the lower line. The problem: At present I have ten simple menus. Navigation is clunky and the code is

becoming spagettilike. I also would like submenus. I am using assembly language and can give about 1K bytes to the menu part of the program. Is

there a clever way to do this? I am hoping there may be a standard way to do it, or that I will get suggestions for giving structure to the process. In Hope. J. Casey.

Hi,

Don't know about a standard way, but think data structures for menu nodes, even if you are writing in asm. Have a short, simple piece of code to drive the menu and the menu description / presentation defined (for example) as tree structured linked list of const data structures, which can be of arbitrary no of entries, with any node entry pointing to another. To keep it simple and to save table space, you make the tree singly linked, with a node address stack so you can retrace back up the tree.

An early version of this idea was around a page or two of 6502 assembler (long ago re-written in C as a state machine) that initially waits on startup for a keypress at the root node, then depending on flags set at that node, you either execute a function, move down the tree to another linked node, or both, then wait for the next keypress. Variants of this can include calling a function on entry to a node etc etc. The advantage of all this is that it's trivially simple to implement in C or asm and can thus be verified by inspection and made bulletproof. It's also inherently structured and is easy to add functionality to without major redesign, but it does require a bit more effort up front to get the basic framework in place. The application is defined by the menu tables, not the code and you only need to deploy a single instance of the menu code itself, not a copy of the same code all over the place which is how some menu systems seem to be written. Usefull builtin functions might include escape to previous menu, which requires only a node stack pop and re-enter the key wait loop. The four arrow keys of your application could also ideally be menu driver built in functions.

Initially, you can get the menu driver itself written and debugged with say a few nodes and the function calls stubbed out, then incrementally add nodes and functionality. The contents of each node structure may vary, but typically would contain the menu header string, no of items at that menu node + text strings and space for flags for each entry, pointers to next nodes, function calls etc.

Don't claim originality for any of this, but has worked well for me and bought me lunch over several projects over the years...

Chris

I had a similar problem with a top of the range hi-fi amplifier. It had a 2x20 char VFD and a quadrature rotor to adjust parameters.

As usual, management wanted features at odds with each other: it had to be simple to use but capable of controlling many parameters.

I took time to carefully think out how What I did was to have an 'iceberg' of complexity: i.e. normally just a small part of it is visible.

By default, the "Volume" screen was visible. The 'select' button toggled between that and the "Balance" screen. So that satisfied the 'simple to use' specification.

Pressing a certain two-key-combo would enable more screens in the selection cycle. These allowed many set-up user-selected parameters to be adjusted. These are seldom needed so it makes sense not to present them to the user all the time.

A 3-key combo would enable technical screens the user would not normally want but a technician would. These allowed inspection of RC5 remote-control codes, and 'black box' so you could see if it had experienced thermal or RF faults. So it became its own test equipment in a way. :-)

It proved a very practical method, and was used in other products.

This page is handy as a basis for trying out screen layouts that you can show to others via email for approval (without having to post them your real equipment!)

You can also make simple JavaScript mimics:

Product review:

In Ireland the easiest way is to purchase through amazon.co.uk, but if that fails you can contact me directly as snipped-for-privacy@panelsoft.com, regards, Niall Murphy

=========================== See the User Interfaces for Embedded Systems Page at

The simple and pretty clear way is to have one or several sheets of parameters and view those sheets by moving 2x16 window on them.

More or less sensible user interface system will cost you several kilobytes at least.

There is no silver bullet, it is all application dependent. The fundamental truth is that it is very difficult to built a sensible user interface with 2x16 LCD. Many people have been there.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant