Menu Routines on a 4x20 LCD

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does someone know how to programm a menu for an LCD?
The user should be able to scroll through the menu, to change settings through this menu and to execute functions. I programmed one but it never worked really good. So does someone a good solution?

Regards,
Tobias

Hava a look at my web page -> http://www.tobiscorner.at.tf

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the same problem to solve either if you can send-me your code that works badly to see what i can do to improve your code

Regards,
Cláudio

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The LCD menu section should be the the main part of the program, it can be a loop
sitting and waiting for an instruction from the key pad. When a key is pressed,
you jump to a subroutine for that particular funtion. Perform whatever function or
action that is required , then return from subroutine.

This always brings you back to the main section of the menu. You can have nested
subroutines, just be sure to remember how many are open, and return from every one, or you'll stack overflow eventually, lost in never never land.

I program in Bascom, you didn't mention the language of your choice.

Dennis

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

U can see

http://www.ibrtses.com/embedded/...

Regards,
Marco

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've imporved my own code, through minimizing RAM usage. That lot of RAM i needed made my programms crashing.

First i'm programming with the AVR-GCC Compiler and i do not want to learn the AVR assambler. I'm using a structure that represents a line in the menu.

struct tagMENU {
unsigned char str[21]; ... Here is the Format String stored
uint16_t value; .... default / current Value
uint16_t bottom; .... the lower border
uint16_t top; ... the upper border
uint16_t step; ... step width
unsigned char command; .... keys to react with
void (*read)(struct tagMENU *x); ... pointer to function to read current value from hardware
void (*update)(struct tagMENU *x,int y); ... pointer to update function like toggle, or updownint
void (*exec)(unsigned int reg); ... pointer to function that writes the value back to the hardware
};

Thats the sturcture.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An alternative way of handling menus if you dont want the processor to be tied up is to use a re-entrant key processing system. This enables the key to be processed and the processor released for other duties between keystrokes. This uses an interupt driven key entry. This is called by if (key_pressed) process_key();

Then inside the routine the system is divided into two sections - action1 and action2. Action1 occurs first and usually consists of multidigit or single digit number entry and the second action is what to do with this number. Because it is reentrant there must be information kept about what is happing. Typically this would be (command_being_processed, position_in_processing_chain, first_action, second action, minimum_allowable_number_value, maximum_allowable_number value).

Action 1 usually falls into three categories - menu display/scroll, multidigit number entry, single digit number entry. The second action usually invoilves the prompt for the next stage in the processing.

This enables an extremely flexible menu structure that allows each menu stage to be totally different (eg mneu item 1 might be 'Turn On Channel' 'channel number', while menu item 2 might be 'Set' 'Time' 'DD YY MM' etc. and menu item 3 might be 'Enter System Name' 'string'.

The only drawback is that typically you require about 3 bytes of eeprom for each menu item/stage and then you need SRAM of about 8 bytes to monitor the stage of command processing.

The big advantage is that this frees up the processor while you are waiting to enter the next digit. This is still a probelm in interupt driven systems if you have interupt routines and non-interupt routines accessing the same peripherals (eg TWI and SPI devices). In this way only the hardware itself is interupt driven and all proccessing of the information from these interupts is done in the main processing loop. This would not be able to occur if you tied the processor up in keybaord entry

Lachlan