1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Info on menu implementation for PIC and Graphics LCD ?

Discussion in 'Embedded' started by Rodo, Feb 19, 2005.

  1. Rodo

    Rodo Guest

    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
    this:

    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.
     
    Rodo, Feb 19, 2005
    #1
    1. Advertisements

  2. Rodo

    Martin Guest

    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
     
    Martin, Feb 19, 2005
    #2
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.