LCD+keyboard user interface with RTOS

Guest · Posted: Sat Jan 27, 2007 1:33 pm

Hi there.

I am planning to use the CCS RTOS for a device that has signal aquisition, data processing, a user interface with LCD and buttons and a serial communication port, a perfect job for RTOS at the first look. I have never worked with RTOS before, but I learned and understood the basics quickly. I am working with the 18F452.

My great difficulty is implementing the user interface, so that the data aquisition and processing executes in the background while the user browses the menus and reads/modifies parameters. Until now I implemented menu structures with functions for every menu option available. Of course, the menu had several levels. Periodic processing of signals was done with timer interrupts. Very easy to do in normal programming. But with CCS' RTOS I just have no idea about implementing this menu-based user interface. Can anybody give me an idea to start with? Thank you.

future · Joined: 14 May 2004 Posts: 330

Can you tell us more about your menu handling algorithm?

You could create a button handling task that calls the current menu function.

VanHauser · Joined: 03 Oct 2005 Posts: 88 Location: Ploiesti, Romania

Seems I forgot to log in when I started this thread Embarassed

Anyway, my old menu structure is something like:

future · Joined: 14 May 2004 Posts: 330

You can setup a 10mS menuMain() task to call getKey() and rtos_yield() in case of K_BACK.

Also you can enable/disable this task by using the rtos calls, so you can enable it when the user presses the menu button and disable itself in case of
K_BACK.

You must remove the infinite loop.

I am very interested in your code. I have tried two or three ways to implement a complex (50 screens) menu tree.

VanHauser · Joined: 03 Oct 2005 Posts: 88 Location: Ploiesti, Romania

future · Joined: 14 May 2004 Posts: 330

I did a menu renderer routine that would accept a pointer to a linked list of 'widgets'. These widgets have their behavior dictated by their own routines.
Any text, label, editbox or button action on the lcd has to be added to the list and sent to the renderer routine.
The code is for C30 and relies on pointers heavily.

The other way was to build a BIG array with all your strings, where-to-go, variables to edit... And just 'navigate' this array throught the buttons.

The results were satisfatory but I did not like them.

Any new screen takes some effort to implement.

Now I think that the best way is to navigate the system throught functions.
Each function can do anything, be completely different from the others and have total control over the system.

I am just starting on user interfaces, but I am doing my homework.

VanHauser · Joined: 03 Oct 2005 Posts: 88 Location: Ploiesti, Romania

Well I am not using graphics, just a 2x16 LCD so it should be easier.

I thought about nested struct's containing the menu tree with all details, but I think it would be too much for my PIC. In my menu I have to enter just floats and integers. I am now working at two general tasks that ask the user for a float and a int respectively and another task that shows menu options.

Another idea that popped into my head is to use a second PIC just for the user interface, without RTOS.

future · Joined: 14 May 2004 Posts: 330

I am doing a user interface at the moment and using the switch method with success.

The final code is big, but it is easy to modify if you structure it correctly.

Have your interface running on a separate task, another one for button debouncing. You will never lock inside a function.

A single switch(menu) and a switch(submenu) can do a lot.

Also don't use menu--; or submenu--;. Use menu = MENU_MAIN or something else.

I hope you understand.

VanHauser · Joined: 03 Oct 2005 Posts: 88 Location: Ploiesti, Romania

I have been working on that interface for a while now and it works much better than expected. Multilayered menus and everything, with recursion. It's very easy to add a new option or a parameter value once you have figured out the interface engine. Menus and parameters are identified by their IDs in a switch.

I have 5 tasks for this interface: menu/selection display, float input, int16 input, int8 input, button debouncing. Menu task is stopped when a value input is demanded and the corresponding task is started, and after that finishes it resumes. Button debouncing runs permanently.

ROM and RAM consumption is HUGE indeed, but the results are good.

future · Joined: 14 May 2004 Posts: 330

I've been thinking about a stack based menu system.

This would ease the management of deep menus and allow any sequence of screens.

There is no code yet, just a thought.