Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

Thread: push-to-break vs. push-to-make?

  1. #1
    Member
    Join Date
    Feb 2014
    Location
    Southern Oregon
    Posts
    79

    push-to-break vs. push-to-make?

    A few years ago, thinking I was being clever at the time, I bought a bunch of push-to-break push button switches, thinking then the logic in conjunction with using internal pull-up resistors would be more consistent. Now, logic aside I wonder if there are other issues I don't understand.

    Are there pitfalls or trade-offs associated with push-to-break vs. push-to-make switches with regards to:

    1) Loads on the internal pull-up resistors?
    2) Idle current scenarios (e.g. one is always closed, the other always open)?
    3) Un-initialized or pre-initialization pin concerns (switch connected to pin & ground)?

    Thanks,

    --Jon

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,323
    A "normally closed" button with a pullup resistor will cause a tiny amount of power to be always consumed when the button isn't pressed.

    For a battery powered project where you put Teensy into a deep sleep mode during long periods of inactivity, that extra current could gradually add up to real battery life problem.

    For powered applications, usually tiny pullup resistor currents are not worth much concern.

    Functionally, either way is fine, both running and during reset & uploading. No significant concerns in almost all projects. Of course, for a *highly* unusual project, almost anything might matter. As a sort of standard disclaimer, this general advise applies generally to projects. You can only get specific advice if you ask a specific question with specific technical details.

  3. #3
    Member
    Join Date
    Feb 2014
    Location
    Southern Oregon
    Posts
    79
    Thanks Paul.

    I should always be more explicit... definitely not a battery powered project. I was mostly trying to learn about any possible pitfalls with respect to pins and currents and un-initialized pull-ups in the two NC & NO scenarios.

    ...and I always appreciate the "standard disclaimer."

  4. #4
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,915
    Yes there are situations in electronics where a NC switch might be a problem, but the teensy CPU has sanly designed outputs that with one exception start completely isolated and have to be specifically assigned as inputs and outputs so nothing bad will happen unless your code makes it happen (ie setting that grounded pin to output, driving it high and killing the pin and/or CPU).

    The exception is pin 33, which on Teensy 3.0/3.1 and I think 3.2 is tied to a programming function and if low at power up sticks the CPU into a wait state. An unfortunate side effect of the ability to fit lots of functions into small pincount devices is that you often get 'special' behavior on theoretically identical pins that leave you digging into big reference manuals to find out what peripheral has activated the pin you were using.

  5. #5
    Member
    Join Date
    Feb 2014
    Location
    Southern Oregon
    Posts
    79
    Quote Originally Posted by GremlinWrangler View Post
    ...is that you often get 'special' behavior on theoretically identical pins that leave you digging into big reference manuals...
    Almost sounds like the reason you chose your user name? That kind of an issue would be a challenge to uncover for anyone, especially for a relative novice.

    But your fist scenario is more the type of pitfall I was asking about. I was blissfully unaware that inadvertently writing a pin high when it is grounded would kill the pin and/or CPU. I can easily see the same happening whether NC or NO, with bad (inattentive) coding. That's not something anyone would do intentionally, but it sounds like one of those things to look for first in a debugging scenario with a dead pin or CPU. Obviously not specific to this NC/NO switch topic. Thanks.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,323
    Teensy 3.2 fixes the pin 33 problems. Or at least it's supposed to and seemed to be effective in all the cases I tested.

  7. #7
    Member
    Join Date
    Feb 2014
    Location
    Southern Oregon
    Posts
    79
    Quote Originally Posted by PaulStoffregen View Post
    Teensy 3.2 fixes the pin 33 problems. Or at least it's supposed to and seemed to be effective in all the cases I tested.
    That's good to know too, since I have a handful of new 3.2's on the bench now, and more on the way from OSH Park too!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •