Hello,
I think that one aspect needs to be addressed in more detail.
PG1 wrote:
5. If a software timer associated with a certain key times out, that key input is un-masked so that it can cause another KBI Int to occur.
I will assume that this part of the operation is a polling process within the main loop.
The active input cannot be unmasked until after the switch has been released. If an unmasked input is active, it is not possible to detect a closure at the other three inputs. In this case the timeout period represents a delay until the testing for switch release commences.
To allow for further contact bounce when the switch is released, a further timout period should expire before the KBI input is unmasked.
For the de-bounce timing, I would tend to utilise a simple "tick" timer at say, 1 to 5 ms intervals. Within the timer ISR, each debounce timing register would be tested, and it non-zero would be decremented. You might allow for debounce intervals of 50 to100ms. Therefore, timeout will have occurred when each register becomes zero - no additional timeout flags are required. The timing uncertainty will be one tick interval.
Note that the debounce timing registers should be 8-bit so that the write process will be atomic. Otherwise, interrupts would need to be globally disabled and re-enabled when the debounce timeout period was set.
Regards,
Mac
