开云体育

Ashar,

I'm an old sbitx DE user, but I have looked at your newest zbitx? code a little.? Your new change using interrupts insures the state of the key/paddle is updated in a global variable in a very timely fashion. So you have made that end of the problem even better than it needs to be.?

You have always noted in the code comments that you don't want CW sending loop reading the gpio pins 96,000 times per second.? But even now when you have accurate/fresh data stored in those variables I think you may not sample them often enough.? I verified this on my sbitx DE (but I see some changes to tick counts in the zbitx so I may be wrong) but it seems that ui_tick() does not call modem_poll() often enough - so modem_poll doesn't get called to go use that nice fresh input!

Good luck with the zbitx - it looks great!

Mike - KB2ML


Ashhar Farhan
Apr 2? ?#116851? ?

Ron, I would like you to review the code:
1.
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.
- f

--
Mike KB2ML