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.

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." 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

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