What about being interrupt-driven instead of using timer-based polling? ?It looks like so far it’s done only for the encoders. ?
27006ea3 sbitx_gtk.c ?wiringPiISR(ENC2_A, INT_EDGE_BOTH, tuning_isr);
27006ea3 sbitx_gtk.c ?wiringPiISR(ENC2_B, INT_EDGE_BOTH, tuning_isr);
I was going to ask at some point anyway: what are the advantages or reasons for choosing WiringPI? ?I see there are a few GPIO libs to choose from, and don’t have much experience with RPI GPIO yet. ?(Although I did manage to read the encoders in a separate program.) ?Maybe it turns out that some make this sort of thing easier than others?
Another conventional solution would be to use a microcontroller for real-time aspects and queue up events over USB or a serial port. ?But it adds cost unless you can use one that is already needed anyway, or use a chip that has programmable I/O features.
toggle quoted message
Show quoted text
On Sep 30, 2024, at 6:28?PM, Ashhar Farhan <farhanbox@...> wrote:
The main challenge is to improve the response time of linux. It is Not a real time kernel.
The best way is to memory map the gpio for fast polling. That means running it at super user privilige.
The K16 EXT Keyer Kit which I have Is a very in-depth manual for a simple device. Also it brings back the concept of transmitter on / off timing as Steve has built in the functions of transmitter timing as part of the keyer and has separate outputs for the Transmitter PTT and the transmitter keying circuits. This is something that was very common with the older tube transmitters (my old Johnson Valiant, and HQ-170 Receiver) the good old days all 83 pounds of transmitter, just what you want for a POTA Hi Hi and do not forget just throw that in your back pack and go SOTA, S-U-R-E -!!!
