Hi,

I am looking for simpler examples for code for a menu to be used together with a LCD-display.
Some example that could guide me in how I should think.
So if anyone have any I would be eternally grateful =)

So for example a statemachine approach or a lockup table approach to the menu or something like that..(?)

FYI:
I am using this settup (but any examples do not necessaraly have to be for this settup of course).
microcontroller:
Atmega4809
display:
128*64 graphical display (I am planing to use 6 rows in the menu)

 

Welcome to AAC.

1) When you say menus, I assume you mean drivers. Or, do you mean something else? Do you want to just print characters or graphics too?

2) Why do you want to use only 6 rows of a display that probably has 8 rows/pages?

3) What controller does that display use? There are differences. What is your interface -- parallel or serial? If serial which one?

4) Language?

 

First of all: thank you for your answer =)

1.I mean the code that is deciding how the lines of texts in the menu should be writen on the display when you press the up/ or down or enter key. I guess that would be called driver (not the most experienced programmer here as you migh see =)

2. good question.. yes, it should probably say 8 rows. What I meant to say is that there are several rows (so any example code for 1 row menu is not going to work).

3. it uses SSD1305z. But I have the display working (I can print text on the diffrent rows of the display). it is more how I should setup the code to control what text should be shown when in the menu when you stepping thru the menu system that is my problem.

4. I am programing in C (using atmel studio).

 

P.S.

1. only characters

3: it is using some kind of version of SPI (without MISO). But as I said the display I have working already.
The question is now how I should design a menu for this display,

 

Unfortunately, that controller is enough different from the ones I have used that the routines I have wouldn't be of much help. My routines are also in PIC Assembly.

For others who will pitch in, here is a link to the datasheet: https://cdn-shop.adafruit.com/datasheets/SSD1305.pdf

In general, after you write to one row/page, you simply set the address to another page. That controller wraps pages (unlike mine) so another alternative is to just add spaces to advance to the next page. The SPI interface will not allow you to read a byte, modify, then re-write.

Sorry I couldn't be more help. It looks like the built in scroll functions in both X and Y will be quite helpful.

 

If your proposed menu is anything but simple the code can get very complicated.
You may be able to hack some of this Arduino code. At least it should give you some idea what is required.
https://www.google.co.uk/search?sou........0....1..gws-wiz.....0..0i131.hakDvb1_Jxk

 

I found menu structures should be as clean and brief as possible, and
use hierarchical structure. But no more that 2-3 deep if possible.

I also in code move blinking cursor from one menu item # or letter to
another, so cursor not all over the place. Assuming you have no keyboard.

Its tempting to pack a lot of menu items onto one screen, thats ill advised as well.
And there should be, in addition to cursor move up/down button, and escape button
that takes you to top level of menu, or exits menu. And a separate button to select
item. I like adding buttons vs everything is done with one button. Like trying to run
an aircraft with one button, could be done,
but I am not going to get into it.

Colors important, I have seen some horrible color choices that make one want to
puke. Clear text and contrast is order of the day. Red on green text, use a sledge
hammer on the product, ech.

Regards, Dana.

 

ok, thanks for tips! =)

dana: you don't happen by any chance to have some example code I guess? =)
also, do you think it's better to have a switch case approach or like a state machine approach for a menu? (I have seen both on the internet, but usually, the code is not complete or too complex to follow for me)

 

The code I have is C, for a character display, and UP architecture for addressing
had unusual addressing, so I think code would be useless for you. Its becuse the
UP had diffrent addressing fro RAM and FLASH, so pointer structures were a tad
involved.

Its not complicated to do the buffer for a char display, a graphic might be a little more
involved because x y positional stuff complicates. That being said a graphic display
has a refresh period where writes could be done so that a separate buffer might not
be needed. Keeping in mind most graphic controllers either have the buffer in them or
map out to external memory, eg. already have a buffer. You would have to write a
simple trial test to see how display appearance looks, to see if that specific controller
has any sensitivity to artifacts due to asynch writes. This of course applies top a tight
loop always writing to display asynch.

I used case statement for top level of menu system, then conditionals for any sub level
menu stuff. That seemed, at the time, most appropriate. State machines fun if you have a
GUI wizard tool in IDE to do them. But from scratch I might think twice about doing
them if menu system has any depth.

Regards, Dana.

 

I am not sure of your terms. My code is in these basic sections:
1) Basic commands: PutCMD and PutDat which are routines to direct the GLCD. For speed, I find it helpful not to exit the write protocol until the end. I just toggle the CMD/Data bit. That is, I use instructions such as "PutCMD+3" to avoid the set up for multiple writes and PutExit to finish my writes.
2) Functions: PutPage(or Row) and PutColumn for navigating the GLCD Screen, which call the PutCMD routine.
3) Putting actual data: That calls the PutDat routine.
4) PutChar or PutText: That is either stack-based or FSRn-based to get the characters and put them where intended. My GLCD's don't have built-in character sets, so that refers to a large table for data. Those instructions use both PutCMD or PutDat as needed.

Since you are not doing graphics and have a built in character set, you will probably not need #3 or most of #4.