You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Got a general question about the comms interface between the uC running QMK firmware and the transciever. As I understand it, the interface is pretty simple — the dongle writes s and gets 11 bytes in return.
It looks like the 0.16.x redox_w firmware issue (qmk/qmk_firmware#16553) was caused by switching QMK's UART routines from non-blocking to blocking.
It looks like QMK firmware often writes the first byte, but then it either doesn't successfully send it or the the response doesn't come through. In turn, QMK is stuck waiting for UART data to arrive. That's the reason for the keyboard freeze.
As a general idea (and based on your experience), would it make sense to add status or a healthcheck command to the transciever? In this case nRF could respond to indicate whether it's good to go or not. This I guess could be queried on each matrix scan in QMK and shown on LEDs if an unexpected state is reached.
Hi @mattdibi
Got a general question about the comms interface between the uC running QMK firmware and the transciever. As I understand it, the interface is pretty simple — the dongle writes
s
and gets 11 bytes in return.It looks like the
0.16.x
redox_w firmware issue (qmk/qmk_firmware#16553) was caused by switching QMK's UART routines from non-blocking to blocking.It looks like QMK firmware often writes the first byte, but then it either doesn't successfully send it or the the response doesn't come through. In turn, QMK is stuck waiting for UART data to arrive. That's the reason for the keyboard freeze.
As a general idea (and based on your experience), would it make sense to add
status
or ahealthcheck
command to the transciever? In this case nRF could respond to indicate whether it's good to go or not. This I guess could be queried on each matrix scan in QMK and shown on LEDs if an unexpected state is reached.This PR qmk/qmk_firmware#17203 resolves the issue.
The text was updated successfully, but these errors were encountered: