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 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
sand gets 11 bytes in return.It looks like the
0.16.xredox_w firmware issue (https://github.com/qmk/qmk_firmware/issues/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
statusor ahealthcheckcommand 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 https://github.com/qmk/qmk_firmware/pull/17203 resolves the issue.