Improve consistency for reading momentary buttons presses

[GM-Script-Writer-62850]

I am using ESwitch with uasyncio to detect button presses on my PICOs (i'm using cheap mini monetary buttons from ebay/ali-express)

what can i do to make button presses more consistent aside from adding a MLC between the button and the GPIO pin's safety resistor

note that EMI getting into the wire and giving a false positive would be worse than a missed press

[peterhinch]

It would help if you could describe the exact nature of the problem you're experiencing. Note that internal pullup resistors tend to be of quite a high value, increasing the risk of EMI. I always add an external resistor (typically 1KΩ) to 3.3V. If the switch is connected by a very long lead, other recommendations may apply.

[GM-Script-Writer-62850]

I have 3 PCIOs deployed, 2 are on the same power supply

I am using these 2 wiring methods

• 3.3v -> Button -> 1K ohm -> GPIO (Internal pull down)
• Ground -> Button -> 1K ohm -> GPIO (Internal pull up)

I do have some long leads ranging from 3ft (1m) to 25ft (7.5m) using telephone wire

my most consistent button out of ~7 or so is a little special in the wiring as it has direct access to the main ground plain/wire bypassing the PICO's micro usb plug (the data wire is not short)

just feels like quite often i press the button and it never triggers the event, sometimes it can take 3 tries before it registers

[peterhinch]

I don't think the series 1KΩ resistors are helping.

In general the best way to wire pushbuttons is between the input pin and ground, with a 1KΩ resistor between the pin and 3.3V. This resistor aids the internal pullup, ensuring that the circuit has a low impedance when the button is open. The reason for preferring a button connection to ground when there is external wiring is that typical fault conditions are a short circuit to ground. Sending out 3.3V on the external wiring exposes a risk of a short between 3.3V and gnd. While this wouldn't break anything, it would crash the processor.

The other possibility is a software problem. Please check whether a sustained press (> 1s) on the buttons is reliably detected. If this is the case you may have a task which is hogging the processor. The ESwitch module uses polling to detect the button state. This is reliable providing that all tasks yield regularly to the scheduler (by calling await asyncio.sleep(t) - or sleep_ms(t)). If your system has a task which sometimes fails to yield for a significant time, short presses can be missed.

Regular yielding is a basic part of good asyncio design.

[GM-Script-Writer-62850]

did not think it mattered what side the resistor was on, i was under the impression the point was to protect the GPIO pin and by placing it at the GPIO pin it would be protected in event if a wiring fault

the awaiting stuff should be good, there are not long processes running on core 0, aside from detecting the inputs it is just setting/testing variables and setting GPIO pins

i do have a async web server process active, but without client(s) it should not be eating time, it is there to serve as a input from other devices as well as be a debug readout

the only 'long' process i have runs on the second core (so gland i can finally do this with my W5500 PICOs without lockups)

long presses are not a issue, doubles are not reliable (though i suspect one of my buttons is a POS, replacing it is on the to do list)

• Maybe i should try using a screwdriver to the back of the button instead of the button more often...

[peterhinch]

I'm suggesting this wiring:

Re protecting the inputs from ESD there are various solutions with varying levels of protection. In my opinion the best approach is first to get the system working reliably. Protection circuitry can be added if you think/find it necessary.

[GM-Script-Writer-62850]

Would having a network enabled cause it to miss? given async server is idle also assume there is not outbound network activity

i get the same issue on both my PICO W and W5500 PICOs, the only long process is reading DHT22s which is done on the second core, the only thing main core does with it is tell the second core to go and read all of them (async message)

how do keyboards and game pads not miss inputs? maybe it is the performance gains of C? and on that note i have seen the cheapest keyboard i could get on newegg wake the computer from sleep mode when opening the closet on the other side of the room (70% or more reproduction success rate)

[bidrohini]

You can try adding external pull-up or pull-down resistors with lower values, such as 10kΩ, to provide a stronger pull on the GPIO pin.

[peterhinch]

Aside from the electrical issues another possibility is the asyncio application code. If a task is blocking for long periods,this can cause button presses to be missed. Drivers such as eswitch run a task which polls the switch. If a blocking task prevents this from running at a high enough rate, state changes can be missed.

To put this into context, micro-gui uses pushbuttons (or an encoder) for control. It has been developed and extensively tested on various platforms. Button presses are not missed unless you very deliberately give an extremely brief press.

If running with a large screen, the transfer of the frame buffer to the screen would block for a period sufficient to affect the reliability and speed of response to pushbuttons. Various measures are taken to ensure this does not occur, including splitting the update into several segments and allowing the scheduler to run between each.

[GM-Script-Writer-62850]

i should not have any long running code on core 0, at least from a idle state (eg not a second press while the 1st is in progress)

• note readSensors is runs on core 1
  source.zip

this code is very basic, unless the existence of a idle network connection cause it to miss idk how i could be a software issue, maybe the buttons are flaky, i have one that is i will swap out...

[peterhinch]

There are various debugging tools which can help with identifying blocking. Or you could measure it:

async def measure():
    global block_time
    block_time = 0
    while True:
        start = time.ticks_ms()
        await asyncio.sleep_ms(0)
        block_time = max(block_time, time.ticks_diff(time.ticks_ms(), start))

Strictly this doesn't measure how long another task blocks. It measures the worst case duration of cumulative blocking by concurrent tasks, and gives an idea of how this is affecting the polling frequency.