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?
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.
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.
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.
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!)
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.
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.
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...
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.
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.
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.
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".
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
gmail.com STOOGES!!
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!!
gmail.com
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.
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...
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.
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.