QElapsedTimer reporting strange values from within QThread
-
@JeKK666
I don't know. It would be interesting if someone else comments, because they will know more than I. But your claim/finding that having had a Qt program show a splashscreen and then exit, and still affect timings after that, sounds fishy.Qt doesn't somehow do things which are not provided by your OS. It just makes appropriate calls. If there is something wrong in its code that would be a Qt bug, but otherwise it's down to your OS.
Since this has become a discussion, there is one thing I don't get, and I hope an expert will clarify. My lack of understanding is because I know nothing about embedded/Yocto. For a desktop Linux or Windows at least, it seems to me: you are relying on a timer to tell you how far apart some events are. But how do you know when your thread or process will be scheduled for a time slice? In a desktop OS at least, after your
poll()gets notified of one event, it could take ages and miss events till the next time that piece of code with thepoll()gets called again. Is that not right?@JonB I'll try to explaining as per my understanding.
The sysfs library provides some sort of "abstraction layer removal": the endpoint on which poll() is called represents a hardware resource (in this case a GPIO pin) made accessible in user space; it allows creation of a construct which resembles registering an interrupt service routine to react to an asynchronous event in the most timely manner, much as you would do in a microcontroller.
In Linux, hardware level access is restricted to kernel space applications, so one would need to write his own driver that access memory locations corresponding to, for instance, GPIO registers, register an IRQ number and all other sorts of voodoo I'm not very familiar about, having worked mostly with bare microcontrollers (no FreeRTOS involved).So, when you call poll() on the sysfs endpoint the thread blocks, waiting for a level change on the pin, coherent with the edge selected; once the transition occurs, the interrupt fires and sysfs will notify (somehow) the thread polling the endpoint, allowing it to execute ASAP.
It has its limits compared to a kernel driver, but for my frequency range (10-20hz) headroom should be plenty.
Same rules for basic ISRs apply, so code executed must be minimal, like setting a flag and let the main thread do the heavy lifting, or in this specific case compute the difference between the time now() and the last time this function was called.Sysfs itself is quite dated, i read somewhere that the version I'm using was deprecated some 3 years ago, but with the module i have it's the simplest option available.
I totally agree with your observations about the issue being in the OS, somewhere, for now I'll just move on to the next toy project, but i will regularly check back on this thread to see if more impressions come in, an apparently simple issue revealed itself to be a rather intricate mess :)
