View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002334 | fsvybrid_Linux | Matrix keyboard | public | 2014-08-21 18:00 | 2014-08-22 12:01 |
| Reporter | Keller | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | fsvybrid-V2.0 | ||||
| Target Version | fsvybrid-V2.1 | Fixed in Version | fsvybrid-V2.1 | ||
| Summary | 0002334: Add cycle based scan algorithm for matrix keypad | ||||
| Description | The pure interrupt based algorithm used in the matrix keypad driver shows some unwanted restrictions. 1. It does not detect different keys that are pressed in one row at the same time 2. It does not debounce keys correctly that are pressed with a short time offset less than debounce_ms after a previous one 3. It does not work reliably if the interrupt system has no pending flags for disabled interrupts We should add a cycle based scanning algorithm to overcome these limits. | ||||
| Steps To Reproduce | Remark: as the driver uses rows for input and columns for output, we switch the roles of rows and columns when using the driver to comply with our F&S notion, where rows are outputs and columns are inputs. So in step 1 we have to press several keys in the same column (!) to trigger the error. 1. Press and hold a key. Then press a second key in the same matrix column, it will not be detected. Release the first key. It will not be detected. Release the second key. The driver will now report the first (!) key as released. 2. If a key is pressed, this issues an interrupt. The driver starts scanning the keyboard after the debounce delay, with the assumption that the key has finished bouncing by then. This is OK so far. But if a second key is pressed in the meantime before the scan takes place, it will also be detected during the scan. But this key is still fully within the debouncing phase. It is not correct to accept and report this key. 3. Press some keys. After a while a key that was pressed but is released already will be reported as still pressed. If key repeat is active, this key repeats indefinitely until it is pressed again. The reason is that any signal changes that happen during the debounce phase when interrupts are switched off are missed. If there are pending flags, these interrupts will catch up after the scan is done and the interrupts are enabled again. But on Vybrid, where there are no such pending flags, these signal changes are simply lost. | ||||
| Additional Information | The interrupt based algorithm is very economic regarding CPU load, it is more or less 0, there are only some irregular scans when the key state changes. But some things simply can't be done with it. To detect several keys in one row you actually have to scan repeatedly. It can't be detected by interrupts alone. Fortunately a repeated scan also solves the other two problems. We can use level triggered interrupts instead of edge triggered interrupts to overcome the pending flag problem on Vybrid. And a key will only be accepted after it has not changed state for a few cycles. If the key changes state in one of the cycles during the debounce phase, it is rejected and the debounce phase starts anew. When no key is pressed, use the same interrupt system as the old method. This scan cycle algorithm is not as economic as the interrupt version. But scan cycles are done with jiffy resolution (10ms) and a full scan only takes far less than 100us. So the CPU load will be less than 1% when keys are active and 0% when waiting for an interrupt when no key is pressed. | ||||
| Forum Link | |||||
