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

Status
Not open for further replies.
E

epicycloid

Well-known member
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
 
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.
 
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."
 
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.
 
GremlinWrangler said:
...is that you often get 'special' behavior on theoretically identical pins that leave you digging into big reference manuals...
Click to expand...

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.
 
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.
 
Status
Not open for further replies.
Back
Top