HP 15c CE - New firmware update officially available!

[brouhaha]

I have not disassembled the ARM code in the 15C CE, but I suspect that it may be only debouncing the keyboard when the Nut processor simulation code executes a keyboard-related instruction. (But perhaps not.)

In embedded systems I develop, I normally do all of my key scanning and debounce on a timer interrupt, though when the keyboard is in a quiescent state, I stop the timer, and put things into a lower-power state. There are a few refinements to the most rudimentary key scanning code that improve reliability.

Code:


1. Initialization
    a. set all GPIO return lines as inputs iwth internal (weak) pullup

2. In quiescent state  (no keys down)
    a.  drive all  GPIO scan lines actively low
    b.  enable interrupt-on-low or interrupt-on-change for all GPIO retrn lines

2. When the GPIO interrupt occurs:
    a. disable GPIO return line interrupts
    b. set all GPIO scan lines actively high, briefly (perhaps a microsecond)
    c. set all GPIO scan lines as inputs with internal (weak) pullups
    d. set up periodic timer
    e. enable timer interrupt

3. On timer interrupt
    a. init a scan line counter to the first scan line
    b. loop
        i. drive the scan line selected by the scan line counter low (setting it as an output)
        ii. wait a short time (a fraction of a microsecond) (deals with RC time constant of parasitic capacitance and weak pullup on the return lines)
        iii. read the return lines and save the bits into an array, indexed by the scan line counter
        iv. drive the scan line selected by the counter high, briefly (perhaps a microsecond)
        v. set the scan line selected by the scan line counter back to an input with internal (weak) pullup
        vi. increment the scan line counter, and loop if greater than number of scan lines
    c. loop over keys
        i. run debounce algorithm for one key
    d. if the array of return line data has no keys pressed, AND no key in the debounce array is in the "press pending" or release-pending state, go back to the quiescent state

The actual debounce algorithm that I use, based on an array of pre-key state, has for each key two variables:
    1. current debounced state, 0 = released, 1 = pressed
    2. debounce conter, 0 = no change, 1..n = change pending

The per-key debounce algorithm is:
    1. if the key scan state == the current debounce state, reset debounce counter to 0, and return (no change)
    2. [key scan state != current debounce state] increment debounce counter
    3. if new debounce counter value < threshold, return (no change)
    4. Set the debounced state to the key scan state, set the counter back to zero, and return that the key has been pressed or released

There is a way, even on 8-bit micros, to somewhat parallelize the debounce algorithm across multiple keys, by using "vertical counters", which may have been invented by, but certainly were popularized by Scott Dattalo: https://web.archive.org/web/201408290353...ounce.html

A typical timer frequency might be between 50 and 100 Hz. The power consumption will typically be higher for higher timer frequencies, but I wouldn't recommend going much below 50 Hz.

Note that the press threshold and release threshold can be different. The thresolds are set to ceil(debounce_time / timer_interval), or slightly higher. The debounce time should be a little higher than the maximum bounce time specified for the actual switch. For isntance Cherry MX keys, commonly used for high-end computer keyboards, have a specified maximum bounce time of 5ms, assuming 16 inch per second actuation speed. (Third-party MX-compatible keys might not be as good.) Ad-hoc dome-and-contact buttons can have much longer maximum bounce times.

If the keys each have diodes, or the keys are of some other type that doesn't provide bidirectional conductivity, this can provide n-key rollover. Otherwise, it's OK for 2KRO.

I apologize in advance if there are any errors in my algorithm descriptions, as this is just off the top of my head.

The general outline of this algorithm derives from a 1977 Mostek application note by Dan Hammond for the F8 microprocessor and MK3870 microcontroller, "Using Mostek's F8 in a Scanned Keyboard Application". The application note can be found starting at page 290 (PDF page 393) of the Mostek Microcomputer 3870/F8 Data Book, 1978 edition. My main changes are the active deassertion of scan lines, and the quiescent state for more power savings.

I have no idea what the maximum bounce time of the HP 15C CE keys is, and am not going to measure it. Perhaps HP has. But from personal experience, simply increasing the debounce time without having a good debounce algorithm does not produce great results.