Info on menu implementation for PIC and Graphics LCD ?

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

Translate This Thread From English to

Threaded View
Hi all,

I'm writing code for a device that has an on-screen menu. The screen is a
128x64 monochrome graphics LCD (COG). Each menu entry has sub-entries. Like

Cars| trucks | Bikes|

Cars: make,model, year
Trucks: size, capacity
Bikes: max speed, wheel size

I have it set-up so that the main entry is highlighted (reverse video). As
the user scrolls (horizontally) to "trucks" and "bikes", It gets
highlighted. If ...say "trucks" is selected, it goes into its submenu and
displays its options. I'm not sure if I'm going to do it horizontal or
vertical yet ...

I have no problems writing the code for the whole thing but since I'm just
starting, I'd like to get some more info on the actual code. The fancier I
get the trickier it gets and I don't have much time for the menu. Managers
!#$%^!!, they want everything yesterday :-)!.

Can anyone suggest a book, article or somewhere to get some info on the
actual code (I'm using C with the Microchip C compiler for the PIC18F)

Thanks a bunch.

Re: Info on menu implementation for PIC and Graphics LCD ?

Quoted text here. Click to load it

Have you looked into the various embedded GUI offerings out there?  I've
never used one but there seem to be a few around.  Might simplify the task
and get results to management quicker with less pain and aggravation.

If you have to do it yourself, here are some thoughts.

First of all, take a step back and realize that writing the code for one
version of the menu system might be a lot of work.  However, this pales in
comparison to the task of maintaining the menu --as it is sure to happen
during development.  It is important to put some thought into this before
you start to write any code or you'll wrap yourself around a pole very
nicely.  Create a simple menu on paper and think about what it will take to
support it.  Now take a few entries off a branch and move them to another
branch.  What will it take to do this?  Or, how about adding a completely
new branch to the menu that uses relocated items from other branches and a
couple of new items?  How about menu branches that are only enabled during

I hope you see my point.  Put in a structure that is maintainable from the
start.  Don't just start coding yourself into a nightmare.

As far as I am concerned, there's only one way to approach a menu structure
that has a non-trivial degree of complexity:  state machines.  You have to
use a lookup-table driven state machine to drive the whole thing.  This
state machine should call "on entry", "during" and "on exit" routines for
each menu transition.

For example, upon entry into a menu branch you might want to take the time
to compose a string or bitmap in memory.  For any user input occuring after
the "on entry" transition (in other words, you are now running whatever menu
function was selected) the "during" or simply "handler" calls take care of
whatever might need to be done.  Finally, upon exiting the branch or menu
function you would call the "on exit" routine for that menu entry in order
to execute whatever is relevant to leaving the branch/function, for example,
saving a setting to Flash.

All menu navigation, then, is pretty much automatic.  A single (and small)
body of code is required to manage navigating the tree structure.  If a user
simply uses the left/right/up/down keys, transistion functions use the
lookup table to figure out where to go and trigger the "on exit" function
for the branch to be left behind and the "on entry" function for the branch
that the system is transitioning to.  The lookup table doesn't just have to
have menu state switching data.  It can contain pointers to text strings and
bitmaps relevant to each and every state that the menu system is
transitioning through.  These items can be painted onto the display
AUTOMATICALLY by the menu state machine transition code!  A huge time saver.
How much to implement in the menu state machine lookup table is, of course,
a function of resources and other considerations.

If you do this right, maintaining the menu system will not take days but
rather minutes.  Some menu functions, for example, a "lights on/off" toggle
at the end of some branch, only need code in the "on entry" and "on exit"
functions because no operation happens "during".  Others will require code
on all three handlers.  You can have more than entry/during/exit events, but
this is the minimum that I've seen work well.  And, as long as you abstract
the user interface well enough, the system won't care if the user is pushing
buttons, using a mouse, turning an encoder or using smoke signals to drive
the thing.

Hope that helps,


Site Timeline