4 ms·

I urge you to consider using an RC network with a hex inverter to debounce your switch input without resorting to a 100ms delay. I've wasted enough hours to kno

I urge you to consider using an RC network with a hex inverter to debounce your switch input without resorting to a 100ms delay. I've wasted enough hours to know that the best kind of software debounce is a few resistors and capacitors. https://mayaposch.wordpress.com/wp-content/uploads/2018/06/debounce_rc.png?w=640 https://mayaposch.wordpress.com/wp-content/uploads/2018/06/d...

kragen 2y ago
I feel like the diode in this schematic is the wrong way around for a normally open switch: it speeds up the keyrelease event when the switch opens instead of the keypress event when it closes. But I think the 100ms delay Ken mentions was intended for a different purpose: to wait for all the fingers in the character to be detected. I think a much better approach would be to wait for one of the keys to be released before registering a character. Isn't that what Engelbart did? I suspect this timing-based approach explains why Ken found it so difficult to use. As I understand it, Baudot's original chording keyboard instead mechanically locked the keys down until the character was transmitted over the telegraph line. The telegrapher had time to enter his next character while the system was transmitting the characters of his colleagues, interleaved with his own at a fixed baud rate.
- peteforde 2y ago
  Oh, that (waiting for all fingers to be detected) does indeed change how I would approach the scenario, and blew past me in my initial reading. That all said, even with 100ms cycles I would hardware debounce the inputs, capture the keystrokes with an ISR to set some semaphore variables, and then create a 100ms loop that checks the current value (and resets) those semaphore variables. Eliminating switch bounce allows far more elegant software handling of the values you're reading, so Ken could turn his attention and development energy towards things like sliding time windows (100ms starting from the first keydown, for example) instead of trying to boil the ocean cancelling bounces.
  - kragen 2y ago
    Yeah, the 100ms wait after stability probably avoids any need to debounce. You need to debounce if you want to detect both keypress and keyrelease events reliably, though. For mass-production products it's cheaper to add 100 lines of code to your firmware than to add a resistor to your PCB, much less a diode, capacitor, and two resistors, but for prototypes and low-volume designs it's less clear. WRT ISRs, plausibly in this case the microcontroller can just poll instead of using interrupts. You probably don't mean "semaphore"; semaphores are a blocking construct, and if there's one thing you can't do in an ISR, it's block.
    - peteforde 2y ago
      You're right, I should have chosen better words. I merely meant setting a flag bit from 0 to 1, later to be picked up by your loop. Since actual semaphore was communicated with flags... I have yet to see the perfect software debounce algorithm. I've come to believe that it is a Sisyphean task. Meanwhile, Schottky diodes are extremely well-suited to the task. You might consider 100 lines worth of complexity to make a switch work to be free, but I won't lose any sleep believing otherwise.
      - kragen 2y ago
        Most of software is Sisyphean. 100 lines of code doesn't add any cost to your BOM, just NRE, and it's easier to simulate.

kragen 2y ago

I feel like the diode in this schematic is the wrong way around for a normally open switch: it speeds up the keyrelease event when the switch opens instead of the keypress event when it closes. But I think the 100ms delay Ken mentions was intended for a different purpose: to wait for all the fingers in the character to be detected. I think a much better approach would be to wait for one of the keys to be released before registering a character. Isn't that what Engelbart did? I suspect this timing-based approach explains why Ken found it so difficult to use. As I understand it, Baudot's original chording keyboard instead mechanically locked the keys down until the character was transmitted over the telegraph line. The telegrapher had time to enter his next character while the system was transmitting the characters of his colleagues, interleaved with his own at a fixed baud rate.

peteforde 2y ago
Oh, that (waiting for all fingers to be detected) does indeed change how I would approach the scenario, and blew past me in my initial reading. That all said, even with 100ms cycles I would hardware debounce the inputs, capture the keystrokes with an ISR to set some semaphore variables, and then create a 100ms loop that checks the current value (and resets) those semaphore variables. Eliminating switch bounce allows far more elegant software handling of the values you're reading, so Ken could turn his attention and development energy towards things like sliding time windows (100ms starting from the first keydown, for example) instead of trying to boil the ocean cancelling bounces.
- kragen 2y ago
  Yeah, the 100ms wait after stability probably avoids any need to debounce. You need to debounce if you want to detect both keypress and keyrelease events reliably, though. For mass-production products it's cheaper to add 100 lines of code to your firmware than to add a resistor to your PCB, much less a diode, capacitor, and two resistors, but for prototypes and low-volume designs it's less clear. WRT ISRs, plausibly in this case the microcontroller can just poll instead of using interrupts. You probably don't mean "semaphore"; semaphores are a blocking construct, and if there's one thing you can't do in an ISR, it's block.
  - peteforde 2y ago
    You're right, I should have chosen better words. I merely meant setting a flag bit from 0 to 1, later to be picked up by your loop. Since actual semaphore was communicated with flags... I have yet to see the perfect software debounce algorithm. I've come to believe that it is a Sisyphean task. Meanwhile, Schottky diodes are extremely well-suited to the task. You might consider 100 lines worth of complexity to make a switch work to be free, but I won't lose any sleep believing otherwise.
    - kragen 2y ago
      Most of software is Sisyphean. 100 lines of code doesn't add any cost to your BOM, just NRE, and it's easier to simulate.