2 pin connections to control the key

[caligari]

Hi everyone,

In the PineTime schematic v1.0, the main button (J6 KEY) is connected to the nRF52832 MCU pins P0.13 and P0.15, both circuits are pulled-down externally and receiving VCC33 when key is pressed.


I can not figure out the motivation to use  2 MCU pins to control the key. May be is it intended to detect whether the key is there, in the case?     



Regards,
Rafa

[larzuk]

Hi!

I checked on the schematic, on the PCB, and wherever i could, but couldn't explain that.

As the label is misindicated on the schematic, my first guess was that was a non-corrected error. Then, i checked on the NRF datasheet, in case of the tri-state of the µC could serve as "debounce hack contraption", but, clearly, i have no better idea.

Debounce could be a nice one, but i doubt it.

[caligari]

As the label is misindicated on the schematic, my first guess was that was a non-corrected error. Then, i checked on the NRF datasheet, in case of the tri-state of the µC could serve as "debounce hack contraption", but, clearly, i have no better idea.

Debounce could be a nice one, but i doubt it.

If the button has 2 positions (SPDP) to indicate fully pressed and fully released, it's perfect to debounce by software and manage it with interruptions (power saving). I don't have pinetime-devkit0 at the moment... Is the button a SPDP?

[caligari]

Finally, I have tested the button in a PineTime: it is a SPST connected to P0.13 and P0.15.
I can not understand the resistors and VCC drawn in schematics, but I have It working with interrupts activating  P0.15 output-high and P0.13 input-pulled-low.

[Independent_Contact]

There are a few nRF52 anomalies that I regularly encounter which are decrease radio performance with high current or leaving floating P0.25 an P0.26, and Compile flags needed that make P0.09 and P0.10 useless because they are the NFC coil ones. So can't find any other reason.

If P0.13 is pulled low, presumably that's what your interrupting from, but why then configure P0.15 an output-high? P0.15 could be pulled low and you just set the interrupt to occur to only on one of them?

(Nrf5 SDK pin_change_int example)

    err_code = nrf_drv_gpiote_init();
    APP_ERROR_CHECK(err_code);

    nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(true);
    in_config.pull = NRF_GPIO_PIN_PULLUP;

    err_code = nrf_drv_gpiote_in_init(PIN_IN, &in_config, in_pin_handler);
    APP_ERROR_CHECK(err_code);

    nrf_drv_gpiote_in_event_enable(PIN_IN, true);

I normally use the App_button to do my debounce, and usually do a few other things to detect short / long / double / triple presses.

[cscott]

Finally, I have tested the button in a PineTime: it is a SPST connected to P0.13 and P0.15.
I can not understand the resistors and VCC drawn in schematics, but I have It working with interrupts activating  P0.15 output-high and P0.13 input-pulled-low.

One way of using this configuration would be as follows:

Usually both pins are actively driven low, which will cause zero current draw whether the button is pushed or not.

On a timer interrupt the chip wakes up and briefly pulses one of them (WLOG) P0.15 high, while configuring the other as an input.  The button is pressed if (and only if) P0.13 goes high.  This causes current draw through P0.15 during the query pulse (because of the pull down R13) and, if the button happens to be pressed, current draw in P0.13's pull down R15 as well.  So after briefly waking to query, both are dropped low again.

The series resistors R12 and R14 are pretty typical ESD protection for anything that a user could touch.  And I think the pull-down resistors R13 and R15 are typical/necessary for ESD as well (although I know very little about ESD protection circuits!), so that might put limits on what games you could play by making one of the GPIOs pull-up instead of pull-down or letting it float.

Note that the benefit of connecting both sides to a GPIO is that you can prevent current draw through a pull-up or pull-down *while the button is pressed*.  If one or the other side was passively pulled to a rail, you'd typically get current draw through a pull-up/pull-down for the duration of the button press.  (You could add a mosfet to the pull-down to turn it off and let the input float while the button is pressed to save power---some microcontrollers have software-configurable pull-up/pull-down that would do the same thing---but I think the input can't be left floating for ESD reasons.)

On the other hand, the pinetime design means you get current drawn whenever you query the button, and you need to wake up reasonably frequently (100-250ms?) to do so.  But each query can be super-fast.  Presumably the engineers did the math comparing the integrated current draw of the queries vs the current draw from the amount of button-depressed time in typical usage.  (Or they just copied the circuit from some previous engineer who'd done that math for an entirely different product/use case.)

It's an okay design, but not a clever/great one.  Depends a lot on how quickly/power-efficiently you can do the periodic poll.