Re: zbitx cw performance problems solved?
|
I believe Ashhar has already handled the interrupt recognition on key closure.? ?The problem appeared to be "doing something as a result" - which impacts other portions of the system.? ?That is where the slow polling was appearing to cause the problem.? ?Speeding up THAT part made a HUGE improvement in the sBitx and Erik's results with the zBitx appeared to be the same improvement.? ?Now Ashhar is contemplating integration.? ?
Gordon KX4Z
Unfortunately, I haven't received my zBitx yet, but as I cen see from the schematic diagram: , the key (J3) is connected to pins GPIO7 (PTT) and GPIO21 (R-DASH).
Both those pins are interrupt capable (correct me if I'm wrong). The libgpiod offers a possibility where the thread sleeps waiting for the change of the state of a set of interrupt capable GPIOs. Can't that be used to improve the latency instead of periodic polling?
In the worst case, the handling of the interrupt of selected pins can be implemented in the kernel space.
(A few years ago I had to write a few kernel drivers that connected to the GPIO subsystem in linux (e.g. or ). They were not used for low-latency handling interrupts, but that's possible as well.)
?
73,
Wojtek SP5DAA
|
