Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #28051 > unrolled thread

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

Back to article view | Back to comp.arch.embedded

Contents

  How do you read digital inputs from microswitch, jumpers, dip-switches...? pozz <pozzugno@gmail.com> - 2018-09-20 11:52 +0200
    Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? John Speth <johnspeth@yahoo.com> - 2018-09-20 05:35 -0700
      Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? pozz <pozzugno@gmail.com> - 2018-09-21 09:42 +0200
        Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? David Brown <david.brown@hesbynett.no> - 2018-09-21 11:09 +0200
          Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Grant Edwards <invalid@invalid.invalid> - 2018-09-24 14:53 +0000
            Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? gnuarm.deletethisbit@gmail.com - 2018-09-29 12:34 -0700
        Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Andrew Smallshaw <andrews@sdf.org> - 2018-09-21 09:16 +0000
        Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? gnuarm.deletethisbit@gmail.com - 2018-09-21 06:22 -0700
          Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Robert Wessel <robertwessel2@yahoo.com> - 2018-09-21 10:04 -0500
            Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? lasselangwadtchristensen@gmail.com - 2018-09-21 14:47 -0700
              Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Robert Wessel <robertwessel2@yahoo.com> - 2018-09-22 21:57 -0500
                Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Andrew Smallshaw <andrews@sdf.org> - 2018-09-23 04:55 +0000
                Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? gnuarm.deletethisbit@gmail.com - 2018-09-22 22:55 -0700
            Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? gnuarm.deletethisbit@gmail.com - 2018-09-22 09:27 -0700
            Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Grant Edwards <invalid@invalid.invalid> - 2018-09-24 14:57 +0000
              Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Ed Prochak <edprochak@gmail.com> - 2018-10-05 09:52 -0700
                Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Richard Damon <Richard@Damon-Family.org> - 2018-10-05 14:40 -0400
                Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? gnuarm.deletethisbit@gmail.com - 2018-10-05 12:48 -0700
    Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Robert Wessel <robertwessel2@yahoo.com> - 2018-09-20 23:38 -0500
    Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-21 14:43 +0100
      Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Grant Edwards <invalid@invalid.invalid> - 2018-09-24 15:00 +0000
        Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Richard Damon <Richard@Damon-Family.org> - 2018-09-25 06:57 -0400
          Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-25 15:12 +0100
            Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Richard Damon <Richard@Damon-Family.org> - 2018-09-28 08:10 -0400
              Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2018-09-28 15:43 +0100
                Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Richard Damon <Richard@Damon-Family.org> - 2018-09-28 21:23 -0400
                Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Richard Damon <Richard@Damon-Family.org> - 2018-09-28 21:42 -0400
                Re: How do you read digital inputs from microswitch, jumpers, dip-switches...? Ed Prochak <edprochak@gmail.com> - 2018-10-05 10:04 -0700

Page 1 of 2  [1] 2  Next page →

#28051 — 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;
}

[toc] | [next] | [standalone]

#28052

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

[toc] | [prev] | [next] | [standalone]

#28058

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.

[toc] | [prev] | [next] | [standalone]

#28059

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.
> 

[toc] | [prev] | [next] | [standalone]

#28125

On 2018-09-21, David Brown <david.brown@hesbynett.no> wrote:

> 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.

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

> So DIP's read at reset are always stable.

Not if somebody is flipping one of the switches.

-- 
Grant Edwards               grant.b.edwards        Yow! Is this going to
                                  at               involve RAW human ecstasy?
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#28135

On Monday, September 24, 2018 at 10:53:51 AM UTC-4, Grant Edwards wrote:
> On 2018-09-21, David Brown <david.brown@hesbynett.no> wrote:
> 
> > 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.
> 
> Why do you rule out a user changing the switch at the same time a
> reset is occuring?
> 
> > So DIP's read at reset are always stable.
> 
> Not if somebody is flipping one of the switches.

Doesn't matter.  You don't need to resolve it with a FF.  You get the old data or the new data depending on the state of the bounce.  How would it matter which one? 

Rick C. 

[toc] | [prev] | [next] | [standalone]

#28060

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

[toc] | [prev] | [next] | [standalone]

#28062

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.

[toc] | [prev] | [next] | [standalone]

#28068

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.

[toc] | [prev] | [next] | [standalone]

#28072

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

[toc] | [prev] | [next] | [standalone]

#28108

On Fri, 21 Sep 2018 14:47:24 -0700 (PDT),
lasselangwadtchristensen@gmail.com wrote:

>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


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.

[toc] | [prev] | [next] | [standalone]

#28109

On 2018-09-23, Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Fri, 21 Sep 2018 14:47:24 -0700 (PDT),
>>
>>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
>
>
> 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.

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

[toc] | [prev] | [next] | [standalone]

#28110

On Saturday, September 22, 2018 at 10:56:29 PM UTC-4, robert...@yahoo.com wrote:
> On Fri, 21 Sep 2018 14:47:24 -0700 (PDT),
> lasselangwadtchristensen@gmail.com wrote:
> 
> >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
> 
> 
> 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.

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 matter.  The only reason to use a debounce circuit is so you don't see multiple 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 matter which state you "see". 

Rick C.

[toc] | [prev] | [next] | [standalone]

#28094

On Friday, September 21, 2018 at 11:04:16 AM UTC-4, robert...@yahoo.com wrote:
> 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.

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. 

[toc] | [prev] | [next] | [standalone]

#28126

On 2018-09-21, Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Fri, 21 Sep 2018 06:22:23 -0700 (PDT), gnuarm.deletethisbit@gmail.com wrote:

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

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

[toc] | [prev] | [next] | [standalone]

#28143

On Monday, September 24, 2018 at 10:57:32 AM UTC-4, Grant Edwards wrote:
> On 2018-09-21, Robert Wessel <robertwessel2@yahoo.com> wrote:
> > On Fri, 21 Sep 2018 06:22:23 -0700 (PDT), gnuarm.deletethisbit@gmail.com wrote:
> 
> >>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).
> 
> 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".

But you are introducing a latency in the mode change.
Time 0 seconds Machine state A and switch state A
Time 1 seconds Machine state A and Reading switch during transition to B
               but bounce causes value to read A, so no state change.
Time 2 seconds Machine state A and Reading switch during transition to A
               but bounce causes value to read A, so no state change.
If this machine is being used to count something via transitions on
that switch, you just lost a count.

>  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.

IOW sampling frequency is not the only factor to consider in debouncing
a switch input.

HTH,
  Ed

[toc] | [prev] | [next] | [standalone]

#28146

On 10/5/18 12:52 PM, Ed Prochak wrote:
> On Monday, September 24, 2018 at 10:57:32 AM UTC-4, Grant Edwards wrote:
>>
>> 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".
> 
> But you are introducing a latency in the mode change.
> Time 0 seconds Machine state A and switch state A
> Time 1 seconds Machine state A and Reading switch during transition to B
>                but bounce causes value to read A, so no state change.
> Time 2 seconds Machine state A and Reading switch during transition to A
>                but bounce causes value to read A, so no state change.
> If this machine is being used to count something via transitions on
> that switch, you just lost a count.
> 
>>  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.
> 
> IOW sampling frequency is not the only factor to consider in debouncing
> a switch input.
> 
> HTH,
>   Ed
> 

Which says if you need to count 1 second pulses you need to be sampling
at a rate of at least slightly faster than once a second. Basicslly your
sample time must be less than the 'solid' press time, which is roughly
the physical press time minus the bounce time.

If you are debouncing solely by sampling, the max rate you can sample at
is the bounce time, so it can only be used to detect button presses that
exceed twice the bounce period (which normally isn't an issue), but if
you do, you need to use something a bit more complicated.

[toc] | [prev] | [next] | [standalone]

#28147

On Friday, October 5, 2018 at 12:52:32 PM UTC-4, Ed Prochak wrote:
> On Monday, September 24, 2018 at 10:57:32 AM UTC-4, Grant Edwards wrote:
> > On 2018-09-21, Robert Wessel <robertwessel2@yahoo.com> wrote:
> > > On Fri, 21 Sep 2018 06:22:23 -0700 (PDT), gnuarm.deletethisbit@gmail.com wrote:
> > 
> > >>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).
> > 
> > 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".
> 
> But you are introducing a latency in the mode change.
> Time 0 seconds Machine state A and switch state A
> Time 1 seconds Machine state A and Reading switch during transition to B
>                but bounce causes value to read A, so no state change.
> Time 2 seconds Machine state A and Reading switch during transition to A
>                but bounce causes value to read A, so no state change.
> If this machine is being used to count something via transitions on
> that switch, you just lost a count.

And that is the key.  If the state is important and not at a high speed, then simple reads are sufficient.  If you want to detect the transitions of a switch and not the bounces, then you have to add debounce hardware or software.  If you want to read and respond to a switch in a short amount of time, you need to debounce the switch signal. 

Don't make this more complicated than it is. 


> >  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.
> 
> IOW sampling frequency is not the only factor to consider in debouncing
> a switch input.

I don't think that was what anyone did.  Samping rate is the only important issue for a state detection which I believe had been indicated at some point. 

Rick C.

[toc] | [prev] | [next] | [standalone]

#28057

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.

[toc] | [prev] | [next] | [standalone]

#28063

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web