Want to do lazy display output computation (printf... )

[goeck]

Hey everyone,

I have a SSD1306 driven OLED display hooked up to my ChibOS-runngin STM32F0-Discovery over SPI for performance reasons (could have hooked it up over I2C as well). No I found that when using gwinPrintf() it takes several 10s ms to compute the output data and only 1.3ms to push the display RAM to the display. Since I do some performance measurements in a row with my running application I can not display the result of each trial since it would influence the next measurement.

I thought about the following possible solution to this issue:

- set up a thread, only responsible for display output at a very low priority

- put it asleep at startup

- pass the whole gwinPrintf() somehow to this thread, computation of printf() has to be done in this thread, not the invoking one

- when system gets lazy again, display output could be done

Well, one could actually pass one msg_t to this thread and would maintain a list of predefines messages whichs index could be stuffed in that msg_t and the display thread goes through that list and prints whatever there is bundled to according to the list. I actually want to have something close to the earlier mentioned idea.

What do you think?

Regards from Germany

[Svenska]

Hi,

you are trying to solve the wrong problem, which usually points to a bad design in the first place.

You could code a faster output routine. Since you probably don't need all functionality printf() provides, creating a faster special-purpose function shouldn't be too hard. The other way is to fix up your design, which means decoupling realtime stuff from non-realtime stuff.

Your GUI is not realtime, your measurements are. Either you put them into a high-priority/realtime thread or into an ISR, depending on your specific application. Your values go in a ring buffer, to be displayed by the normal-priority (or lower-priority) display subsystem, which also takes care of skipping older values.

Mucking around in the inner parts of the system and increasing the complexity to hide an inherently bad design is only going to put you into trouble later.

/Svenska

[goeck]

Hey Svenska,

thanks for the reply. You really got my point, I have realtime and non realtime, and I see no well paved way how this can be solved in uGFX. I agree with you; maybe you know the famous Einstein quote

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." 

This is actually the way I like to go, so I thought of robust mechanisms which led me to the posted idea. Rather than keeping lists and counters I'd like to have a dedicated display drawing thread that takes care of non realtime GUI stuff and hides whenever performance and no latency is demanded.

Right now, what I do is saving timestamps and doing no GUI output when events happen, e.g. start_of_measurement notification. This is not ideal since I want to put out lots of debug data.

Regards

Stefan

[Svenska]

You really got my point, I have realtime and non realtime, and I see no well paved way how this can be solved in uGFX.

Exactly; µGFX doesn't care about your realtime requirements. That's what you, as a system designer, need to handle.

Another famous quote attributed to Einstein is: "Make things as simple as possible - but no simpler."

Right now, what I do is saving timestamps and doing no GUI output when events happen, e.g. start_of_measurement notification. This is not ideal since I want to put out lots of debug data.

Putting out lots of (unstructured) debug data on a graphical display conflicts somewhat with realtime. You might want to think about using a buffered, interrupt-driven serial port for that, which is much lower overhead and allows offline analyzing the data.

/Svenska

[Joel Bodenmann]

Right now, what I do is saving timestamps and doing no GUI output when events happen, e.g. start_of_measurement notification. This is not ideal since I want to put out lots of debug data.

NEVER put debugging data on an LCD. As soon as you remove it again (once your systems appears to do what you want it to), you change the entire behaviour of the system. Debug data is supposed to be retrieved through your controller debugging port or through any other suited interface. Only put stuff on your LCD that you eventually want on it once you finished your project.

~ Tectu

[goeck]

Well, Joel, thanks for the guideline. Maybe I was mistaken. I must have said, I have incomming data that has to displayed to the user, not real MCU related debugging data.

I want to display all the communication of an UART attached system that I am communicating with. So when the project is finished I whish to have all those data on the display, it's not necessary for the function of the system though.

But anyways, how could a threaded GUI be done with uGFX? Best would be to implement the thread and attach it to gwinPrintf() I just thought, so the printf computation implicitely runs in that thread and when it's done it lays itself asleep again or terminates. This at least is what I was used to doing Qt GUIs.

[Svenska]

Create a lower-priority thread calling gwinPrintf(). The output will then inherit that priority.

Make sure not to produce more data than you can consume (display), unless you can handle buffer overruns.

[Joel Bodenmann]

Note that you can also change the GDISP worker thread priority in your gfxconf.h.

~ Tectu