From 6d8787164b077ace68fcb1532c8e7600c5df7538 Mon Sep 17 00:00:00 2001 From: Taylor Yu Date: Sun, 29 May 2022 19:58:46 -0500 Subject: [PATCH] improve STOP/START handling Respond immediately when we get a STOP or repeated START while still selected. Otherwise, a START condition immediately preceded by a STOP could be missed. This probably will result in more clock stretching, but the ATmega firmware doesn't seem to handle retries, so it probably implicitly depends on the keyscanner doing clock stretching anyway. Anyway, the ATmega firmware seems to only issue STOPs when reading, so it's probably not too important in practice. (I only noticed when trying to do back-to-back LED commands that ended in STOPs.) Signed-off-by: Taylor Yu --- firmware/twi-slave.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/firmware/twi-slave.c b/firmware/twi-slave.c index f5b7be5..5a2f7c5 100644 --- a/firmware/twi-slave.c +++ b/firmware/twi-slave.c @@ -125,12 +125,14 @@ ISR(TWI_vect) { break; case TW_SR_STOP: // A STOP condition or repeated START condition has been received while still addressed as Slave + // Clear the condition immediately, so we're less likely to miss + // a START that immediately follows a STOP, and can still match + // our address + TWI_Start_Transceiver(1); // Either way, treat it as end of transmission if (TWI_Rx_Data_Callback) { TWI_Rx_Data_Callback(TWI_buf, TWI_bufPtr); } - // Release the bus and re-enable reception in un-addressed mode - TWI_Start_Transceiver(1); break; case TW_SR_DATA_NACK: // Previously addressed with own SLA+W; data has been received; NOT ACK has been returned