Menus on 16x2 line LCD.

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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
In Hope.
J. Casey.

Re: Menus on 16x2 line LCD.

Quoted text here. Click to load it


Quoted text here. Click to load it

Niall Murphy's "Front Panel" still appears to be in print, and has a
lot of good ideas to help you.  A new copy from Amazon is about US$35,
used starts at US$16.  Not sure where you'd find it in Ireland,
though.  ISBN: 0879305282


Change is inevitable, progress is not.

Re: Menus on 16x2 line LCD.
On Mon, 15 Sep 2003 20:23:56 GMT, (Dave Hansen)

Quoted text here. Click to load it

In Ireland the easiest way is to purchase through, but if
that fails you can contact me directly as,
        Niall Murphy

See the User Interfaces for Embedded Systems Page

Re: Menus on 16x2 line LCD.

Quoted text here. Click to load it


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

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


Re: Menus on 16x2 line LCD.
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
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

You can also make simple JavaScript mimics:

Product review:

Re: Menus on 16x2 line LCD.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Site Timeline