Solved QElapsedTimer reporting strange values from within QThread
-
@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 :)