I'm trying to make a menu system for my project. I tried looking for menu libraries and they all looked like overkill for what i was doing i think. So i figured I make my own for my needs. I wrote most of the code for what i think it needs to work,but its stuck. It complies fine, but does not go beyond the main menu. If anyone is brave enough to help me or suggestion a replacement solution I would be very grateful. If i do get the code working I want to post it so other can use it too.
My project has 4 buttons hopefully more in the future and a bunch of sensors and a Serial LCD hopefully a bigger GLCD after this works. I want to make a menu system that can show different info on the screen with the push of a button. I want there to be room for expansion in the future is I wanted to add more menus or things.
My menus are
Main menu which shows the available menus to go to
COsense which shows the Carbon monoxide sensor
Temp which shows temperature
Text which shows some stored text on screen
I want each one to have a submenu maybe two, but be able to go back in the order it got there. I was thinking of setting up and array and using numbers to represent each menu and add them to the array so they can be accessed to go back to the other menus.
The main functoions in my program are
void Mainmenu; which is starting point of all menus and lets me go to other menus.
int findsmenuspot; which looks at the array "menustack" and scans for the last number that's not a zero and stores in a variable "currentmenuspot" to be tested later.
int prevmenu; which looks at the stack and sets the "prevmenuspot" to what ever is one before it so that it can be used to go back to the previous menu
int debounce; is a modified version of the arduino debounce that is a function that accepts pin numbers and debounces those pins. I left the LED portion so that i can see that the arduino receives my button push.
Template functions that are empty and will put stuff in after menus are working.
Cosense
Temp
Text
Thank you again for any replies and help.
P.S. I confirmed all my hardware is working with other test demos. So I'm sure its all in the code. You may take my code and chop it up and to test parts of it.
stripped_lcd_mult_menu.ino (5.38 KB)
I hate to read menu codes since everyone has his peculiar way of making a menu. Your code is OKish. There are a bunch of global variables messing around so it's impossible to understand what controls what. I do have library that handles menus but like you said it is one of the overkills you try to avoid, very understandable. I also have a product with the library integrated in there. Don't want to sound like I'm pushing my product but if you're interested, watch some of the videos here:
http://www.inmojo.com/store/liudr-arduino-and-physics-gadgets/item/serial-lcd-back-pack---phi-panel/
You can choose between three types of inputs, up to 8 push buttons, rotary encoder plus up to 6 buttons, 4X4 matrix keypad. You don't run the menu or sense buttons, they are all taken care of by the device. You send your menu as text to it via serial port. Too bad you bought your sparkfun-ish serial lcd already. I'd recommend mine as it is the least overkill i.e. highest menu/code ratio. For a menu that is say 150 characters long, the ratio is about 100%, so all your work is to sent the text to the device and watch it do the work 
Otherwise, my suggestion to your code:
- develop class for buttons or just use existing library. Don't do the debounce of all buttons with one function. I recommend my library, the phi_interfaces. It allows you to sense an arbitrary combination of buttons, rotary encoders, keypads, etc. and hide the detail from the menu system you write.
- properly indent your code
- find a way to scroll content on LCD cause your display will run out of space if you don't
Thank you for the reply.
So I can't use your library for this display?
What do you mean scroll the content?
How many lines of text can your LCD display ?
How many lines of text might there be in a menu ?
If the answer to the second question is larger than the first one then you need to be able to scroll the display to see all the options. It is also normal to have an indication that more menu items are available above/below or both those currently displayed.
Two lines on my display.
Right now I'm putting everything so it fits in those two lines. Later I'm going to use this code on a bigger GLCD so I can show more text.
Could I use clearscreen command to erase the text and then display the next text if i needed to? When i use clearscreen does the data stay in memory or anywhere? Do i need to do any cleanup other than clearscreen?
When you say scroll text you mean having the text move from left to right correct?
By scroll I meant move the lines up or down to show the next one although you could scroll sideways if you wanted to. However, a conventional menu would have say, 5 options and on a 2 line LCD 2 would be displayed at a time. Moving down the menu would put menu item 2 on line 1 and menu item 3 on line 2 and so on.
Using a display that cannot show the entire menu means that you have to make decisions such as will you allow the user to select items not currently on display. Is that convenient or confusing ?
A convenient way to hold menu items is an array
char* topLevelMenu[] = {"Menu item 0", "Menu item 1", "Menu item 2", "etc"};
You could use a 2 dimensional array to hold several levels of menu and move between them.
Frequently clearing the screen results annoying blinking of the texts. What I do is to set up a display buffer, the size of the entire display. Say your display has 20*4 size so you set up a buffer the size of 81 characters. Instead of writing directly to the display, I write to this buffer, same way as to a display. Then I have a timer in loop to time out every 50ms and if there is update in the buffer, which is set by a flag, then I unload the whole buffer to the LCD. This eliminates any blink or flash or unnecessary refreshing of static information etc.
If you use GLCD, you will still run out of space if you don't scroll.
I went to your code page (Google Code Archive - Long-term storage for Google Code Project Hosting.) and tried a few of the libraries out. Only Phi_Panel_big_show worked but the data was cut off on my display Is there code for a 16x2 display I could try?. Your displays have buttons on them so serial.read will sense when those buttons are pressed? So the button code wouldn't work since my display has no buttons.?
Also I can't quite see in your code how you're buffering the display I see a bunch of variable for storing text, but that's it. Could you point out which part of your code is involved in buffering please.
Thanks again.
So I spent a few hours and figured out a way to debug my code. I put serial.print(TX) where X was a number and I numbered them from 1 to 20 in order and put them down my code and I was able to see where my code was stopping or looping.
I quoted you guys in the code. Feel free to take it and use it. If you want could you/anyone take a look and see if there is anything i could fix or change to make it neater or better. I commented and indented so the code is easier to read. Thanks again guys.
Mult_menu_template_by_yigiter_izgordu.ino (16.7 KB)
I noticed I forget to change the names of some functions to generic ones and cleaned up the code a bit
and changed
if( buttonlook9==1 && buttontest9) to if( buttonlook9==1)
and deleted the unused variables. repeat for each menu.
New code posted
I forgot to mention i am using code from this example code/library from sparkfun.
SerLCD_Arduino_Example_102.ino (7.81 KB)
The sample code of phi-panel is for phi-panel only. The panel is 100X more than a dumb serial LCD. The contents you send to it get buffered on the phi-panel (notice the circuit board behind a regular LCD?). If you want to see how menus are done, you need a phi-panel backpack and a common HD44780 display. The sparkfun lcd won't understand the control characters intended for the phi-panel.
For example if you send the following to sparkfun lcd, it only displays the first bunch of characters. But on a phi-panel, a menu is rendered and you can navigate the menu with keypad connected to the phi-panel. Then your arduino can wait for a response from the panel, only after the user has made a choice. All the display buffering, scrolling and key scanning is done on the panel.
"\eFDemo menu\nDisplay\nKeys\nMulti-tap\nBuzzer\nMenu\nLong message\nLEDs\nBacklight\nPassword\nCredits\n~"
FYI, the \eF causes phi-panel to interpret the rest of the text as content of a menu, all the way up to ~
Plus, the phi-panel doe multi-tap so you can enter anything on it.