I have tested it with another output to drive the input and lower debounce settings which works. however my point is how does it make sence that a rising event can occur without a previously falling event on the same pin?
No, there is no debounce for rising or falling. Debounce doesn’t care falling or rising.
Any interrupt within debounce range will be ignored, no matter rising or falling. So it is normal if you see 2 rising or 2 falling.
Following your image,
rising, then falling, because 20ms between them
but next rising won’t be raised. because only 10ms from last falling interrupt.
Okay but then again for a logic signal that doesn’t make any sence… correct me if I am wrong but isn’t the idea for a debounce to make sure what you have illustrated does get detected as two events becuase the short rising edge is seen as noise and therefore no state change has occurred? which means the signal hasn’t changed and therefore no new event should be raised?
I think there are 2 ways to look at this. Debounce stops events for the debounce time and then reactivate after. This is what TinyCLR does today. This means that you will see an mismatch between the rising and falling count.
The other case is we guarantee the rising/falling order but then the system must send the opposite state after the end of the debounce but only do it the current state is actually the opposite state. This sounds simple but can be very tricky as noise and changes can happen at any given random time.
Anyway, looks like it has been is added to the list to be investigated.
@SoftcontrolFrederik I am thinking more about this! While I agree with you, can you please share a real life example on when this maybe a concern? I do not see with a push button and do not see it with a GPIO. I only see it when I induce random noise.
An application example could be a power or heat meter that sends pulses as the measurement increments indicating power or heat consumption.
If you count pulses on either falling or rising edge. The current debounce system will cause falsely counts on a noisy signal because it does not guarantee a valid state change has occurred LOW->HIGH->LOW but your system would accept LOW->LOW or HIGH->HIGH as valid changes as @Dat_Tran showed in the picture above.
May I suggest adding a option like this for the input system:
I’ve attempted to updated to v126.96.36.19900-RC1 but keep getting no entry point found when deploying. I have updated FW on SC20xxx, VS2022 but I assume the Nuget packages also requires update but no new packages found even when clicked include prerelease.