crice
19th August 2012, 16:28
Hello, we are fairly new to QT, and writing an embedded QT application (using QTQuick) that talks to a serial port (needs to send messages at a constant rate) and renders some complex, scrollable displays.
We have found that the user can use the display (for example, scrolling the chart) in a way that makes the serial messages stop for a bit. We believe that the scrolling/re-rendering is starving the timer that is driving the serial messages momentarily. Currently this is driven by a QTimer and a signal/slot connection.
We need to revise to ensure that the rendering of the display, no matter how complex, cannot prevent the sending of a serial message. What's the best way to do this in a QT application? We can make the display simpler, but this would simply reduce the chances of this -- if there is enough data to render this it seems this is always possible with our current approach -- we want this to not be possible.
I can imagine answers ranging from setting priority flags (if any) in the QT framework, to re-sourcing our serial comm from the QT Timer to something more deterministic, to making our application multithreaded (I hope it doesn't get this drastic, but we will do this if it's the only way to ensure serial cant be interrupted).
Any thoughts from experienced QT folks are very appreciated.
We have found that the user can use the display (for example, scrolling the chart) in a way that makes the serial messages stop for a bit. We believe that the scrolling/re-rendering is starving the timer that is driving the serial messages momentarily. Currently this is driven by a QTimer and a signal/slot connection.
We need to revise to ensure that the rendering of the display, no matter how complex, cannot prevent the sending of a serial message. What's the best way to do this in a QT application? We can make the display simpler, but this would simply reduce the chances of this -- if there is enough data to render this it seems this is always possible with our current approach -- we want this to not be possible.
I can imagine answers ranging from setting priority flags (if any) in the QT framework, to re-sourcing our serial comm from the QT Timer to something more deterministic, to making our application multithreaded (I hope it doesn't get this drastic, but we will do this if it's the only way to ensure serial cant be interrupted).
Any thoughts from experienced QT folks are very appreciated.