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

Started by pozz September 20, 2018
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.&#2013266080; If you really do
> need to read these kinds of switches periodically, your user > requirements will tell you to debounce or not.&#2013266080; 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.&#2013266080; 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.&#2013266080; 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.&nbsp; If you really do > > need to read these kinds of switches periodically, your user > > requirements will tell you to debounce or not.&nbsp; 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.&nbsp; 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.&nbsp; 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