Stellaris EKL-LM4F232 Evaluation Kit Graphics Library Sample Codes

How about the long standing Stellaris Graphic Library?  New M4F MCUs expand upon instruction set/capabilities of past M3 - yet should run the great bulk of existing code/examples with little/no change.

hi cb1_mobile,

thanks for that info.. i think thats a good idea.. do happen to know where to find Graphic Library sample codes for M3?

cheers,

sherwin

Hi Dave Wilson,

We have an LM4F232 EVM to which we have interfaced a ETO24011DMU LCD display(240 x 320) with HX8347 LCD controller. The driver for the display has been developed with all the graphics primitives defined. We are able to display text and images on the LCD.

We are now  looking into having the menu screen on the display...very similar to the one in qs logger example. We tested the qs logger example on the display on the EVM.(cfal96x64x16). This works fine. Then, we modified the qs logger application to use ETO24011DMU LCD display driver that we developed instead of the cfal96x64x16 driver. Now, when the application is run, we can see that the TI logo and the menu appears on this display. This uses only 96x64 pixels of the 240 x320 LCD screen..(That is, whatever was being displayed on the onboard LCD(cfal96x64x16 ) now appears on the(small portion of)  ETO24011DMU  LCD. We can even navigate using the buttons on the EVM and see the outputs on the LCD)

We now need to be able to use the complete 240x320 LCD screen for display of the menus. Could you kindly guide us in this regard.

This is the curent understandng:

The menus.c uses 2 off screen buffers(which are stored in the SRAM) of size 96x64 for the slide menu widgets . Trying to increase this to 240 x 320 causes the linking to fail, since the size of the SRAM(32kB) is not sufficient to store the buffers of this size. Thus, we are unable to use the complete screen for slide menu display. We then tried allocating buffers of size 240 x 50. This causes one dimension of the display to  be used completely but not the other.

Could you kindly provide some insights as to how we could use the entire 240x320  screen for display of the menus. Are there any example applications(modifications of qs logger) available that employ the larger LCD? Also, note that we dont have a touch screen, the navigation would be using a capsense keypad..but for now we would really like to understand the various options available for being able to display the slide menu/menu widgets on the ETO24011DMU LCD ..

Thanks in advance..

Using the whole of your LCD panel should not prove difficult but I strongly suspect you will not find the menu handling system employed by qs-logger to be much help when driving a QVGA display such as the one you are using. As you notice, the sliding menu widget requires 2 offscreen buffers sized the same as the area of the screen that is to be used. When dealing with a low resolution display such as the one on the ek-lm4f232 board, this is possible because each buffer isn't very big (96 * 64 bytes or 6KB total for two 4bpp buffers). When dealing with a 320x240 display, though, you would need 320 * 240 bytes or 75KB to hold these buffers and, obviously, you can't do that if you only have 32KB of SRAM on the part.

The menu system in qs-logger was designed specifically for that application, knowing that it could use 6KB of internal SRAM as a double buffered display bitmap to allow animation of the menus. This is rather an unusual way to use the Stellaris widget library, though. Widgets are normally drawn directly into the hardware frame buffer of the display device and do not, therefore, use any internal SRAM other than the small amount required to store the widget structure itself. The downside to this approach is that you can't do smooth animation (which usually needs a double buffer or very careful synchronization of the drawing code with the display refresh).

In your situation, I would suggest you take a look at the example applications provided for dk-lm3s9d96, rdk-idm, rdk-idm-sbc or rdk-idm-l35. All of these use a QVGA display and make use of the widget library or low level graphics API to draw on the whole screen without the need for any frame buffer other than that supported by the display controller itself.

If you really want to use a menu system like the one in qs-logger, you would have to rework the code in the qs-logger example to remove the offscreen buffers and draw directly to the display frame buffer. In doing this, you would also likely need to remove the animation because the redraw rate to the display would likely be too slow for the animation to be smooth without double buffering.

Thanks for your quick and useful reply..

I have infact installed the rdk-idm and am looking into the example grlib applications..I shall get back to you in case any clarification is needed

Thanks again..

On looking into the example applications(grlib_demo, idm_checkout), I see that they are based on the Touch screen sending the widget pointer messages(WIDGET_MSG_PTR_UP, WIDGET_MSG_PTR_DOWN or WIDGET_MSG_PTR_MOVE) to the widgets in the active panel. The messages are also associated with X and Y coordinate information, and the widgets that are in this coordinate range respond and execute the application defined callback function. Is this understanding correct?

In our case, however, we do not have a touch screen. We are planning to use a keypad instead(up, down, left, right and the select buttons). Also, we would be needing a menu based UI on the 240x320 LCD display(that is, a screen having different menus that is scrollable by clicking the up/down buttons). We shall also be needing to handle multiple screens/navigations.

As stated in my earlier post, the qs_logger example does have a menu based system(for a small display screen) but that cant be used in our case since SRAM is not sufficient to handle this.

Firstly, since we need a menu based system, should we use the WIDGET_MSG_KEY_DOWN,WIDGET_MSG_KEY_LEFT,WIDGET_MSG_KEY_RIGHT, WIDGET_MSG_KEY_SELECT ,WIDGET_MSG_KEY_UP messages instead of the pointer messages? (Can the menu screen be implemented as a series of push button widgets? If so, how would we handle the up/down/select actions?).

Is there anyone who has developed a menu based system on a 240x320  display having multiple screens?(Since in the rdk-idm, I could not find any such examples).

Kindly guide us as to what approach/method can be followed for implementing such an UI on this display?

Thanks in advance,

Aravinda

As you have noticed, the current widget library makes the assumption that you have a touchscreen or pointer-based input system. It doesn't support the concept of widget focus or keyboard input in the existing widget set. Supporting keyboard and button-based input via the widget layer is right at the top of the list of changes I hope we can make but I suspect you won't see this for a while so, for now, I reckon your best bet would be to create your own set of widgets which understand the LEFT/RIGHT/UP/DOWN/SELECT messages, as was done in the qs-logger application. You can probably use the source there as a guide as to how you can do it.

If you want to use the existing widgets, you may also be able to write a fake touch driver that uses the buttons to move the cursor position and send fake pointer down/up messages to the widget manager.  When the user presses the RIGHT button, for example, you would set the touch position to somewhere within the bounds of the control to the right of the current position then, on the next SELECT press, send dummy DOWN and UP messages to cause that button to be pressed and released. Whether or not this will work will depend upon your UI layout because the touch driver would have to know where the controls were to allow the focus to be moved around correctly.