User interface for text mode LCD display

Question

Does anybody know any resources on this subject?

I'm developing an embedded application for 2x16 LCD display. Ideally I would like to have a general (display independent) framework, that could be used virtually on any display - one or more segment(s) LED, 1x16, 2x16 LCD, etc. Also would like to learn about general guidelines for such small user interfaces.

EDIT: I'm interested in high-level functionality, how to organize the user interface - the menus, options and the user input. We don't dicuss the LCD controller issues here.

Answer 1

If you're referring to a 2 line by 16 character display, they'll generally be pixel based and will have an integrated controller as they're much more complicated to control. The 2x16 and 4x16 LCD devices I've used in the past actually have a nibble-wide interface, and the commands are sent to the device in <command>[<address>][<data>] style, with the number of nibbles required for a valid command being dictated by the command itself. If would be helpful if you link to the target device as there really doesn't seem to be a standard from manufacturer to manufacturer.

With respect to segmented LEDs and LCDs, there is a standard layout for so-called seven segment devices that started back with the pixie tubes. Here's a diagram that shows this segmentation:

   a
  ---
f| g |b
  ---
e|   |c
  ---
   d

Another question is whether you want to drive the display directly or will use a controller IC. It's pretty easy to drive a seven-segment LED as they generally have a common cathode or anode and you simply need to be able to sink or source enough current. Driving an LCD directly is a little more complicated as the polarity applied to a pixel or segment has to constantly flipped to avoid damage to the device. It's much easier to find a controller with an integrated clock that performs this function.

Answer 2

I would design it for a single-line interface, using more lines would give you more space.

I would go for at least 4 buttons:

• MENU
• UP
• DOWN
• OK

If you specify the line width (like 16), then this would work for 16x2, 16x1 and 16 7-segment displays.... and you would take that into consideration when designing the text on the menus.

The UI would be more useful if you add more buttons, I would think about these, ordered by priority, but these are not essential:

• LEFT & RIGHT
• NUMERIC KEYS
• QWERTY

You would have a main menu, that would take you to nested submenus or action items.

I'll give an example, let's assume you're doing a digital clock that would work on 16x1 or 16x2.

The main screen would be something like 08:15P SUN101908 when you press the menu key, it will show a menu (Set Time, Set Date, Set Alarm,Set Display), with UP&DOWN to move the item, and OK to select an item.

If you select "Set time" the UP and DOWN arrows will change the hours and OK will accept and move to the minutes selection ...etc.

If you had a numeric keypad, it would be simpler to use.

Answer 3

I don't know of any "project" or library built for this explicit purpose.

I recommend that you take the approach of having a "display layer" code that operates on the concepts of screens and fields. The screen is responsible for "owning" all the fields on the screen, and the fields are responsible for specifying what is displayed, and what variable the field affects, and the input method(s) to affect the field values. The fields also store any function pointers to pre- and post- field setup/validation functions.

Doing this will help you maintain a fairly consistent UI. The code will also be concentrated in one spot, so it's potentially easier to debug.

Answer 4

A nintendo like controller is simple to make and can be used for almost any application. All you need is 8 keys; 4 for the D-pad, 2 in the center and 2 for A and B button. Creating this kind of controller is very simple, and for the user it is pretty intuitive. It is also something the user can hold in their hand, making it a lot more user friendly than a mounted control.

Answer 5

I think the differences between 1x16 and 2x16 LCDs are so vast that you shouldn't strive to create a GUI library that can handle both - just like you don't try to create a GUI library that can handle both CURSES and Cocoa as backends (well, someone did, but it's... wrong).

Whith so little display, your GUI should be very domain-oriented... that is, I cannot tell you what would be good concepts without knowing what your domain is.

Answer 6

The size of the display will have a huge impact on the user interface.

1 line is only big enough to a single level menu, although I think even that is pushing it. I would have all the functions as buttons and the display only for showing data.

2 lines is enough for a multilevel level menu. In menu mode the top line is used for indicating where they are in the menu tree, and the second line can be used for menu choices. I wouldn't recommend many levels to the menu or the user will forget where they are and also have trouble remembering where things are in the menu tree. In function mode the top line can be used to indicate the selected function and the second line the data. You can get away with up down menu ok for the buttons but I would think about still ahving buttons dedicated to functions.

4 lines is good for a menu. Similar to the above with layout, and the extra lines help the user to remember where they are in the menu tree. It helps them to visualise it spacially. In this case I would recommend the up down menu ok button, and no specific function keys. Specific function keys sometimes confuse the user with respect to the menu paradigm.

I would not bother with numeric keypads for the 1 or 2 line displays, and forgo the QWERTY keyboard altogether. If you can afford the real estate to put this many buttons on the front then you owe it to your users to have a bigger display! Imagine QWERTY with a 1 x 16 display. Ridiculous. The complexity of the UI should reflect the complexity of the device.

Consider Osama's example of the single line clock. This can be realised with two buttons and no menu. The buttons can be called 'set' and 'adjust'.

Operation would be:

1. normal - display shows time and date: 08:15P SUN101908
2. alarm - press 'set' - display shows alarm with hours flashing, pressing 'adjust' increments hours, press set again to change minutes, again to change on/off status. eg: AL: 08:00 off
3. press 'set' again (or press and hold set) same thing happens with time. Also not pressing a button for a certain time times out the menu.

A numeric keypad would be overkill and from an engineering point of view more hardware and more cost. This is why there isn't numeric keypads on alarm clocks.