Anyone else developing a user interface (UI) on LCDs and keypads/buttons?

The only thing stopping that would be the size in memory to have all the user defined characters to be passed on to the LCD. :\

There are ways round the limited number of characters...

I may have not explained myself correctly... I was talking about the size in Arduino's memory to hold the user defined characters... any formulas to create those characters that avoid the use of char arrays in memory?

Yes, create them in PROGMEM:

PROGMEM prog_char lcd_ch0[]={ 4,14,31,64,31,31,31,31,0};// Up triangle with block
PROGMEM prog_char lcd_ch1[]={ 4,14,31,64,64,64,64,64,0};//Up triangle 
PROGMEM prog_char lcd_ch2[]={31,31,31,31,64,64,64,64,0};// Top block
PROGMEM prog_char lcd_ch3[]={64,64,64,64,31,31,31,31,0};// Bottom block
PROGMEM prog_char lcd_ch4[]={64,64,64,64,64,31,14, 4,0};// Down triangle
PROGMEM prog_char lcd_ch5[]={31,31,31,31,64,31,14, 4,0};// Down triangle with block
PROGMEM const char *ch_item[] = {lcd_ch0, lcd_ch1, lcd_ch2, lcd_ch3, lcd_ch4, lcd_ch5};

I’ve already made a scroll bar. Please watch some videos on the link I provided. There’s only enough customized characters to create a rough scroll bar though. Dynamically shoving customized chars back and forth is too much work.

It's still in memory, isn't it?

It's in program memory (aka Flash) not in data memory (aka RAM), so it's still using resources but one that there is more of.

bubulindo: It's still in memory, isn't it?

So what is your point? Where would you store these data?

sixeyes: It's in program memory (aka Flash) not in data memory (aka RAM), so it's still using resources but one that there is more of.

Besides, the SRAM character array that is used to temporarily store the customized chars is in the init function so I suppose once that function exits, the array is gone and SRAM recovered.

Besides, the SRAM character array that is used to temporarily store the customized chars is in the init function so I suppose once that function exits, the array is gone and SRAM recovered.

Correct - all that's needed is initialisation of those characters and then they are stored on the LCD, a simple request for that character to be written then recalls it from the LCDs memory to write to the display.

Just added new line to long message display so now you can start a new line in a long message display with '\n'. Didn't know that would take me so long I was dreaming about it last night and figured it out this morning.

As you can see the first two lines have "new line" symbols '\n' after the last characters. I didn't put exact space to make it look like the picture!

It was not easy for something that probably nobody will ever notice.

Hi All

What a nice thread. @liudr: Thanks for pointing out this thread.

So, to answer the inital question: I currently work on a graphical user interface. It will be GPL, it is hosted here: http://code.google.com/p/m2tklib/

History: Sept 2010: Idea came up, as an addon for my dogm128 library Okt/Nov 2010: Research on existing user interfaces: Not much open source, not specific to embedded systems, poor documentation. Except liudr's phi-prompt lib, but at that time it only has focus on text displays. Nov 2010: Start working...

Goals: - Licensed under GPL - Small memory usage, original target was ATTINY with 16KB Flash, leaving enough space for the application itself - Widget based approach (like any other major GUI), widgets are called "elements" inside m2tklib - Message based communication - lib itself in C, but also C++ API (full Arduino IDE integration) - Portable according to any inputs (including a debounce algorithm), also portable according to the number of input buttons. - Portable according to the display output: Support for Dogm128 lib finished. LiquidCrystal works.

Status: Not yet released something, documentation is online (mostly). If there is some interest from community of this board, i can provide a alpha release.

Oliver

m2tklib example

here are some elements (widgets) arranged within the gridlist container (c2 = two columns)

M2_LABEL(el_label1, NULL, "red"); 
M2_RADIO(el_radio1, "v0", &select_color);  
M2_LABEL(el_label2, NULL, "green"); 
M2_RADIO(el_radio2, "v1", &select_color);  
M2_LABEL(el_label3, NULL, "blue"); 
M2_RADIO(el_radio3, "v2", &select_color);  
M2_BUTTON(el_cancel, NULL, "cancel", fn_cancel); 
M2_BUTTON(el_ok, NULL, " ok ", fn_ok);  
M2_LIST(list) = { &el_label1, &el_radio1,      
&el_label2, &el_radio2,       
&el_label3, &el_radio3,      
&el_cancel, &el_ok  }; 
M2_GRIDLIST(list_element, "c2",list);

results are portable accross different output devices: dogs102 (dogm128 lib):

16x4 LCD (LiquidCrystal Lib):

Oliver

Neat :D

Awesome! The code reads similar to java. My ultimate goal is to create something like a dialog or panel, with multiple inputs of different types, much like a dialog you see in java dialogs.

See this one I found randomly online:

There are lists, number entries, radio buttons, text entries and several buttons. Apparently I'm not going for their level of visual details but a rough text-based version.

You can use left/right or a tab to move among the fields on the panel and change values here and there.

liudr: There are lists, number entries, radio buttons, text entries and several buttons. Apparently I'm not going for their level of visual details but a rough text-based version.

This is what I wanted to do. m2tklib is expandable and in principle able to support any kind of input fields. Currently I have text input, radio/checkbox buttons, number inputs, normal buttons with several features (see here http://code.google.com/p/m2tklib/wiki/elref)

There are also different container "widgets" which allow different approaches for the layout of dialog boxes. So except for the combo box, you could already implement the "page setup" dialog box.

The appearance of these elements has been separated from the dialog specification itself. It is the responsibility of the graphics driver to add some nice shadow borders or similar things to the elements.

Oliver

Impressive. I'll take a lot of time to catch up with you. BTW, my documentation is final finished, after 33 pages. I sincerely hope someone will read it :sweat_smile: :D

What i have seen so far is, that your phi-lib is a well known standard here. Well documented and proven in use. For any text based LCDs the choice #1. Additionally, some features like scrolling will probably never go to m2tklib. And finally, there is no release for m2tklib. While i hope that i can finish it soon, it is still vaporware...

olikraus,

That was flattering. My library is not really a standard of any sort. I do have a decent manual though :D I've used LCD for quite some time and didn't see any libraries of user interface. I struggled to make my own and think lots have gone and will go through the same struggle so I made this library. It's anything but perfect although currently it's the only one posted here and on playground. Please forge ahead with your development. I will probably make a new release after the summer is over if I finish everything I plan to finish over the summer.

Hi

First version of M2TKLIB is finished

see here: http://arduino.cc/forum/index.php/topic,65653.0.html

Project URL: http://code.google.com/p/m2tklib/

Oliver