Compiler/TM4C123GH6PGE: ListBox Widget in TivaWare Graphics Library

Hi Jame,

  Unfortunately, we don't have any examples. We also don't have expertise with the Listbox widget creation. The user's guide is your best source of information on how to create the widget. I have also searched e2e forum for any posts relevant to this subject and came across this post that might help you. Please take a look. https://e2e.ti.com/support/archive/stellaris_arm/f/471/t/222582?tisearch=e2e-sitesearch&keymatch=listbox

  If you can get the ListBox widget to work, please do share with the community as it will benefit anyone who is looking for the same solution. Thanks!

Hi Charles

Thank you for your reply.

I created a thread after searching and looking in the e2e forum.

I understand the answer to question Q1.

By the way, please give advice of Q2, Q2-1, Q2-2 which I asked. ?

Of course, widget behavior will depend on CPU occupation time . !!!

For example, if you need to change the TM4C (TM4C123GH6PGE) MCU, etc ..

Thanks!

regards,

Jame

Thank you Charles - your 'vote of confidence' much appreciated.    And - more importantly - your 'Resourcefulness in locating (mostly) buried examples - (very) well done!'

Charles Tsai said:

I will suggest you get the ListBox to work with static message before attempting to take dynamic data entry.

That's a 'super' illustration of, 'KISS' (even though unsaid - especially unsaid!)     

Poster & cb1 crüe keep hearing, "One small step (project change) for man ... one giant step (project success) for mankind!"    (phrase has been used (somewhere) before - has it not?)

Hi,  Cb1 &  Charles

Thank you for your reply.

I walk step by step.

Fighting. .. !!!

Thanks!

regards,

Jame.

Dear all Ti Engineers

I've been searching in the GRL-UG documentation and forums for many hours.

One of the parameter values of the ListBox macro is sName.

I don't know how to declare the sName variable declaration.

Q1> Where do you refer to the variables you declare and use them as sName?

Thanks

regards,

Jame,Shin

================================================================================

#define ListBox(

sName,                   // sName is the name of the variable to be declared.

psParent,

psNext,

psChild,

psDisplay,

i32X,

i32Y,

i32Width,

i32Height,

ui32Style

ui32BgColor,

ui32SelBgColor,

ui32TextColor,

ui32SelTextColor,

ui32OutlineColor,

psFont,

ppcText,

ui16MaxEntries,

ui16PopulatedEntries,

pfnOnChange)

Jame shin said:

Q1> Where do you refer to the variables you declare and use them as sName?

In your C source file, s = short name (static uint16_t MyVariablName). CCS GUI composer 1.1 the list box name could be specified as widget name. So the Symbol (s) matches target firmware variable name or can be referenced in the pre-initializations page# of GUI.

Dear  BP101 & Cb1 & all Ti Engineers.

I move forward one step.

Go to Implementing Features from Static Characters to Dynamic Characters.

I start with static texting first.

Q1> [Fig-1] does not appear on the screen.

        What's wrong with the source code ?

Q2> [Fig-2] is displayed on the screen by other method than ListBoxWiget

        All [Fig-1 & Fig-2] are applied to the minimum font size (FontCm12)

        [Fig-2] is expressed as 6Line x 16 Character = 96 Character.

        Calculate how many pixels per character.

        96 (Width) : 96 / 16 = 6 pixel

         64 (High)   : 64 / 6 = 10.4 pixel (about 10 pixel)

         accordingly, 6 x 10 pixel / character

         How to make small font size (5 (w) x5 (h) Pixel) ?

.

Q3> My final purpose is to:

        Host PC UART ( 115200bps, 8bit) ->  DK-TM4C123G(EVB) -> Display incoming data via ListBoxWidget on 96x64 OLED

        FIFO Size seems to be big.

        SRAM 32KB size in TM4C123GH6PGE

        What do you think is possible to implement the function ?

Thanks

regards,

Jame,Shin

#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_memmap.h"
#include "driverlib/fpu.h"
#include "driverlib/sysctl.h"
#include "driverlib/rom.h"
#include "driverlib/pin_map.h"
#include "driverlib/uart.h"
#include "grlib/grlib.h"
#include "drivers/cfal96x64x16.h"
#include "utils/uartstdio.h"
#include "driverlib/gpio.h"
#include "grlib/widget.h"
#include "grlib/listbox.h"


//tListBoxWidget 
// tWidget sBase; uint32_t ui32Style; uint32_t ui32SelectedBackgroundColor; uint32_t ui32TextColor;
// uint32_t ui32SelectedTextColor;  uint32_t ui32OutlineColor;  const tFont *psFont;  const char **ppcText
// uint16_t ui16MaxEntries;  uint16_t ui16Populated;  int16_t i16Selected;  uint16_t ui16StartEntry;
// uint16_t ui16OldestEntry;  uint16_t ui16Scrolled;  int32_t i32PointerY;
// void (*pfnOnChange)(tWidget *psWidget, int16_t ui16SelIndex);

extern tListBoxWidget sName, g_psListBox[]; 

//*****************************************************************************
// The error routine that is called if the driver library encounters an error.
//
//*****************************************************************************
#ifdef DEBUG
void
__error__(char *pcFilename, uint32_t ui32Line)
{
}
#endif


//*****************************************************************************
// Configure the UART and its pins.  This must be called before UARTprintf().
//
//*****************************************************************************
void
ConfigureUART(void)
{
    // Enable the GPIO Peripheral used by the UART.
    //
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    
    // Enable UART0
    //
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);

    // Configure GPIO Pins for UART mode.
    //
    ROM_GPIOPinConfigure(GPIO_PA0_U0RX);
    ROM_GPIOPinConfigure(GPIO_PA1_U0TX);
    ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    // Use the internal 16MHz oscillator as the UART clock source.
    //
    UARTClockSourceSet(UART0_BASE, UART_CLOCK_PIOSC);

    // Initialize the UART for console I/O.
    //
    UARTStdioConfig(0, 115200, 16000000);
}

//*****************************************************************************
// ListBox "Hello" to the display.
//
//*****************************************************************************
int
main(void)
{

    // Enable lazy stacking for interrupt handlers.  This allows floating-point
    // instructions to be used within interrupt handlers, but at the expense of
    // extra stack usage.
    //
    ROM_FPULazyStackingEnable();

    // Set the clocking to run directly from the crystal.
    //
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);
    
    // Initialize the UART.
		//
    ConfigureUART();

    // Initialize the display driver.
    //
    CFAL96x64x16Init();
    
//#if 0
	
		tListBoxWidget sWidget;


		//	char ppctext Point String = {"hello"};
		const char *ppcText  = {"hello"};
		
		
		// Initialize ListBox Widget , OLED Display 96 x 64 pixel
		ListBoxInit( &sWidget,				// tListBoxWidget *psWidget,				
		             &g_sCFAL96x64x16,                  // const tDisplay *psDisplay,							
			     &ppcText, 				// const char **ppcText, 						
			     10,	   			// uint16_t ui16MaxEntries, 				
			     5,	   				// uint16_t ui16PopulatedEntries, 	
			     0,    				// int32_t i32X  X coordinate of the upper left corner  										
			     0,    				// int32_t i32Y  Y coordinate of the upper left corner 									
			     96,   				// int32_t i32Width, 								
			     64 ); 				// int32_t i32Height 	
		
		

		// Declares an initialized variable containing a listbox widget data structure.
		//

		ListBox(g_sName,			// sName
			0, 				// psParent, pointer to the parent widget
			0,				// psNext
			0, 				// psChild
			&g_sCFAL96x64x16,               // psDisplay
			0,				// i32X  X coordinate of the upper left corner
			0,				// i32Y  Y coordinate of the upper left corner
			94,				// i32Width
			62,				// i32Hight
			(LISTBOX_STYLE_OUTLINE | LISTBOX_STYLE_LOCKED |LISTBOX_STYLE_WRAP),	// ui32Style
			ClrBlue,			// ui32BgColor
			ClrRed, 			// ui32SelBgColor
			ClrWhite,			// ui32TextColor
			ClrWhite,			// ui32SelTextColor
			ClrWhite,			// ui32OutlineColor
			g_psFontCm12,	                // psFont
			&ppcText,			// ppcText
			10,				// ui16MaxEntries
			5,				// ui16PopulatedEntries
			0);				// pfnOnChange,  pointer to the application callback 


	//  ListBoxStruct Array Table in tListBoxWidget data structure 
	//
	tListBoxWidget g_psListBox[] =
	{
		ListBoxStruct(&g_sName, 	// psParent,  pointer to the parent widget
		              g_psListBox,	// psNext
			      0, 		// psChild
			      &g_sCFAL96x64x16, // psDisplay
			      0,								// i32X  X coordinate of the upper left corner
			      0,								// i32Y  Y coordinate of the upper left corner
			      96,								// i32Width
			      64,								// i32Hight
			     (LISTBOX_STYLE_OUTLINE | LISTBOX_STYLE_LOCKED |LISTBOX_STYLE_WRAP),	// ui32Style
			      ClrBlue,					// ui32BgColor
			      ClrRed, 					// ui32SelBgColor
			      ClrWhite,					// ui32TextColor
			      ClrWhite,					// ui32SelTextColor
			      ClrWhite,					// ui32OutlineColor
			      g_psFontCm12,			        // psFont
			      &ppcText ,				// ppcText
			      10,					// ui16MaxEntries
			       5,					// ui16PopulatedEntries
			       0),					// pfnOnChange,  pointer to the application callback 
		
		};
		 						
		//  Macro,  ListBox Background Color Set
			ListBoxBackgroundColorSet(&g_sName, ClrDarkBlue);
			UARTprintf("Background Color Set!!\n");

		//  Macro, ListBox Text Color Set
			ListBoxTextColorSet(&g_sName, ClrWhite);
			UARTprintf("Text Color Set.\n");
		
		//  Macro, ListBox Outline Set
			ListBoxOutlineColorSet(&g_sName,ClrWhite);
			UARTprintf("Outline Color Set.\n");
			
		//  Macro, ListBox Font Set
			ListBoxFontSet(&g_sName, &g_sFontCm12);
			UARTprintf("Font Set.\n");		
		
		// Macro, Lock ListBox ignore attempts elements, 
			ListBoxLock(&g_sName);
			UARTprintf("Lock ListBox.\n");
			 
		// Macro, remove all text from ListBox Widget		
			ListBoxClear(&g_sName);
			UARTprintf("Empties the listbox.\n");
			
		// Macro, Add a line of text to a ListBox 
			ListBoxTextAdd(&g_sName, ppcText);
			UARTprintf("Add a line of text.\n");			
			
		// Macro,	update the display after text add 
			WidgetPaint((tWidget*)WIDGET_MSG_PAINT);	
			UARTprintf("update the display.\n");
			
				
					
		while(1)
		{
		}	

//#endif 

#if 0	
    // tContext 
    // int32_t i32Size;	 const tDisplay psDisplay;  tRectangle sClipRegion;	
    // uint32_t ui32Foreground;		uint32_t ui32Background;	const tFont *psFont;
    // (*pfnStringRenderer)(const struct _tContext *, const char *, int32_t, int32_t, int32_t, bool);
    // uint16_t ui16Codepage, uint8_t ui8NumCodePointMaps; uint8_t ui8CodePointMap; uint8_t ui8Reserved;
    tContext sContext;
    
    // tRectangle
    // i16XMin; i16YMin; i16XMax; i16YMax;		
   tRectangle sRect;	
				
    // Initialize the graphics context.
    // tContext type sContext struct member 
    //
    GrContextInit(&sContext, &g_sCFAL96x64x16);	
    
    // Data structure tRectamgle type (X, Y Min, X, Y Max) Set member value to 
    // sRect structure variable , OLED Display Area 96 x 64 pixel 
    // Data structure tContext type  sContxt struct variable, 
    //
    sRect.i16XMin = 0;
    sRect.i16YMin = 0;
    sRect.i16XMax = GrContextDpyWidthGet(&sContext) - 1;
    sRect.i16YMax = 63;
		
 
while(1) 
	{
   	GrContextForegroundSet(&sContext, ClrDarkBlue); // Forground (Green) Color Set
        GrRectFill(&sContext, &sRect);			// Draws a filled rectangle.

	GrContextForegroundSet(&sContext, ClrWhite);	// Forground (White) Color Set
        GrContextFontSet(&sContext, &g_sFontCm12);	// Set the font 
	GrStringDraw(&sContext, 			// OLED Draws
	"abcdefghijklmnopqrstuvwxyz0123456789", -1,	//  Left Coordinate string.
		0,0,0);					// X , Y coordinate of the Left, bOpaque  0

	GrStringDraw(&sContext, 
	"abcdefghijklmnopqrstuvwxyz0123456789", -1,
	0,10,0);
	GrStringDraw(&sContext, 
	"abcdefghijklmnopqrstuvwxyz0123456789", -1,
	0,20,0);
	GrStringDraw(&sContext, 
	"abcdefghijklmnopqrstuvwxyz0123456789", -1,
	0,30,0);
	GrStringDraw(&sContext, 
	"abcdefghijklmnopqrstuvwxyz0123456789", -1,
	0,40,0);
	GrStringDraw(&sContext, 
	"abcdefghijklmnopqrstuvwxyz0123456789", -1,
	0,50,0);

	GrFlush(&sContext);
		
	SysCtlDelay((SysCtlClockGet()/3) * 2 );
		
  }
#endif 


} // Main Func End,  

Greetings,

First to your 'Tag,'  "I'm desperate" ... may it be asked - who here - is not?

Jame shin said:

Go to Implementing Features from Static Characters to Dynamic Characters.

Had vendor ever positively confirmed that such (dynamic) capability was achievable w/in a, 'List Box Widget?'   (One's 'desire' does not insure that another's system will meet (your) unique requirements.)

Jame shin said:

How to make small font size (5 (w) x5 (h) Pixel) ?

This IS done - especially when employing physically small and/or 'Pixel-Limited Displays.'     Siemens past produced an 'Led Matrix' w/5x5 pixel font - your 'on-line' search may reveal.    In its absence - your review of (any) Character Lcd Module spec details a 5x7 font - which 'Increases your Character Rows from 6 to 8!'    Good that.   If you (must) have a 5x5 font - your systematic modification of the Lcd Module's 5x7 font - is reasonably 'straight-forward.'    (Note that the 5 'descender' characters (g,j,p,q,y) will not 'Win' any beauty contests...   we're told they have 'great personalities' - though...)

Jame shin said:

Host PC UART ( 115200bps, 8bit) ->  DK-TM4C123G(EVB) -> Display incoming data via ListBoxWidget on 96x64 OLED

Why have you committed so strongly to this 'ListBoxWidget' method, alone?    That - by itself - proves 'desperate' ... does it not?

Hello Cb1.

Thank you for your reply.

Cb1 Said > Had vendor ever positively confirmed that such (dynamic) capability was achievable w/in a, 'List Box Widget?'  

            A > There is not. The vendor said it did not know.

                   Charles said : “ We also don't have expertise with the Listbox widget creation.” 

                   And Charles suggested :  ” I will suggest you get the ListBox to work with static message before attempting to take dynamic data entry.”

                  So I tried eagerly.

Cb1 Said >  Why have you committed so strongly to this 'ListBoxWidget' method, alone?    That - by itself - proves 'desperate' ... does it not?

            A >   I have to implement it absolutely. GRL-UG determined that ListBoxWiget was appropriate.

Cb1 Said > Why have you committed so strongly to this 'ListBoxWidget' method, alone?    That - by itself - proves 'desperate' ... does it not?

             A >  Because I have to implement the feature. Is there a suitable solution  ?

Thanks

regards,

Jame,Shin

Dear all Ti Engineers

https://e2e.ti.com/support/microcontrollers/other/f/908/p/836379/3105104#3105104

Please answer question Q1 at the link above.

regards,

Jame,Shin

Jame shin said:

Cb1 Said >  Why have you committed so strongly to this 'ListBoxWidget' method, alone?    That - by itself - proves 'desperate' ... does it not?

            A >   I have to implement it absolutely. GRL-UG determined that ListBoxWiget was appropriate.    

Pardon my friend - but your 'reasoning' here appears 'circular.'    (You 'justify' your logic by 'beginning'  - with that with which you seek to 'end.')    

Such is  well-known as a 'logical fallacy' - always leading to a 'false conclusion.'   

Repeating (perhaps for the 3rd time now) - switching your efforts to a 'more achievable/obtainable' method or procedure - is likely to (far) better serve you...

Hello Jame,

I've been following this thread for a while. I can understand the frustrations with the challenges you are facing, but unfortunately these topics are really very application specific.

Regarding Question 3 specifically, it may be possible but you need to evaluate the throughput of data you need based on the refresh rate of your screen. From a memory standpoint there shouldn't be an issue if the data arrives fast enough to update the display until you define the refresh rate and then investigate the overhead to take the data from the UART and output it onto your screen, you won't be able to know if 115200 kbps UART is sufficient.

Regarding the remaining topics:

We are device experts for the TM4C MCUs and it's peripherals, and while we try and put together examples and offer guidance on how to leverage the peripherals for applications, there are times where the application gets advanced beyond our ability to help.

This situation is one of those cases.

We provide the Graphics Library with documentation and examples to give users a strong start on development, but creating graphic interfaces beyond our examples is an area we just lack the expertise to help guide. At the end of the day, the dynamic list box widget is an application specific concern and it goes beyond the support we can offer as TM4C experts.

You may want to evaluate hiring a third party firm with graphics experience to help build this application. We have a resource to help find such firms you can look at: http://www.ti.com/devnet/docs/catalog/searchcatalog.tsp?DCMP=Third_Party&HQS=3p

If you find an issue directly related to the peripheral itself let us know and we can guide from there, but as far as the current questions are concerned we just are not able to provide support.

Jame shin said:

        All [Fig-1 & Fig-2] are applied to the minimum font size (FontCm12)

Where did you get the font/s imported into the OLED project? Oddly recently saw similar Q1 behavior for fonts incorrectly created as anti alias for an LCD that did not support dynamic font feature. All the number widgets were blank. After recreating the fonts with anti alias unchecked they display ok in widgets, Veranda 16 high Windows 1586 encoding. The font generator allows custom size to be created but I have not yet done so.

You're welcome to try Veranda 16 font file./cfs-file/__key/communityserver-discussions-components-files/908/Veranda_2D00_16_5F00_Win_2D00_1586enc.zip    

Oddly the custom font generator will only accept 16 pixel high as it barked back for 5 pixel attempt. 

Hello CB101.

Thank you for your reply.

BP101 Said > Where did you get the font/s imported into the OLED project?

           A> \TivaWare_C_Series-2.1.4.178\grlib\fonts\fontcm12.c &   C:\..\grlib\grlib.h

BP101 Said > All the number widgets were blank.

A> What is the number of all widgets and how should I modify them?

BP101 Said > You're welcome to try Veranda 16 font file

 /cfs-file/__key/communityserver-discussions-components-files/908/Veranda_2D00_16_5F00_Win_2D00_1586enc.zip

       A> I learned about Verdana Font. Thank you.

However, we could not find any search results at the address you provided.

I couldn't download the zip file.

Q1> https://e2e.ti.com/support/microcontrollers/other/f/908/p/836379/3105104#3105104

       Is it displayed when the widget number is modified in [Fig-1.] Of the previous post ?

If correct, “Hello” will be displayed

regards,

Jame,Shin

.

Dear Ralph & All Ti Engineer

Thank you for your reply.

I feel the truth in your dedication and appreciation.

By the way, I think this !!

Ti engineers are experts on peripherals only. I do not know other release documents. !!

Such content cannot be found in UG documents, including the E2E Forum.

Do you think that Ralph alone? Or is Ti company policy !!

Of course, it will be possible if the data transfer speed and processing is faster than the display processing.

I think this is something that anyone can approach.

Ralph said > We provide the Graphics Library with documentation and examples to give users a strong start on development,

                       but creating graphic interfaces beyond our examples is an area we just lack the expertise to help guide.

             A >  “we just lack the expertise to help guide.” Is this true?

I will give a simple and meaningful example.

1 + 1 = 1 or 2  ? 

Thinking together and worrying is not the spirit of E2E !!

Ralph said > You may want to evaluate hiring a third party firm with graphics experience to help build this application

                   We have a resource to help find such firms you can look at: 

  http://www.ti.com/devnet/docs/catalog/searchcatalog.tsp?DCMP=Third_Party&HQS=3p 

A> I am poor. So I must do it myself

Ralph said > If you find an issue directly related to the peripheral itself let us know and we can guide from there,

                 but as far as the current questions are concerned we just are not able to provide support.

             A> It feels cruel to me

Can't we think and think together?

Is that not the meaning of E2E's Forum? !!

I'm worried together ..

regards,

Jame,Shin

Hello Jame,

Neither Charles nor myself have worked extensively with graphics displays. Even the provided libraries and examples were written before we were on the team to help with support. Without firsthand experience, it is difficult to even offer basic guidance.

As you have alluded to, we are device experts and while we try and understand as much as we can about end applications, we have a finite amount of time and a large number of customers to support, so there are limitations at how deep we can go into learning a specific application. At the end of the day, we are an IC manufacturer not an end system design house.

What I said though is from a TI standpoint and of course this thread will remain open so you can continue to have dialogue with some of our knowledge community members as E2E is meant to be about, and they may be better positioned to help you realize your goals. And Charles & I will continue to read your questions and if we see any areas we can chime in and offer some guidance, we still will.

And on that note, I was able to download the zip file myself. See if this download link works for you instead: 3404.Veranda-16_Win-1586enc.zip

Hello Jame,

Have you yet tried to change widget font file name, last font bottom of /grlib/font folder (FontFixed6x8.c)? Perhaps it is 6 pixel high x 8 pixel wide font. My uploaded file was 16 pixel high Veranda.

BP101 said:

(FontFixed6x8.c)? Perhaps it is 6 pixel high x 8 pixel wide font.

I'd, 'Not bet the farm (or even the south 40) on that!'     Fonts are almost always taller than wide - note the 'universal 5x7 Font' is 5 pixels in character-bit width & 7 pixels in character-bit height.    One bit spacing is applied - resulting in a 6 pixel wide by 8 pixel tall 'character cell' - which 'houses' the 5x7 font pixel matrix...

Hello Ralph.

Thank you for your reply.

Ralph Said > Even the provided libraries and examples were written before we were on the team to help with support.

     A> I fully understand your difficulties.

         Please do not turn away. !!

Ralph Said > As you have alluded to, we are device experts and while we try and understand as much as we can about end applications,

                 we have a finite amount of time and a large number of customers to support,

  A> I study and think a lot about special applications.

                 I will ask questions in the E2E forums if I do not know while studying.

                Please answer me with say that have soul !!

Q1> I know by saying BP101. Height is 16.

       It's not a font I need, but I learn it with a learning attitude.

       I opened the Veranda-16 Font you sent.

       The image file is like an attached picture.

       How do I porting this?

Have a relaxing weekend.

Regards.

Jame,Shin

Hello PB101

Thank you for your reply.

[Fig-3.]This is origin picture

This is the result of your proposed “6 pixel high x 8 pixel wide font” [Fig-4.].

That's my point of view

The upper first letter position has been raised.

I have some space below

Progress has been made on some of the font height 5 goals. !!!

[Fig-5.] Displays one more line with the space below of [Fig-4.].

 BP101 Said > All the number widgets were blank.

        Re_Q1>  A> What is the number of all widgets and how should I modify them?

Have a nice  weekend.

Regards.

Jame,Shin

Hello Jame,

Great job to see progress. Also like CB1 work group adds very intuitive LCD information this thread.

Jame shin said:

All the number widgets were blank

I was referring to an actual number box widget but it was the text box too was blank. Fig.4 is much better than Fig.3 original 12cm!

Yet 7 line string seems a bit blurry. It would seem OLED pixel size can produce even smaller fonts or should. Long in past wrote an 8 octant DDA to produce vector graphic microdot tiny CRT fonts. The simple DDA worked via coordinate inputs (x1-y1) to (x2-y2) in 8 easy steps to draw vertical/horizontal lines (+) and diagonal (x) lines. The original code was written in Pascal, I converted each octant to run z80 machine language.

Greetings ... to all those 'interested or arriving accidentally'  to this "LIKE & KISS (less)" List-Box Widget's 'poking/prodding.' 

Jame shin said:

I want to create a hyper terminal window on an OLED display (96 x 64 pixels).

Earlier this reporter (fairly) noted poster's 'potential issues':

• expanding the List-Box's capability - so that 'Live, UART data' is accepted & displayed
• accomplishing that at a relatively high data rate (w/likely 'other demands' taxing the MCU)
• employing (only) a 96x64 Oled
• expanding 'character rows' from 6 to 8  (via use of a 'rare' (yet available) 5x5 pixel font)

From my 'intermittent following' (and first impression) it remains 'questionable' if the List-Box can be successfully 'poked & prodded' into accepting 'Live Data' - and if it can - at so high a data rate.    To my group's mind - this has never been 'fully/properly' resolved!    (it proves always 'wise' - to build upon a 'known good/solid' foundation - and ONLY then - venture further!)   [clearly that IS 'KISS!']

Poster appears to seek, 'Beyond the normal/customary (number) of character rows' - resident w/in the List-Box.   (thus the quest for 5x5 font)    There IS a serious 'downside' which accompanies 'so small' a font:

• each character row is (notably) 'height-reduced' - which is likely to 'reduce recognition' and/or message legibility.   (especially when Data Arrival is 'Live' and near continuous)
• such '5x5 font' is well known as "Failing in the display of those (lower case) characters w/'descenders!"   [again: g j p q y]    Those characters appear (pardon) 'ugly' when rendered in the (standard) 5x7 font - they  cannot (even) meet (ugly's standard) - when rendered in 5x5...    Lower case characters lacking descenders are 'unattractive' - and may be employed - yet the limitation is severe.

The quest for 'Increased Character Rows' can (better be achieved) by employing a 'More Pixel-Rich Display' - which enables, 'More rows of legible 5x7 font characters.'    (i.e. the (usual - next size up) non custom Oled is 128x96 ... which if  (early morning math succeeds) - yields '96/8 = 12 character rows!   Note that this vendor - in the distant (LM3S) past - produced a 'rare' LX232, BGA MCU, Eval Board w/such a display.   (gifted to my small firm)

In conclusion - while (several times suggested) this 'course of action' appears proper:

• really determine if 'Live Data Input - via UART - is (even) accommodated by a 'List-Box'
• and 'if so' - can a data rate of 115Kbaud be sustained
• migrate from the '96x64' Oled to 'Next Man Up' - to accommodate the quest for, 'Increased Character Rows'

In fairness to the '96x64' Oled - arrives now a 'color version' (employing the 5x7 font) via a 'not quite successful' (rushed) Lcd to Oled (screen address) translation.    (We 'got' the 2nd attempt right - progress rules!)

and

May it be noted that (both) images above are (near) "List-Boxes" - and as such each enables individual list row:

• creation
• storage
• display
• ability to alter the 'display's window' into the list.  (i.e. 'slide' a 'grouped portion' of the list - up or down - the list's depth (number of rows) usually exceeds the display's capacity - thus only a portion of the entire list is displayed)
• ability to detect & respond to user input commands - issued via 'common panel controls' (usually momentary switches - although rotary encoders are faster & more elegant).    Note that 'multiple such List-Boxes' may each use those same panel controls - that usage depending upon which 'Specific List-Box is currently 'IN FOCUS.'

Alas - as powerful & valuable as this is - it is 'Not believed' that 'Live Data' may arrive' - both 'Updating the List-Box' while (somehow) Communicating the NEW OPERATIONS such New Data DEMANDS!    That fact (appears) to have been missed - thus the 'suggested Answer' - while admittedly a 'suggestion' - 'Fails as an answer!'

Hello Cb1

Thank you for your reply.

Cb1> To my group's mind

     - this has never been 'fully/properly' resolved!    (it proves always 'wise'

       - to build upon a 'known good/solid' foundation 

       - and ONLY then - venture further!)   [clearly that IS 'KISS!']

A> Yes, it's a good mind, so I'm a fan of my friend mind “KISS”.

Cb1 > employing (only) a 96x64 Oled

A> It is not intended to be used as a 96x64 Oled. Let's try to implement the function first in DK-EVB.

               Use 128 x 96 OLED, that's ok.

Cb1 >  (thus the quest for 5x5 font)  There IS a serious 'downside' which accompanies 'so small' a font:

           which enables, 'More rows of legible 5x7 font characters.' 

A> Yes it is. Legible !!

                 I've drawn pixel fonts for each size. (Attached image, font type)

Cb1 > in the distant (LM3S) past - produced a 'rare' LX232, BGA MCU, Eval Board w/such a display.   (gifted to my small firm)

         In conclusion - while (several times suggested) this 'course of action' appears proper:

A> May I buy the gift

Q1> Is it possible to provide the function I need?

Cb1> migrate from the '96x64' Oled to 'Next Man Up'

       May it be noted that (both) images above are (near) "List-Boxes“

         - and as such each enables individual list row:

• creation
• storage
• display

         ability to alter the 'display's window' into the list.  (i.e. 'slide' a 'grouped portion' of the list )

A> Wouldn't it take less steps to use the “ListBoxWiget“ Tool the way I would like to !!

Step 2, Creation, Display.

         ※ This is the primary purpose I want to use as a ListBox.

             1. The received data must be represented in the List Box.

             2. The Y coordinate value should be calculated automatically.

             3. The old string is deleted and the new string is added.

Q2> “ (i.e. 'slide' a 'grouped portion' of the list )” Can't remove grouping? (Only Lsit Box Display)

Cb1> ability to detect & respond to user input commands

A> In the GRL-UG, I saw that the Style List_Locked setting is only report type, not interactive.

       So, my thought is seeing the possibility of displaying only data received from the UART in the form of a text report. !!

   * SW-TM4C-GRL-2.1.4.178 (See 163 page)

     LISTBOX_STYLE_LOCKED causes the listbox not to make any application callbacks and to ignore user attempts to select or deselect entries.

     A locked list box does not, however, ignore all user input since it still responds to pointer activity to allow the content to be scrolled.

   This style may be used in cases where, for example, the listbox is being used to report text status rather than as an interactive element.

    And LISTBOX_STYLE_WRAP.

Cb1 > it is 'Not believed' that 'Live Data' may arrive‘

Cb1 > That fact (appears) to have been missed

Q3> Speeds up the time data arrives, Reliability without missing data

           Can't do this like this?     [ Kiss mind (Full)]

           TM4c123gh6pge Data Sheet (see 924 page),

           Tx & Rx FIFO 16x8 Hardwired.

           Data input into SW FIFO configuration again

           “RxFIFO 16x8 --> Receiver --> UnRx --> SW RxFIFO 32x8 --> OLED Display “

Regards.

Jame,Shin

Greetings,

May I repeat (young/gifted staff's comment?) ... "Poster Jame's '5x5 (descending) q & y - appear like a (pardon) 'Deformed Space Alien!'    (perhaps 'visiting earth' - seeking a 'legally blind' wife... Alien (likely) came (too close) to the 'Left Levitation Thruster' - during 'Pilot Walk-Around.')    Kindly recall - I am (only) the  'messenger' - your argument (remains) w/the authoring, young/gifted staff...

As always - glossed over (i.e. AVOIDED) is the:

• shotgun marriage to the 'List-Box Widget' - and ONLY to that!
• failure to determine - 'HOW - even IF' - that Widget may receive, process & function normally - in its MUCH EXPANDED 'Live Data Input while in operation,' role

Retreating from that (remaining) issue - (may) place ALL follow on efforts here - in jeopardy.    Recall the establishment of a 'Strong/Solid FOUNDATION!'   Have you created that?

A most recent post (again) noted,

"Alas - as powerful & valuable as this 'List-Box' is - it is 'Not believed' that 'Live Data' may arrive' - both 'Updating the List-Box' while (somehow) Communicating the NEW OPERATIONS such New Data DEMANDS!    That fact (appears) to have been missed (and/or) denied!

In 'times past' - men 'feared'  "sailing OFF the 'edge' of the earth."    As a (reasonably) inept weekend sailor - I too have such fear - and thus Sail only where the Pacific is 'known' - and my craft  is PROVEN.

Desire - no matter how strong - proves an unacceptable 'substitute' for 'Proven Capability!'    Minus such 'proof' - all efforts to assist - may be in vain...     Can that be 'fair or proper?'

Dear Cb1. ( To. my friend )

Thank you for your reply.

Cb1_Tag> How can one do this? .... Has an alternative to the (over-challenged) List-Box - really been properly (or otherwise) considered?

           A>  There is no other alternative at this time.

                 I think while a month. And study

                Could you please let me know if there are other alternatives?

Regards.

Jame,Shin

Dear all Ti Engineers

The TM4C-GRL-UG document has insufficient content.

( tDisplay , see 31 Page)

I do not know about * pvDisplayData.

Example the ColorTranslate () function inside a struct member.

Ex>

unsigned long

ColorTranslate(void *pvDisplayData, unsigned long ulValue)

“ pvDisplayData is a pointer to the driver-specific data for this display driver. “

Use OLED Display of Vendor Solomon Systech SSD1332 (OLED Pannel Driver IC) in DK-TM4C123G-EVB

Q1> Is this correct if I show this in the source code?

        ColorTranslate( &SSD1332, ClrDarkBlue);

The member pointer function in the tDisplay structure is shown below.

void (*pfnRectFill)(void *pvDisplayData,   const tRectangle *psRect,   uint32_t ui32Value);

Q2> Where is the source code for the RectFill () function file?

Tag: Don't be afraid or avoid posting my debate. !!

         Even if that question is crappy…

        Think together and be your guide.  

Regards.

Jame,Shin

Jame shin said:

Could you please let me know if there are other alternatives?

May I answer via a, Sailing Example?    (group & I fly to L.A. shortly - where we'll demonstrate our newest 'marine-based product' - installed on my sailboat ... i.e. firm's 'Floating tax deduction')

Now we sometimes enter 'Class based sailing races' - and even though my craft is 'crammed' w/Radar, Advanced Marine & Ham Communication gear, and (almost 'autonomous Sail & Tiller Management' [steering]) - I NEVER WIN!     And many times - those who win are 'High-School gurlz.'   

How can that be?    Simply - my 'sailing capability' is 'Unable to adequately meet the demands' - imposed by such races.    To confirm this 'Capability Test' - I've let these (usually competing) high-school women race my boat - and they have, several times then, easily WON!     So - my 'inadequate sailing capability' - places (severe) limits - upon my Racing Success!   (i.e. 'lack thereof')

Now substitute your 'List-Box Widget' for cb1's 'sailing skills.'    Have not the '31 (failing) posts herein' - established the 'strong likelihood' - that your (desired) 'List-Box Widget' - cannot meet your capability demands?    THAT has 'long' been my point...

You ask (others) to identify an alternative.    Does that task not begin with a, 'Detailed Specification' - authored by you?     (as (only you) know 'All of your detailed needs/requirements.')

By thoughtfully considering - then listing - then prioritizing (your) requirements - in a systematic manner - you increase the chances of 'Vendor Experts' being able to 'inform & advise.'    (or even - hapless outsiders - who sometimes (if/when lucky) - 'blunder upon' a giant,tasty acorn...)   (i.e. 'blind squirrel' syndrome)

Dear Cb1.

Thank you for your reply.

Your say and inspirational advice are all correct.!!

I want to implement it in DK-EVB.

As a result, even if it fails… …

I will feel and learn something in the process.

Previous Post,   e2e.ti.com/.../3112743

can you answer my tDsipaly struct question?

Regards.

Jame,Shin

Hello Jame,

Sorry for the delayed reply, I was travelling to another TI site. As I'll be on travel the next week, please forgive any other delayed replies.

I have been looking into your question regarding the pvDisplayData. We don't have any internal documentation that clarifies that and I was trying to look into prior questions or maybe the example code but nothing gives me a clear answer. However, my understanding from looking at the general structure of GrLib code is that it is a pointer to what needs to be drawn formatted based on the specific graphic display (I presume for height/width). In our example projects, this would correlate to the g_sContext variable. Perhaps following how that is used in those examples will help better guide regarding pvDisplayData.

//
// Global graphic context for the application.
//
tContext g_sContext;

Regarding the source code for RectFill, it looks like this is an odd situation. There is no source code I can find even within our internal resources, but the documentation file that is used to generate the User Guide has it mentioned. I am not sure if it was 'documented' before being added and got forgotten, or if it was removed without the documentation being updated, but in any case that API does not exist. There is a GrRectFill API though, maybe that can help.

Hello Ralph,

Thank you - that's valuable data - and adds to our 'group attempt' to aid poster.

As this thread has now grown to '33' posts - w/out effective resolution - perhaps a, 'Restatement of poster's requirement assists:'

• His continued desire is to employ (only) the List-Box Widget    (No other function w/in the GrLib need apply!)
• He seeks to 'break' from that widget's (normal) operation by extending it to,"LIVE Updating of list elements via UART"

To staff/myself - this added, 'External (UART) Update capability' was not anticipated - nor provided for - by the widget's designers.   (Dave - as one I specifically recall)     

Note especially that those 'listed items' - appearing w/in the List-Box Widget - are capable of generating, 'Multiple, reasonably demanding, pre-programmed, List-Box Operations!'     (such as list's vertical scrolling, or entering 'deeper' into the selected list item's detail.     (i.e. to select a value or frequency etc.)    

Staff/I do Not 'See How' all of those (potentially) complex linkages & list manipulations  may be (fully/properly) 'Commanded' by a, 'Live UART feed - alone!'   

Thus to us - poster's desire has, 'Little chance of success.'     It must be further noted that, 'Passing ALL of this complex, required 'Update Data' in a timely (practically unnoted) fashion' - is yet, 'One more nail' in this attempted  'widget's  re-purposing  coffin!'

Dear all Ti Engineers

I had a question while looking for the meaning of “pvDisplayData”.

grlib/grlib.h

-------------------------------------------------------------------------------------------------

#define ClrRed                 0x00FF0000

#define ClrGreen               0x00008000

#define ClrLime                 0x0000FF00

#define ClrBlue                 0x000000FF

-------------------------------------------------------------------------------------------------

grlib/Offscr1bbp.c   ( RGB888 24bit  to RGB332 8bit , The logic to convert.)

-------------------------------------------------------------------------------------------------

#define DPYCOLORTRANSLATE(c)   ((((((c) & 0x00ff0000) >> 16) * 19661) + \

                                 ((((c) & 0x0000ff00) >> 8) * 38666) + \

                                 (((c) & 0x000000ff) * 7209)) /         \

                                 (65536 * 128))

-------------------------------------------------------------------------------------------------

(100% Red, RGB888 24Bit)   0x00FF0000  --->  (100% Red, RGB332 8bit ) =  0xE0

I translated the Red Color by the above logic calculation..

    (c)       0x00FF0000                         (c)       0x00FF0000                      (c)       0x00FF0000                                       0d 65536

& Mask   0x00FF0000                      & Mask   0x0000FF00                  & Mask   0x000000FF                                   * 0d   128

-------------------------------                  ---------------------------------               -------------------------------                       --------------------

 >> 16    0x00FF0000                         >> 8     0x00000000                                  0x00000000 (0d 0)                   0d 8,388,608 (0x800000)

-------------------------------                  --------------------------------                        *       0d 7209

              0x000000FF (0d 255)                       0x00000000 (0d 0)              ---------------------------------

          *       0d 19661                                 *       0d 38666                                       0x00000000 (0d 0)

-------------------------------                    ------------------------------

           0x4C8033 (0d 5,013,555)                     0x00000000 (0d 0)

[Result]

0x ( 0x4C8033 + 0x00000000 + 0x00000000 ) / 0x800000 = 0

0d ( 5,013,555 +          0          +       0            ) / 8,388,608 = 0.59766……

Q1> 100% Red Color, RGB888 24bit -->100% Red Color, RGB332 8bit , I think the converted result is 0xE0.

        What is wrong and the calculation results are wrong?

Regards.

Jame,Shin

Dear all Ti Engineers

Logic calculations have been solved.

Cfal96x64x16.c

--------------------------------------------------------------------------------------------------------------------------------

#define DPYCOLORTRANSLATE8(c)   (   ( ( (c) & 0x00e00000) >> 16) |     \

                                 (   ( (c) & 0x0000e000) >> 11) |                 \

                                 ( ( (c) & 0x000000c0) >> 6)     )

--------------------------------------------------------------------------------------------------------------------------------

RGB888 24bit , 100% Red Color 0x00FF0000    -- > RGB332 8bit , 100% Red Color,   0xE0   Converter OK.

Q1 >     What does  * pvDisplayData  0 value mean ?

             In GRL-UG documentation it's called a pointer

             pvDisplayData is a pointer to the driver-specific data for this display driver.

 <Cfal96x64x16.c>

----------------------------------------------------------------------------------------------------------------------------

const tDisplay g_sCFAL96x64x16 =
{
sizeof(tDisplay),                                    // int32_t  i32Size
0,                                                           // void  *pvDisplayData
96,                                                         // uint16_t  ui16Width
64,                                                         // uint16_t  ui16Height
CFAL96x64x16PixelDraw,                    // void (*pfnPixelDraw)
CFAL96x64x16PixelDrawMultiple,       // void (*pfnPixelDrawMultiple
CFAL96x64x16LineDrawH,                 // void (*pfnLineDrawH)
CFAL96x64x16LineDrawV,                 // void (*pfnLineDrawV
CFAL96x64x16RectFill,                      // void (*pfnRectFill)
CFAL96x64x16ColorTranslate,          // uint32_t (*pfnColorTranslate)
CFAL96x64x16Flush                          // void (*pfnFlush)
};

Regards.

Jame,Shin