Input events, uneven count of rising / falling events

TinyCLR OS
#1

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.
image

     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}");
    }
#2

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.

#3

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?

#4

It could be raised or not, depend on debounce.

#5

Then if i understood your debounce system it works like this?

image
image770×545 24.6 KB

would this generate two rising events? but filter out the falling event? because of debounce set to 15ms.

#6

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.

#7

Could you then explain how two rising events or two falling events can be raised in a row?

#8

Sorry if my image looks not good as yours :)).

image

#9

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?

1 Like
#10

We may add that in future.

Gpio interrupt. · Issue #1127 · ghi-electronics/TinyCLR-Libraries (github.com)

#11

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.

#12

@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.

#13

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:

image
image905×572 24.4 KB

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.

#14

I would think that debounce would not be used in a situation where the pulse interval is used for measurements.

Any noise would be handled by the software. For example, a PID loop, or some type of averaging.

Debounce is meant for really dirty/noisy situations.

#15

I am surprised those cause noise. Are they mechanical meters? Would a small capacitor fix the problem? Then denounce would not be used.

#16

Hi, v2.2.0-preview2 supports feature you wanted. Can you please confirm it is OK or not, pls?

#17

Thanks.

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.

I will a look at a later time and test it.

#18

You have to download the nuget packages locally and add them as a package source in the nuget package manager, then also check prerelease

2 Likes