Info on menu implementation for PIC and Graphics LCD ?

...

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 development?

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,

-Martin