Products > Programming

Simple menu system with dynamic keypad functions (embedded alphanumeric display)

(1/2) > >>

ricko_uk:
Hi,
how can I implement a multi screen system with a menu at the bottom where every screen the keys labels on the display change (according to the specific screen functionality)?
Something that can be quickly implemented and easily maintained.

I am looking for infos about both setup and functionality details as well as data structure.

Ideally (although this second point might be separate to the above implementation) to also have keypad autorepeat functionality that has faster autorepeat rate the longer the user keeps the menu keys pressed.

I googled it but couldn't find much. Maybe I was searching for the wrong terms. Any pointers to tutorials/resources are welcome. :)

Many thanks

ricko_uk:
Any suggestion anybody? :)

Any input would be greatly appreciated. Thank you inn advance :)

dmills:
That sort of thing is usually sufficiently application specific that general purpose code has limited use.

What I generally do is have a mess of static const structures.

One per menu entry that has the text string, a menu type enum, maybe some min, max values and such and union of a couple of different pointer types, one of which is a pointer to a child menu, and one is a pointer to an editor function, call this struct menu_entry. 

Then you have struct menu that looks something like this :

struct menu {
    char * title;
    struct menu_entry entries[8];
    struct menu * parent;
 };

By using named initialisers it is easy to build the menu structure :

struct menu menu_toplevel = {
    .title = "Top level",
    .entries = {
        {.label = "foo", .child = &menu_foo, .type = MENU_SUBMENU},
        {.label = "bar", .child = &menu_bar, .type = MENU_SUBMENU},
        {.label = "baz", .child = &menu_baz, .type = MENU_SUBMENU},
    },
    .parent = NULL,
};

Then your menu driver code simply maintains a pointer to whichever menu is currently being displayed.

You can of course extend this sort of thing to add function pointers for specific actions and per item parameters, one that is often useful is a offset into a configuration structure of some sort (the offsetof macro is your friend!), that way you can make the menu handle annoyances like toggle options and small integers without needing to specialise every stupid editor function.

But really, you know your architecture, menus systems are fairly trivial things.

One slight trap, data driven is the way to go, but remember to design in enough space to cope with the weird edge cases.

ricko_uk:
Thank you Dmills, I like that approach! :)

Could you elaborate on your line "One slight trap, data driven is the way to go, but remember to design in enough space to cope with the weird edge cases.". Can you give me perhaps an example or two that happened to you so I know what to watch out for?

Thank you again :)

obiwanjacobi:
If your RAM is limited check how you can put those literals in flash (like PROGMEM in Arduino).
They can really add up and eat a lot of storage.

[2c]

Navigation

[0] Message Index

[#] Next page