TM4C129X Display tearing/blinking

JHi said:

The question is: is this feature, bug or am I doing something wrong? Is there a better way to display changing values?

I use the grlib from the TivaWare library and the display driver is what comes as an example with the development kit.

 Hi JHI, this trouble resemble all pain I suffered with stack overflow, can you increase Stack to see if it disappear?

I'm using TI-RTOS (if it maters?). With the ROV tools I can see that my hwiStackPeak = 872/1024 and task peak 1492/2048. I'm calling WidgetMessageQueueProcess() from the Idle Task. Is that Ok or should it be high priority Task which is triggered with a clock? BR JHi

Our small tech group has long been in the graphic display field - yet have little experience w/vendor's graphic library. 

You state, "part of the old numbers stay on the display if the size of the new number is smaller than the old."  Classically - operating outside vendor's gra lib - we'd overcome this via 1 of 2 ways:

a) clear the "complete" old number field just prior to each/every number field update.  (Should text be a "legal entry" w/in that field - sending "space" characters works well)

b) append blanks (or space codes) when the new number is smaller than the old

We've used both techniques w/many of our firm's graphic panels - avoids the issues you've identified - and seems worth a "try" to solve your issue.  (yet again - we do not employ vendor's graphic lib.)

I'm using now sprintf with one "space" bigger array and print fixed sized strings adding space characters as padding. Clearing is not possible with the grlib, because before the display is updated I have to call widgetpaint and then I would have to wait x time when it's through the queue and then draw the number -> not worth it.

I was just hoping there would be a better way to handle this. And if it is bug then I was hoping it might some day be fixed.

BR

JHi

Graphic Lib "giveth" and "taketh away" - thus our group's avoidance.

If your update is always numeric or text - might you be able to escape the issues by writing a fixed length string - padded with blanks - as/if appropriate?

In our display applications - we often update multiple numeric fields - and "hooked" bar-graphs - and our methods (thus far) have escaped the unwanted/unacceptable display artifacts you report...  We set out to support 16 unique numeric fields - many w/linked bar-graphs - and designed our SW to that end.  Vendor's graphic library appears to have targeted broad & different objectives - design trade-offs/compromises often result...

JHi said:

I'm using TI-RTOS (if it maters?). With the ROV tools I can see that my hwiStackPeak = 872/1024 and task peak 1492/2048. I'm calling WidgetMessageQueueProcess() from the Idle Task. Is that Ok or should it be high priority Task which is triggered with a clock?

 Hi, you wrote about using an Example of TIRTOS, please can you point us to what example is so we can test on our board if issue reproduce as from your side?

 Can you test your code on a different DK board to see if not defective?

No I didn't say that I use example code, only the Kentec display driver from the example code. Unfortunately I have only this one DK board so I can't test it with other board/display.

But here is a part of my code:

// Initialize Canvas
Canvas(dateCanvas, &header, &alarmCanvas, 0,
       &g_sKentec320x240x16_SSD2119, 112, 2, 127, 16,
       CANVAS_STYLE_TEXT | CANVAS_STYLE_FILL | CANVAS_STYLE_TEXT_RIGHT,
       TC_BLUE, TC_LIGHT_GREY, ClrGhostWhite, g_psFontDigital7_20, 0, 0, 0);

// Update the Canvas every second. This is done in another function
struct tm tm;
getCurrentTime(&tm);
usprintf(clockText, "%02d:%02d:%02d-%02d.%02d.%d",
	tm.tm_hour, tm.tm_min, tm.tm_sec, tm.tm_mday, tm.tm_mon + 1, 1900 + tm.tm_year);

CanvasTextSet(&dateCanvas, clockText);
WidgetPaint((tWidget *)&dateCanvas); 
And in Idle-Task call WidgetMessageQueueProcess().

BR

JHi

JHi said:

No I didn't say that I use example code, only the Kentec display driver from the example code. Unfortunately I have only this one DK board so I can't test it with other board/display.

 Hi, is your code confidential or just at start point so you can send me/Amit full project to see all setting and cross check? If so I can test and see if issue reproduce, I also can try isolate what can happen, my application using RTOS is ok but I analyze  everything can appear on my hardware too.