In the progress of testing the input events I found that it is easy to generate an uneven count of rising or falling events.
My assumption is following: for every rising event there would have been a falling event before it and for every falling event there would have been a rising event before it.
Is my assumption wrong? because it easy to generate uneven count of rising / falling events when manual shorting the input to ground.
var gpio = GpioController.GetDefault();
var button = gpio.OpenPin(SC20260.GpioPin.PJ2);
button.DebounceTimeout = new TimeSpan(0, 0, 0, 0, 100);
Debug.WriteLine($"Debounce: {button.DebounceTimeout.TotalMilliseconds}");
button.SetDriveMode(GpioPinDriveMode.InputPullUp);
button.ValueChangedEdge = GpioPinEdge.FallingEdge | GpioPinEdge.RisingEdge;
button.ValueChanged += Button_ValueChanged;
static int total = 0;
static int rising = 0;
static int falling = 0;
static void Button_ValueChanged(GpioPin sender, GpioPinValueChangedEventArgs e)
{
if (e.Edge == GpioPinEdge.FallingEdge)
{
Debug.WriteLine("Falling");
falling++;
}
if(e.Edge == GpioPinEdge.RisingEdge)
{
Debug.WriteLine("Rising");
rising++;
}
total++;
if(total % 2 == 0)
Debug.WriteLine($"Rising:{rising}, Falling: {falling}, Total: {total}");
}
I think manual short the pin causes many noises. Also, take a look at 100ms debounce. If Rising at 20ms and Falling at 90ms, next Rising is 120ms and next Falling 190ms.
The result could be two Rising in first 200ms and no Falling triggered.
You can use another pin to write low / high, connect that pin to interrupt pin. Pick proper debounce is good way to test.
The debounce make sure there is no event in debounce range. It doesn’t mean rising now and next is falling.
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:
This will result in delaying events but ensures what is been reported by the input event system actually is a valid change and not a noisy edge getting through debounce.
I’ve attempted to updated to v2.2.0.3000-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.
