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; }

Reply to
pozz
Loading thread data ...

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

Reply to
John Speth

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.

Reply to
Robert Wessel

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.

Generally yes.

Reply to
pozz

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.

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!)

Reply to
David Brown

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
Reply to
Andrew Smallshaw

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

do

he

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 use d 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 modul es from seeing different states.

ed to

ciding

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

Rick C.

Reply to
gnuarm.deletethisbit

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

Reply to
Chris

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.

Reply to
Robert Wessel

fredag den 21. september 2018 kl. 17.04.16 UTC+2 skrev snipped-for-privacy@yahoo.com:

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

Reply to
lasselangwadtchristensen

If that is your concern the "debounce" is simply a matter of reading the switch less frequently than the bounce duration of the switch. I guess if a switch input is being read in a fast loop for whatever reason, some basic debouncing is required.

Rick C.

Reply to
gnuarm.deletethisbit

How does that work? Just because you're reading the switches only occasionally, doesn't mean you're not going to read them in the middle of a bounce.

Reply to
Robert Wessel

Sure, you might miss the transition if it is still bouncing when you poll the switch but in that case you notice the change on the next poll. Polling the switch at a few tens of Hz is more than enough to appear to be instantaneous, but also long enough for any bouncing to have settled between one pass and the next.

--
Andrew Smallshaw 
andrews@sdf.org
Reply to
Andrew Smallshaw

On Saturday, September 22, 2018 at 10:56:29 PM UTC-4, snipped-for-privacy@yahoo.com w rote:

om:

user.

nge

tches

you

itioning, they will be in the old state or the new state, either result is valid during the transition.

dipswitch or jumper settings the delay shouldn't be a problem

The fact that the switch is bouncing is not significant. The input will be a one or a zero. If the switch is bouncing, which should it be? You can' t say for sure so it doesn't matter. Some debounce circuits will return a one and others a zero for the same conditions. So obviously it doesn't mat ter. The only reason to use a debounce circuit is so you don't see multipl e transitions. If you aren't sampling the circuit fast enough to "see" the switch twice while it is bouncing from one transition, then it won't matte r which state you "see".

Rick C.

Reply to
gnuarm.deletethisbit

Why do you rule out a user changing the switch at the same time a reset is occuring?

Not if somebody is flipping one of the switches.

--
Grant Edwards               grant.b.edwards        Yow! Is this going to 
                                  at               involve RAW human ecstasy? 
 Click to see the full signature
Reply to
Grant Edwards

That depends on how _often_ you read them during operation. If the read happens once a second, then you're not going to see bounces and not going to be "switching between modes numerous times". If you read a switch once every millisecond, you have to worry about that. At some point between a cycle time of 1ms and 1s, you can stop worrying about debouncing.

--
Grant Edwards               grant.b.edwards        Yow! I don't understand 
                                  at               the HUMOUR of the THREE 
 Click to see the full signature
Reply to
Grant Edwards

Why delay before accepting the change?

That sounds like you're trying to ignore noise pulses that appear spontaneously. That's a completely different problem from debouncing.

In my experience, the usual method of debouncing, is to accept the change immediately then ignore the switch for a period of time (a few tens of milliseconds is usually sufficient).

--
Grant Edwards               grant.b.edwards        Yow! YOU PICKED KARL 
                                  at               MALDEN'S NOSE!! 
 Click to see the full signature
Reply to
Grant Edwards

For a human, 10s of milliseconds is normally 'instantaneous', so good enough. (In some gaming environment response gets more critical when the user has developed good twitch reflexes). While buttons rarely make a spontaneous make, in some environments they may open momentarily without intentional operation, so ignoring very short signals may be useful.

Reply to
Richard Damon

Ok, rushed and incomplete description. What I mean is that state starts off = idle. On clock tick, input is read and compared against the most recent value. If there is no change, do nothing. If there is a change, state = pending. On next tick, read again and if the same, return new value, otherwise state = idle.

Very simplistic, yes, but using a clock tick to drive such code means a keyscanner or hardware input module can run in the background at interrupt level. Data from that can either use a common variable, or queue...

Chris

Reply to
Chris

My comment dealt with the fact that for many purposes, that 1-2 clock tick delay is acceptable because it is 'fast' enough. In some environments, like gaming, the delay may be unacceptable due to people working on 'twitch' reflexes. For that sort of environment you need a slightly more complicated coding which responds immediately to a switch change, but then doesn't respond if the next sample falls back to the old state, but delays that reaction for another sample (or two if cheap bouncy switches). This gives immediate response without a risk of bouncing. For this case sampling tends to be synchronous with the display processing, which in some cases may be fast enough to otherwise detect a bouncing switch. Avoiding a frame delay to denounce may be very important as often you already have a frame delay from building frame n+1 while frame n is being displayed to the user, so even instantaneous reaction without a denounce delay can't affect the screen until frame n+2. If it didn't happen until n+3, some gamers will notice (they are actually probably somewhat anticipating), but 'frame perfect' is a thing for some of them.

Reply to
Richard Damon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.