GpioButtonWait - wrong expectations and output inside the code

Describe the bug The variable at will never be in “pressed” state, as the waitResult.EventTypes does not returns the type of the current event, but it returns the events we’re listening to, so it’s value is a [Flag] value: PinEventTypes.Rising | PinEventTypes.Failing see: https://github.com/dotnet/iot/blob/ae9ba984e1b637807185d648cb1c208d13f8db3e/tools/DevicesApiTester/Commands/Gpio/GpioButtonWait.cs#L76

For starters is there a HOW TO PDF?

For anyone interesting in any button event, keep this in mind:

1. pressing and releasing the button will fire both events
2. some HW might behave weird (like mine is able to fire one of the events twice if pressed in quick sequence, but the touch sensor works as expected)

A clear and concise description of what the bug is. Just a wrong output to console, but it’s a misleading stuff for starters.

Steps to reproduce Just see the console output when pressing/releasing the button.

Expected behavior So while the current code does behave as expected and just the output is not correct (expectations from some lines in the code are simply not fulfilled)…a proper way to check if button was just pressed can be achieved with a callback, see code below:

                    controller.RegisterCallbackForPinValueChangedEvent(
                        buttonPin,
                        inputEvents,
                        (object sender, PinValueChangedEventArgs pinValueChangedEventArgs) =>
                        {
                            Debug.WriteLine($"{DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss.fff")} Btn event: {pinValueChangedEventArgs.ChangeType}");

                            if (pinValueChangedEventArgs.ChangeType == PinEventTypes.Rising)
                            {
                                isOn = !isOn;
                                controller.Write(ledPin, isOn ? PinValue.High : PinValue.Low);
                            }
                        }
                        );

Actual behavior Just wrong output and well, bad expectations (badly set pressedOrReleased variable).

Versions used Latest 2020/01 RPI 3B+ .NET Core 3.1

[pgrawehr]

@joperezr I have tried hard, but couldn’t reproduce a problem as described. My setup:

• Use a square wave generator, running at 1khz
• Waiting for rising events
• Check that the result correctly indicates they were rising

I tried modifying the duty cycle of the square wave from very short to very long pulses, but I never saw a falling event being detected when reading the state just after I got the interrupt. Note that I did the test without the last change on my branch, which will - by design - never report a wrong edge if only waiting for one edge. I tried with both the Raspi implementation as well as the SysFs implementation. What I did see - and what I also expected - was that the SysFs implementation was much slower and lost a great number of events, while the Raspi implementation only lost events when they became very short (<~100us). I’ll try what happens if I’m listening on several pins at the same time. Maybe this will repro the issue.

The situation could still be improved by adding logic that compares previous from next values, as described above, but that’s optional, IMHO.

[hidegh]

@joperezr it’s .NET Core 3 used on Raspbian stretch with Raspberry Pi 3B+; Latest IotNuget at that time.

But as mentioned it’s not my code, nor a malfunction, it’s a wrong sample on the repository. The sample wrongly assumes that the property EventTypes is the type which lead to the event, but as proven in the screenshot (where the desciption is from XML summary fields, so part of the IOT documentation) the property is just the events we set to listen for (see link: https://github.com/dotnet/iot/issues/925#issuecomment-570942001).

So again, no problem on my side, Problem (bug) is in the sample code - see 1st entry, with line number attached,

Solutions:

1. keep current property as is, it’s called EventTypes, and based on documentation it should contains the values we listen for (so in the case of the sample both for raising and falling edges)
2. update and fix the bug in the sample project - not because of me (i already figured it out) but because of others with less exp. working with IOT
3. and a good idea would be to extend that event with a EventType property (or call it: RaisedEvent) into which the event type that occured is set.

@pgrawehr “Oh, sometimes, one needs to read the docs first…” - Is there somewhere a comprehensing documentation?