Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Reversing the pushbutton state -- feedback?


  • Please log in to reply
12 replies to this topic

#1 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 August 2010 - 03:49 PM

By default, the Netduino's pushbutton (SW1) acts as a reset button. But if you create an InputPort (or InterruptPort) using Pins.ONBOARD_SW1, the pushbutton becomes a GPIO input--and can be read from your C# code. We posted two videos showing how to use this feature: One of our viewers has commented that having the pushbutton return FALSE when pushed and TRUE when _not_ pushed seems backwards. This is because the GPIO is tied high (3.3V) by default and pushing the button drives it to ground (0V). Is anyone opposed to reversing this logic in firmware (i.e. pushing the button would return TRUE, releasing the button would return FALSE)? I'm not normally a big fan of making changes that could alter code functionality, but I tend to agree that the logic would be simpler if reversed. Thanks for the feedback, everyone (and in this paricular case, YouTube user smjjasdfa). Chris

#2 José Ángel

José Ángel

    Advanced Member

  • Members
  • PipPipPip
  • 39 posts
  • LocationSpain

Posted 09 August 2010 - 04:11 PM

I think that is better make the changes now, when the platform is taking off, than later. Anyway, the logical use of a button is to get TRUE when is pressed and FALSE with not, so I prefer change the behavior of the button :)

#3 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 09 August 2010 - 04:12 PM

By default, the Netduino's pushbutton (SW1) acts as a reset button.

But if you create an InputPort (or InterruptPort) using Pins.ONBOARD_SW1, the pushbutton becomes a GPIO input--and can be read from your C# code.

We posted two videos showing how to use this feature:



One of our viewers has commented that having the pushbutton return FALSE when pushed and TRUE when _not_ pushed seems backwards. This is because the GPIO is tied high (3.3V) by default and pushing the button drives it to ground (0V).

Is anyone opposed to reversing this logic in firmware (i.e. pushing the button would return TRUE, releasing the button would return FALSE)?

I'm not normally a big fan of making changes that could alter code functionality, but I tend to agree that the logic would be simpler if reversed.

Thanks for the feedback, everyone (and in this paricular case, YouTube user smjjasdfa).

Chris



I'm up for reversing it. When the button is pushed, it is usually said that it's state is TRUE.

#4 Thomas

Thomas

    Member

  • Members
  • PipPip
  • 15 posts
  • LocationDenmark

Posted 09 August 2010 - 05:03 PM

Shouldn't the SW1 button act like all the other GPIO's? If you start out by using the SW1 for input, but later on decides to use another pin for the button, it wouldn't be good to require further code changes. The way the button is wired (Pull-Up scenario) is pretty common, and having all GPIO's "inverted" wouldn't be fun is you ask me. I'd say that a LOW signal on a pin should be FALSE, and a HIGH signal should be TRUE - Including the SW1 input. Just my 5 cents... /Thomas

#5 dab

dab

    Advanced Member

  • Members
  • PipPipPip
  • 54 posts
  • LocationBellevue, WA, USA

Posted 09 August 2010 - 06:07 PM

Shouldn't the SW1 button act like all the other GPIO's?

If you start out by using the SW1 for input, but later on decides to use another pin for the button, it wouldn't be good to require further code changes.

The way the button is wired (Pull-Up scenario) is pretty common, and having all GPIO's "inverted" wouldn't be fun is you ask me.

I'd say that a LOW signal on a pin should be FALSE, and a HIGH signal should be TRUE - Including the SW1 input.

Just my 5 cents...

/Thomas


You can make a good case for either option. I think the real problem is that a Port is fairly generic, while connecting a switch to an input port is a specific use case.

A couple of suggestions:

1. Define a new switch-specific enumeration, so that ON corresponds to boolean false, and OFF corresponds to boolean true.


2. Derive a Switch class from the InputPort class, and give the Switch class semantics that make sense for a switch (reading the state as being On/Off, Open/Closed, etc.).


Option 1 is probably simpler, while option 2 may be a "next version" type of thing.

Thanks,
-David
Thanks,
~ David ~

#6 JohnH

JohnH

    New Member

  • Members
  • Pip
  • 8 posts

Posted 09 August 2010 - 06:49 PM

One the one hand, I agree with the YouTube comment. It does seem backwards to read true when the button is NOT pushed and false when it is. The dialog in the video seems to say that the value returned by the Read method would be true when the button is pushed (paraphrasing here, but the narration is something like "we can read the value of the button to see if it is pushed or not"). That to me says the value should be true if the button is pushed. On the other hand, I do understand how the true/false values get reversed in relation to how the button is physically connected. The button carries 3.3 volts when "open" (NOT pushed) and 0V when the button is "closed", so naturally 3.3V should correspond to true and 0v to false. Maybe the nomenclature should be changed a little? On the Arduino, you'd light up an LED by pushing a value of "HIGH" to the GPIO pin, not "true". This makes more sense to me because we are really talking about high and low voltages as opposed to true and false values. I hope I didn't confuse matters more! Chris, I'm really liking this open dialog you have with your user community. Keep up the good work, and keep the tutorial videos coming!

#7 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 August 2010 - 07:28 PM

Thanks for all the feedback on this, everyone! Since the pushbutton is a special case (and we want to make it easy for people to get started...not having to worry about voltage levels until they wire up a switch to one of the pins)...and based on your initial feedback...we're really leaning towards swapping the logic internally so that pushed is "TRUE" and unpushed is "FALSE". Wow, that was one long sentence :) But before we make the change, please keep the feedback coming. We want to make sure we do what's right for our users. Chris

#8 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 09 August 2010 - 07:29 PM

Chris, I'm really liking this open dialog you have with your user community. Keep up the good work, and keep the tutorial videos coming!


Thank you! And we will!

#9 xc2rx

xc2rx

    Member

  • Members
  • PipPip
  • 27 posts

Posted 09 August 2010 - 07:45 PM

Thank you! And we will!


I don't think it's a good idea to reverse it. It makes more sense to keep it as it is now. If you look at it from the electronic perspective, by default, the button is tied to +5v/+3.3v so that it won't float. When the button gets pushed, electronically, it now makes the connection to ground and therefore it is false.

It will be very confusing to people coming from an electronic background if this gets changed. Perhaps people coming from a software background should get their hands wet in electronic to understand at least the basic stuff. Just my 2 cents.

By the way, I'm a certified electronic technician and a graduate in Computer Science.

Thanks!

#10 RedHermit

RedHermit

    Member

  • Members
  • PipPip
  • 14 posts
  • LocationColorado

Posted 10 August 2010 - 04:47 AM

I scratched my head in thought when I first saw that in the videos too. My background is software and code, so it didn't quite make sense at first. Taking a closer look at the electronics side of it (and as xc2rc and others have pointed out with an excellent explanation) made things much clearer. Even though it would be easier to say change it for software people, I feel that leaving it "as is" Is the proper thing to do. I want to learn the the electronics/hardware side of what I'm coding against the right way- it's as if I'm taking a trip from my home country of software-landia to hardware-ica and I should learn the customs to make the most of my journey.

#11 xc2rx

xc2rx

    Member

  • Members
  • PipPip
  • 27 posts

Posted 10 August 2010 - 05:44 AM

Even though it would be easier to say change it for software people, I feel that leaving it "as is" Is the proper thing to do. I want to learn the the electronics/hardware side of what I'm coding against the right way- it's as if I'm taking a trip from my home country of software-landia to hardware-ica and I should learn the customs to make the most of my journey.


I totally agree with RedHermit. By changing this, it's like we are lying to ourself of what's really going on behind the scene. So I suggest that we leave it as is.

#12 Chris Seto

Chris Seto

    Advanced Member

  • Members
  • PipPipPip
  • 405 posts

Posted 10 August 2010 - 08:48 PM

Why not just have a switch class that inverts it?

#13 MrSmoofy

MrSmoofy

    Advanced Member

  • Members
  • PipPipPip
  • 47 posts
  • LocationOdessa, FL

Posted 11 August 2010 - 02:43 PM

Being a software developer for 11+ years I can understand how it would be confusing to any software developer especially those that do know anything about the hardware side. I would say leave it as is since it provides the actually state of the hardware but add maybe a helper function for developers to call as well. Yes any developer could write a helper function but if it's already there those developers that don't understand would be less confused. Maybe derive a Button class from the InputPort where the Button class has a IsPressed method and even a Pressed Event on the Button class so novice software developer wouldn't have to understand how the hardware works. Just throwing ideas out there as I think it's pretty easy to understand the way it is but for a beginner they might not understand.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.