How do you read digital inputs from microswitch, jumpers, dip-switches...?

Often I have digital inputs connected to switches managed by the user. 
For example: microswitches, tactile switches, push-buttons, 
dip-switches, simple jumpers and so on.

What is your preferred method to read the status of this inputs?

I usually arrange a debounce method for reading push-buttons and 
similars (tactile switches, micro-switches...) and I know there are many 
(many many) methods[*].

What about simple jumpers or dip-switches? Do you implement a debounce 
on those too? Or do you simply read the digital input and change the 
logic status of the switch without any debounce/filter strategy?

It's very simple to write:

bool dip1, dip2;
void poll_dip_switches_every_100ms(void) {
   dip1 = pin_get_input_level(PIN_DIP1) == 0;
   dip2 = pin_get_input_level(PIN_DIP2) == 0;
   ...
}

bool jumper;
void poll_jumper_every_100ms(void) {
   jumper = pin_get_input_level(PIN_DIP2) == 0;
}

On 9/20/2018 2:52 AM, pozz wrote:
> Often I have digital inputs connected to switches managed by the user. 
> For example: microswitches, tactile switches, push-buttons, 
> dip-switches, simple jumpers and so on.
> 
> What is your preferred method to read the status of this inputs?

Typically dip-switches and jumpers are used for easy user system 
configuration so FW will read them at init time and never again.  Of 
course, requirements dictate it so it's not a rule.  If you really do 
need to read these kinds of switches periodically, your user 
requirements will tell you to debounce or not.  It comes down to the 
answer to this question: Will the consequences of ever misreading the 
switches have a negative effect on the function?

Push buttons and tactile switches are typically used in occasional user 
interactions.  They are typically debounced but, as always, you need to 
ask the same question as above about whether to debounce or not.

Advice from the trenches: A brand new switch will often not display 
characteristics requiring debouncing but it very well might as it ages 
and collects dirt, etc.  Plan for that possibility when you are deciding 
to debounce or not.

JJS

On Thu, 20 Sep 2018 11:52:47 +0200, pozz <pozzugno@gmail.com> wrote:

>Often I have digital inputs connected to switches managed by the user. 
>For example: microswitches, tactile switches, push-buttons, 
>dip-switches, simple jumpers and so on.
>
>What is your preferred method to read the status of this inputs?
>
>I usually arrange a debounce method for reading push-buttons and 
>similars (tactile switches, micro-switches...) and I know there are many 
>(many many) methods[*].
>
>What about simple jumpers or dip-switches? Do you implement a debounce 
>on those too? Or do you simply read the digital input and change the 
>logic status of the switch without any debounce/filter strategy?
>
>It's very simple to write:
>
>bool dip1, dip2;
>void poll_dip_switches_every_100ms(void) {
>   dip1 = pin_get_input_level(PIN_DIP1) == 0;
>   dip2 = pin_get_input_level(PIN_DIP2) == 0;
>   ...
>}
>
>bool jumper;
>void poll_jumper_every_100ms(void) {
>   jumper = pin_get_input_level(PIN_DIP2) == 0;
>}


There's nothing really special about DIP switches as switches, other
than their form factor.

If you allow the user the change DIP switches during operation, you'll
need to debounce them (or be able to live with the consequences).  I
most applications, DIP switches are read only at startup, and no
debounce is necessary there.

Il 20/09/2018 14:35, John Speth ha scritto:
> On 9/20/2018 2:52 AM, pozz wrote:
>> Often I have digital inputs connected to switches managed by the user. 
>> For example: microswitches, tactile switches, push-buttons, 
>> dip-switches, simple jumpers and so on.
>>
>> What is your preferred method to read the status of this inputs?
> 
> Typically dip-switches and jumpers are used for easy user system 
> configuration so FW will read them at init time and never again.  

Sincerely I don't like this approach.  When I, as a user, read the 
manual that says "dip-switch 1 enables option 1", I think I can change 
its position at any time.  Maybe somewhere the manual says "Dip-switches 
are read only at startup, so power cycle or press RESET button when you 
change them"... but it's not friendly.

When possible I read dip-switches during normal working.


> Of 
> course, requirements dictate it so it's not a rule.� If you really do 
> need to read these kinds of switches periodically, your user 
> requirements will tell you to debounce or not.� It comes down to the 
> answer to this question: Will the consequences of ever misreading the 
> switches have a negative effect on the function?

Generally yes.


> Push buttons and tactile switches are typically used in occasional user 
> interactions.� They are typically debounced but, as always, you need to 
> ask the same question as above about whether to debounce or not.
> 
> Advice from the trenches: A brand new switch will often not display 
> characteristics requiring debouncing but it very well might as it ages 
> and collects dirt, etc.� Plan for that possibility when you are deciding 
> to debounce or not.

On 21/09/18 09:42, pozz wrote:
> Il 20/09/2018 14:35, John Speth ha scritto:
>> On 9/20/2018 2:52 AM, pozz wrote:
>>> Often I have digital inputs connected to switches managed by the
>>> user. For example: microswitches, tactile switches, push-buttons,
>>> dip-switches, simple jumpers and so on.
>>>
>>> What is your preferred method to read the status of this inputs?
>>
>> Typically dip-switches and jumpers are used for easy user system
>> configuration so FW will read them at init time and never again.  
> 
> Sincerely I don't like this approach.  When I, as a user, read the
> manual that says "dip-switch 1 enables option 1", I think I can change
> its position at any time.  Maybe somewhere the manual says "Dip-switches
> are read only at startup, so power cycle or press RESET button when you
> change them"... but it's not friendly.
> 
> When possible I read dip-switches during normal working.

That will depend entirely on what the DIP switches are for.  In some
cases it makes sense to be able to change them at run-time.  In other
cases, it does not.

A compromise that I have used on a number of systems is to read the DIP
switches at reset.  Then I also read them regularly while running - and
if they have changed, I reset the card.  That gives the best of both worlds.

> 
> 
>> Of course, requirements dictate it so it's not a rule.  If you really
>> do need to read these kinds of switches periodically, your user
>> requirements will tell you to debounce or not.  It comes down to the
>> answer to this question: Will the consequences of ever misreading the
>> switches have a negative effect on the function?
> 
> Generally yes.
> 

DIP switches read at reset don't need debouncing to be stable.  You only
get bouncing when you read the switches at approximately the same time
as a user is changing them.  So DIP's read at reset are always stable.
(If they are not, it's time to fix your power supply!)

> 
>> Push buttons and tactile switches are typically used in occasional
>> user interactions.  They are typically debounced but, as always, you
>> need to ask the same question as above about whether to debounce or not.
>>
>> Advice from the trenches: A brand new switch will often not display
>> characteristics requiring debouncing but it very well might as it ages
>> and collects dirt, etc.  Plan for that possibility when you are
>> deciding to debounce or not.
> 

On 2018-09-21, pozz <pozzugno@gmail.com> wrote:
> Il 20/09/2018 14:35, John Speth ha scritto:
>> 
>> Typically dip-switches and jumpers are used for easy user system 
>> configuration so FW will read them at init time and never again.  
>
> Sincerely I don't like this approach.  When I, as a user, read the 
> manual that says "dip-switch 1 enables option 1", I think I can change 
> its position at any time.  Maybe somewhere the manual says "Dip-switches 
> are read only at startup, so power cycle or press RESET button when you 
> change them"... but it's not friendly.
>
> When possible I read dip-switches during normal working.

Personally it tends to depend on how the switch output is being
used (which is different to what it actually does).  If the switch
is simply controlling a decision I'm probably more likely to read
the switch at the decision point than anything else, assuming a
small system with direct access to the value - the more expensive
I/O becomes or the more indirect the path between switch and MCU
(multiplexers, I/O expanders etc) the more likely I am to read once
and forget the switch.

OTOH sometimes a switch will affect e.g. how a data structure is
initialised and handling a changed value means redoing a lot of
work.  I probably wouldn't handle that in a dynamic fashion unless
there is a clear and concrete reason to do that.  I am not going
to adjust firmware wholesale to cater for a mere whim.

Regardless of when the values are read, I honestly am struggling
to envisage when the question of bounce would become relevant.
I'm not saying there not out there but that I simply can't see
them.  A slide or (latching) rocker switch of any form is for
persistent state rather than a one-off event.  The usage typically
falls into one of two patterns - either it is read occasionally
for the current value, and if the wrong value is read because it
was changes so close to the decision point I would say that is a
user issue.  The other case is retrieving the value in some fast
loop and things will settle down in short order without consequence,
i.e. we've got the wrong value for this iteration, but don't worry,
it'll sort itself out on the next pass in 1.3ms...  If the switch
is human-operated the question of a super-fast response time becomes
irrelevant.

One other point, the whole question suggests these switches are
being operated with some frequency.  If that's the case rethink
your choice of switch - DIP switches are typically only rated for
a few hundred cycles.  I'm sure I'm not alone here in having a few
prototyping modules that I'll mount up and wire together to create
a quick prototype for an initial proof of concept or for software
development.  Many of mine have DIP switches for configuration for
the particular use case, e.g. enabling or disabling onboard
pull-ups.  They don't get a _lot_ of operation but I have found
some of my most used modules need occasional switch replacement.

-- 
Andrew Smallshaw
andrews@sdf.org

On Friday, September 21, 2018 at 3:42:16 AM UTC-4, pozz wrote:
> Il 20/09/2018 14:35, John Speth ha scritto:
> > On 9/20/2018 2:52 AM, pozz wrote:
> >> Often I have digital inputs connected to switches managed by the user. 
> >> For example: microswitches, tactile switches, push-buttons, 
> >> dip-switches, simple jumpers and so on.
> >>
> >> What is your preferred method to read the status of this inputs?
> > 
> > Typically dip-switches and jumpers are used for easy user system 
> > configuration so FW will read them at init time and never again.  
> 
> Sincerely I don't like this approach.  When I, as a user, read the 
> manual that says "dip-switch 1 enables option 1", I think I can change 
> its position at any time.  Maybe somewhere the manual says "Dip-switches 
> are read only at startup, so power cycle or press RESET button when you 
> change them"... but it's not friendly.
> 
> When possible I read dip-switches during normal working.

Still, they don't need to be debounced.  If they are read while transitioning, they will be in the old state or the new state, either result is valid during the transition.  


> > Of 
> > course, requirements dictate it so it's not a rule.  If you really do 
> > need to read these kinds of switches periodically, your user 
> > requirements will tell you to debounce or not.  It comes down to the 
> > answer to this question: Will the consequences of ever misreading the 
> > switches have a negative effect on the function?
> 
> Generally yes.

If it is a mode setting then it won't need to be debounced.  However, like in logic where an input is used in multiple circuits, if this switch is used to control multiple modules it may be necessary to save the state for use rather than have each module read the switch directly preventing the modules from seeing different states. 


> > Push buttons and tactile switches are typically used in occasional user 
> > interactions.  They are typically debounced but, as always, you need to 
> > ask the same question as above about whether to debounce or not.
> > 
> > Advice from the trenches: A brand new switch will often not display 
> > characteristics requiring debouncing but it very well might as it ages 
> > and collects dirt, etc.  Plan for that possibility when you are deciding 
> > to debounce or not.

It is only when a switch is conveying time as well as state that it needs to be debounced.  In logic terms, it is only the clock that needs to be debounced, not data. 

Rick C.

On 09/20/18 10:52, pozz wrote:
> Often I have digital inputs connected to switches managed by the user.
> For example: microswitches, tactile switches, push-buttons,
> dip-switches, simple jumpers and so on.
>
> What is your preferred method to read the status of this inputs?
>


Assuming not in an rtos environment, where you have timers,
a system clock tick and background timer capability, perhaps
with callback, can make debounce easy.  A simple state
machine using a switch statement, allows testing the input,
delaying for a specified time, then reading again before
acceptance of the change.

Build that into set of library functions makes it reusable
as well...

Chris

On Fri, 21 Sep 2018 06:22:23 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:

>On Friday, September 21, 2018 at 3:42:16 AM UTC-4, pozz wrote:
>> Il 20/09/2018 14:35, John Speth ha scritto:
>> > On 9/20/2018 2:52 AM, pozz wrote:
>> >> Often I have digital inputs connected to switches managed by the user. 
>> >> For example: microswitches, tactile switches, push-buttons, 
>> >> dip-switches, simple jumpers and so on.
>> >>
>> >> What is your preferred method to read the status of this inputs?
>> > 
>> > Typically dip-switches and jumpers are used for easy user system 
>> > configuration so FW will read them at init time and never again.  
>> 
>> Sincerely I don't like this approach.  When I, as a user, read the 
>> manual that says "dip-switch 1 enables option 1", I think I can change 
>> its position at any time.  Maybe somewhere the manual says "Dip-switches 
>> are read only at startup, so power cycle or press RESET button when you 
>> change them"... but it's not friendly.
>> 
>> When possible I read dip-switches during normal working.
>
>Still, they don't need to be debounced.  If they are read while transitioning, they will be in the old state or the new state, either result is valid during the transition.  


Only if there's no real cost to switching whatever mode the switch
controls.  That's certainly possible, but has not been specified.  If
you get bounce, your device may end up switching between modes
numerous times for a single change in the switch position (from the
user's perspective).  If that's expensive in some way, it may be a
problem.

fredag den 21. september 2018 kl. 17.04.16 UTC+2 skrev robert...@yahoo.com:
> On Fri, 21 Sep 2018 06:22:23 -0700 (PDT),
> gnuarm.deletethisbit@gmail.com wrote:
> 
> >On Friday, September 21, 2018 at 3:42:16 AM UTC-4, pozz wrote:
> >> Il 20/09/2018 14:35, John Speth ha scritto:
> >> > On 9/20/2018 2:52 AM, pozz wrote:
> >> >> Often I have digital inputs connected to switches managed by the user. 
> >> >> For example: microswitches, tactile switches, push-buttons, 
> >> >> dip-switches, simple jumpers and so on.
> >> >>
> >> >> What is your preferred method to read the status of this inputs?
> >> > 
> >> > Typically dip-switches and jumpers are used for easy user system 
> >> > configuration so FW will read them at init time and never again.  
> >> 
> >> Sincerely I don't like this approach.  When I, as a user, read the 
> >> manual that says "dip-switch 1 enables option 1", I think I can change 
> >> its position at any time.  Maybe somewhere the manual says "Dip-switches 
> >> are read only at startup, so power cycle or press RESET button when you 
> >> change them"... but it's not friendly.
> >> 
> >> When possible I read dip-switches during normal working.
> >
> >Still, they don't need to be debounced.  If they are read while transitioning, they will be in the old state or the new state, either result is valid during the transition.  
> 
> 
> Only if there's no real cost to switching whatever mode the switch
> controls.  That's certainly possible, but has not been specified.  If
> you get bounce, your device may end up switching between modes
> numerous times for a single change in the switch position (from the
> user's perspective).  If that's expensive in some way, it may be a
> problem.

so read the switches at a lower rate than the bounce settling time, for dipswitch or jumper settings the delay shouldn't be a problem