-
|
Folks, on stm32, I am observing something rather strange and I was wondering if anybody has ever come across that. None of my code is touching this LED or the button. I already replaced the board, suspecting a hardware issue. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 2 replies
-
|
Same in my Site on samd21 . My.feeling is that this is related to progbutton and rhe debouncing |
Beta Was this translation helpful? Give feedback.
-
|
Um... strange. Ok, I am not alone with this. Makes me feel better. I think you might be right. Let's assume something is causing that edge event, i.e., button-up. I reckon bad board design... without proper hardware debounce. Now, the below code indeed only prevents that a single button press is detected as more than one. Sort of a cool-down time of 200ms. Line 21 in 4f6c837 The code does not require a button press to be sufficiently (=humanly) long. If we get a single event upset pulling the pin down for a few millis, we would indeed see progmode toggle. With the current interrupt logic we cannot detect this reliably. Options... Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
There is no 'strong' pull-up on most boards. This means that the input
impedance is rather high and makes it sensitive to interferences.
This has nothing to do with debauncing. Debaucing would prevent the event
to trigger more than once on a single button press.
To get rid of this the best approach would be adding a stronger Pull-up and
maybe a small capacitor to the input.
To work around this in Software you could ignore short pulses.
Not using interrupts will only reduce the frequency the issue occurs, but
not the source of the problem.
Marc
Am 10. Mai 2022 21:05:43 schrieb rueckix ***@***.***>:
… Um... strange. Ok, I am not alone with this. Makes me feel better. I think
you might be right.
Let's assume something is causing that edge event, i.e., button-up. I
reckon bad board design... without proper hardware debounce.
Now, the below code indeed only prevents that a single button press is
detected as more than one. Sort of a cool-down time of 200ms.
https://github.com/thelsing/knx/blob/4f6c837b78603dbdfc67c192d116ce9c78be4f57/src/knx_facade.cpp#L21
The code does not require a button press to be sufficiently (=humanly)
long. If we get a single upset event pulling the pin down for a few millis,
we would indeed see progmode toggle. With the current interrupt logic we
cannot detect this reliably.
Options...
a) handle on-CHANGE interrupts
b) do away with interrupts altogether
c) reset progmode periodically
Thoughts?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
|
Right, that's what I meant when suggesting detect a reasonably long button press. The problem is the current interrupt logic in the code. It just triggers on RISING. To ignore short pulses, we need to determine their length. I was wondering if there is a preference in this community for either of the proposed options. If using interrupts, we need to handle state and timestamps across interrupts. Alternatively, the entire logic is implemented without interrupts. Third option is to accept the fact and periodically reset the progmode. |
Beta Was this translation helpful? Give feedback.
-
|
oh sorry you are right, debouncing is only in case you press the key, in your case should be the pull up resistor. |
Beta Was this translation helpful? Give feedback.
-
|
The software should check if the button was pressed long enough IMO. |
Beta Was this translation helpful? Give feedback.
The software should check if the button was pressed long enough IMO.