The last log resulted in a loopback of the pushbuttons to the LEDs. There's no switch debouncing.
This step will add switch debouncing to the pushbuttons. It will still do loopbacks (baby steps), but the pushbuttons will be debounced.
It would be helpful to know when the scan is completed. This will also reduce the effort to debounce since the switches are read every ~1 mS. To do this, a signal should be sent to the peripheral bus. A single write to a defined address should do the job.
IOP16 Memory Map
Address | R/W | Function |
---|---|---|
0X00 | R | Pushbuttons(31..24) |
0X01 | R | Pushbuttons(23..16) |
0X02 | R | Pushbuttons(15..8) |
0X03 | R | Pushbuttons(7..0) |
0X04 | R | I2C Data |
0X05 | R | I2C Status |
0X06 | R | I2C Interrupt (polled) |
0X00 | W | LEDs(31..24) |
0X01 | W | LEDs(23..16) |
0X02 | W | LEDs(15..8) |
0X03 | W | LEDs(7..0) |
0X04 | W | I2C Data |
0X05 | W | I2C Control |
0X06 | W | SCAN STROBE |
The SCAN STROBE address signals a frame was just scanned.
Created a new branch which latches the pushbuttons every scan. It runs the code FP01_LOOP2. The result is still not debounced, but the 32-bits of pushbuttons are latched every frame.
Debouncing
Debouncing consists of counting the number of consecutive frames the button is pressed. With an ~1 mS frame rate that would be a count of maybe 50 or so. That's long enough for the switches to settle and short enough that the delay time is reasonable.
A six bit counter would be 64 mS. Seems about right. Start the counter when the button is pressed. Reset the counter if the pushbutton is un-pressed (or still bouncing).
Created a new branch with the debounced pushbuttons. It runs the same FP01_LOOP2 code.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.