Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Button with external resistor bug as for #2012 #2013

Merged
merged 25 commits into from
Jan 25, 2023

Conversation

raffaeler
Copy link
Contributor

@raffaeler raffaeler commented Jan 15, 2023

This PR implements solution 1 and 3 proposed in #2012

I ask the reviewers whether they prefer:

  • option 1 (adding a single parameter to the existing constructor)
  • option 3 (adding two ctor overloads)

In case of option 3, please tell me whether you prefer to:

  • mark the old ctors as obsolete
  • replace the two boolean values with an enum
Microsoft Reviewers: Open in CodeFlow

@ghost ghost added the area-device-bindings Device Bindings for audio, sensor, motor, and display hardware that can used with System.Device.Gpio label Jan 15, 2023
@raffaeler
Copy link
Contributor Author

After a rebase, this PR got all the doc changes that has already been merged in main. Don't know why.
The only changes of this PR are in the folder src/devices/Button (including its README.md)

src/devices/Button/GpioButton.cs Outdated Show resolved Hide resolved
src/devices/Button/GpioButton.cs Outdated Show resolved Hide resolved
@raffaeler
Copy link
Contributor Author

Since this PR introduce a source and binary breaking change (the old two ctors were replaced with different parameters), I tried to run the command build -pack /p:GenerateCompatibilitySuppressionFile=true as discussed in the Triage.

Anyway the command failed with the following output:

H:\Samples\_forks\iot\src\devices\Arduino\samples\Monitor\Arduino.Monitor.cs(90,59): error CS1503: Argument 2: cannot convert from 'System.Device.Gpio.GpioController' to 'bool' [H:\Samples\_forks\iot
\src\devices\Arduino\samples\Monitor\Arduino.Monitor.csproj::TargetFramework=net6.0]
H:\Samples\_forks\iot\src\devices\Arduino\samples\Monitor\Arduino.Monitor.cs(90,82): error CS1503: Argument 4: cannot convert from 'System.Device.Gpio.PinMode' to 'System.Device.Gpio.GpioController?'
 [H:\Samples\_forks\iot\src\devices\Arduino\samples\Monitor\Arduino.Monitor.csproj::TargetFramework=net6.0]
H:\Samples\_forks\iot\src\devices\Arduino\samples\Monitor\Arduino.Monitor.cs(90,97): error CS1503: Argument 5: cannot convert from 'System.TimeSpan' to 'bool' [H:\Samples\_forks\iot\src\devices\Ardui
no\samples\Monitor\Arduino.Monitor.csproj::TargetFramework=net6.0]
    0 Warning(s)
    3 Error(s)

Time Elapsed 00:03:42.99
Build failed with exit code 1. Check errors above.

Apart the compatibility suppression xml file not being generated, the rest of the PR is good and ready for review/approval.

@raffaeler
Copy link
Contributor Author

@pgrawehr I had to change the ctor call in Arduino.Monitor.cs.
Since previously the PinMode was Input, I don't know if it was pull-up or pull-down.
Please take a look at the current values and tell me whether I should change them (I don't know how the Arduino board is configured).

@raffaeler
Copy link
Contributor Author

@joperezr I see helix failing with this error. Is there anything I can do?

    System.Device.Gpio.Tests.SysFsDriverTests.AddCallbackFallingEdgeNotDetectedTest [FAIL]
      Assert.False() Failure
      Expected: False
      Actual:   True
      Stack Trace:
        /_/src/System.Device.Gpio.Tests/GpioControllerTestBase.cs(246,0): at System.Device.Gpio.Tests.GpioControllerTestBase.AddCallbackFallingEdgeNotDetectedTest()

@joperezr
Copy link
Member

I see helix failing with this error. Is there anything I can do?

Those are the hardware tests. Given their nature and what they test, they tend to be flaky sometimes. Usually we just re-run to make sure it was just a fluke. In this case we can be pretty sure about it since your PR isn't really touching S.D.G and the other Linux Debug build (which also runs the tests) passed.

@raffaeler
Copy link
Contributor Author

Those are the hardware tests. Given their nature and what they test, they tend to be flaky sometimes. Usually we just re-run to make sure it was just a fluke. In this case we can be pretty sure about it since your PR isn't really touching S.D.G and the other Linux Debug build (which also runs the tests) passed.

Thanks, but recently I got merge permissions, but not the azp ones :-)

@pgrawehr
Copy link
Contributor

@pgrawehr I had to change the ctor call in Arduino.Monitor.cs. Since previously the PinMode was Input, I don't know if it was pull-up or pull-down. Please take a look at the current values and tell me whether I should change them (I don't know how the Arduino board is configured).

The button is pulled down with an external resistor in the example. See src\devices\Arduino\ArduinoSample_Monitor.png for the schematic of the example.

@raffaeler
Copy link
Contributor Author

The button is pulled down with an external resistor in the example. See src\devices\Arduino\ArduinoSample_Monitor.png for the schematic of the example.

@pgrawehr
I just commited and pushed the change with isPullUp=false and HasExternalResistor=true on the Arduino.Monitor.cs.

@raffaeler
Copy link
Contributor Author

@pgrawehr do you have any idea why the Linux Build Build_Release failed twice in a row?
If you think that this is a random failure, please azp this PR again.
Thank you

@pgrawehr
Copy link
Contributor

@pgrawehr do you have any idea why the Linux Build Build_Release failed twice in a row?
If you think that this is a random failure, please azp this PR again.
Thank you

Yea, that particular test is flaky. I'll check a bunch of the latest builds and disable it if it's really always the same.

src/devices/Button/GpioButton.cs Outdated Show resolved Hide resolved
src/devices/Button/GpioButton.cs Outdated Show resolved Hide resolved
Copy link
Member

@Ellerbach Ellerbach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PullUp/PullDown are not supported everywhere. So you can't create them just like this. You have to test and then keep the chosen mode to compare later on.

_debounceTime = debounceTime;
HasExternalResistor = hasExternalResistor;

_eventPinMode = isPullUp ? PinMode.InputPullUp : PinMode.InputPullDown;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is dangerous! Because some board do not support PullUp/PullDown. It's the reason why originally you have to pass the pull type.
If you want to do something like this, you need first to check if the pin mode is supported, if not, then choose one that is a default one.
See here for the good way to do it: https://github.com/dotnet/iot/blob/main/src/devices/Dhtxx/DhtBase.cs#L192

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ellerbach I am aware that not every pin can be internally pulled up or down.
I didn't change the logic of the original author, I just added support for the external pullup/down resistor.

I was not aware of IsPinModeSupported in GpioController. Good to know, Now I can throw an exception if it's not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I revised two cases:

  • if the button can be configured as input (certain gpio can only be output)
  • if the button can be configured with the configuration deriving from isPullUp and HasExternalResistor

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine. If the mode is not supported, it will throw, which is expected, because it's an user error.

@@ -75,7 +101,7 @@ private void PinStateChanged(object sender, PinValueChangedEventArgs pinValueCha
switch (pinValueChangedEventArgs.ChangeType)
{
case PinEventTypes.Falling:
if (_pinMode == PinMode.InputPullUp)
if (_eventPinMode == PinMode.InputPullUp)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, you can't really do it like this is pull up is not supported

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The _eventPinMode is always good because it is used to keep track if it is either pulled-up internally or externally.
The validation only goes when I open the pin. But if the resistor is external, the raising/falling logic is basically the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make this more clear: _eventPinMode is not used in OpenPin.
I just 'reused" the enumeration to keep track whether the button transition is high to low or vice-versa.

Copy link
Member

@Ellerbach Ellerbach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for the tweaks, looks good to me now.

@raffaeler
Copy link
Contributor Author

Thanks a lot for the tweaks, looks good to me now.

Could you please you merge it?

@Ellerbach Ellerbach merged commit bf03b0e into dotnet:main Jan 25, 2023
@raffaeler raffaeler deleted the button_resistor branch January 25, 2023 20:44
@github-actions github-actions bot locked and limited conversation to collaborators Dec 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-device-bindings Device Bindings for audio, sensor, motor, and display hardware that can used with System.Device.Gpio
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants