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 <[email protected]>

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