Here, we setup the ISR (interrupt service routine) to call a function called key_isr whenever the state of the paddle chages (press, release).
2. The key_isr () reads the status of the the two paddles (DASH and PTT) and stores them in global variables ptt_state and dash_state.
3. the cw sending loop has to generate 96,000 samples a second. And it cannot spend?time reading the gpio pins to see if the any new symbol (dot/dash/space) has been generated by the user. Instead, it just reads these two variables. This is done by the routine key_poll().
.4 Read key_poll (). You will note that it executes very quickly. To know what type of key we are using, it doesn't even to a string compare of the CW_INPUT settings, instead it just samples the 6th letter with is different for all the three cases (Straight, Iambic and Iambic-B).
Let me know what you think of the?implementation and if it can be improved.
On Thu, Apr 3, 2025 at 6:57?AM Ron, N6YWU via <ron.nicholson=[email protected]> wrote:
Have you considered using interrupts to handle the GPIO pins connected to the keying inputs?? Interrupts might reduce or eliminate the possibility of missing the first dot before a dash. ?
?
A priority interrupt handler would need to be written with good real-time coding practices (bounded time algorithm, no locks, no API calls that could involve memory management, etc.). ? But this should be possible.? Then post the key inputs with time stamps to be handled by the priority keying sidetone process, which perhaps will run only a few milliseconds later.? The time stamps on the interrupt data would prevent the dash from being handled before any dot, if that was the key closure sequence, and solve at least one issue with fast iambic keying that polling with a slow CPU on a loaded system might never be able to completely solve.
