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 2 of 2 — ← Prev page 1 [2]

#28127

On 2018-09-21, Chris <xxx.syseng.yyy@gfsys.co.uk> wrote:
> 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.

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!!
                              gmail.com            

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

#28128

On 9/24/18 11:00 AM, Grant Edwards wrote:
> On 2018-09-21, Chris <xxx.syseng.yyy@gfsys.co.uk> wrote:
>> 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.
> 
> 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).
> 

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.

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

#28129

On 09/25/18 11:57, Richard Damon wrote:
> On 9/24/18 11:00 AM, Grant Edwards wrote:
>> On 2018-09-21, Chris<xxx.syseng.yyy@gfsys.co.uk>  wrote:
>>> 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.
>>
>> 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).
>>
>
> 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...

Chris

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

#28130

On 9/25/18 10:12 AM, Chris wrote:
> On 09/25/18 11:57, Richard Damon wrote:
>> On 9/24/18 11:00 AM, Grant Edwards wrote:
>>> On 2018-09-21, Chris<xxx.syseng.yyy@gfsys.co.uk>  wrote:
>>>> 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.
>>>
>>> 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).
>>>
>>
>> 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...
> 
> 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.

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

#28131

On 09/28/18 13:10, Richard Damon wrote:

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


Gaming might be a special case, but perhaps the way round
that is to adjust the clock tick period to get the required
response time ?. I doubt if 2 or 3 mS would be noticeable,
but there are various other issues, such as how long a key
must be down to be positively identified. A polling
approach may not be good enough, depending on polling
interval and or the system load elsewhere. For absolutely
instant response, the only way is to add hardware to post
an interrupt for any keypress, with the interrupt handler
deciding what to do with it. Whatever solution, the
keyprees has to get to the consumer process, either through
polling ar perhaps a signal and task switch, so overall
system architecture matters a lot and not later into the
design when problems surface :-).

The reason I use such techniques is that a lot of the work
done here is on none rtos platforms, often with inadequate
hardware and running things like keyscanners in the
background reduces complexity and allows more flexibility
in the design of mainline code. Same applies to serial
comms for example, where  an upper (mainline) and
lower (interrupt) layer, with queues on tx and rx to connect
the two, can offload a whole wedge of functionality...

Chris

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

#28133

On 9/28/18 10:43 AM, Chris wrote:
> On 09/28/18 13:10, Richard Damon wrote:
> 
>>
>> 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.
> 
> 
> Gaming might be a special case, but perhaps the way round
> that is to adjust the clock tick period to get the required
> response time ?. I doubt if 2 or 3 mS would be noticeable,
> but there are various other issues, such as how long a key
> must be down to be positively identified. A polling
> approach may not be good enough, depending on polling
> interval and or the system load elsewhere. For absolutely
> instant response, the only way is to add hardware to post
> an interrupt for any keypress, with the interrupt handler
> deciding what to do with it. Whatever solution, the
> keyprees has to get to the consumer process, either through
> polling ar perhaps a signal and task switch, so overall
> system architecture matters a lot and not later into the
> design when problems surface :-).
> 
> The reason I use such techniques is that a lot of the work
> done here is on none rtos platforms, often with inadequate
> hardware and running things like keyscanners in the
> background reduces complexity and allows more flexibility
> in the design of mainline code. Same applies to serial
> comms for example, where  an upper (mainline) and
> lower (interrupt) layer, with queues on tx and rx to connect
> the two, can offload a whole wedge of functionality...
> 
> Chris
> 

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

#28134

On 9/28/18 10:43 AM, Chris wrote:
> On 09/28/18 13:10, Richard Damon wrote:
> 
>>
>> 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.
> 
> 
> Gaming might be a special case, but perhaps the way round
> that is to adjust the clock tick period to get the required
> response time ?. I doubt if 2 or 3 mS would be noticeable,
> but there are various other issues, such as how long a key
> must be down to be positively identified. A polling
> approach may not be good enough, depending on polling
> interval and or the system load elsewhere. For absolutely
> instant response, the only way is to add hardware to post
> an interrupt for any keypress, with the interrupt handler
> deciding what to do with it. Whatever solution, the
> keyprees has to get to the consumer process, either through
> polling ar perhaps a signal and task switch, so overall
> system architecture matters a lot and not later into the
> design when problems surface :-).
> 
> The reason I use such techniques is that a lot of the work
> done here is on none rtos platforms, often with inadequate
> hardware and running things like keyscanners in the
> background reduces complexity and allows more flexibility
> in the design of mainline code. Same applies to serial
> comms for example, where  an upper (mainline) and
> lower (interrupt) layer, with queues on tx and rx to connect
> the two, can offload a whole wedge of functionality...
> 
> Chris
> 

Raising the frequency can invalidate the debouncing. The key to
debouncing is that after the switch makes contact, it might rebound off
and bounce for a period of time. You thus need to do something to avoid
seeing the multiple on-off-on transitions. The period of this bouncing
is strongly a function of the type and quality of the switch, some (like
mercury wetted contacts) having inherently no bounce, while some cheap
leaf spring contacts can bounce for 10s of milliseconds.

Gaming is a bit special because time gets naturally quantized into
frames, everything happens in multiples of the frame (so 'polling' the
switch by reading it once a frame is natural, if a frame is longer than
the bounce period, you can ignore bouncing, if it is shorter you need to
do something to debounce (preferably without adding a frame delay). At
60 Hz, you are naturally sampling about every 16 ms, which is longer
than most bounce times, but controllers tend to get mashed a lot, so
sometimes you want to be a bit careful.

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

#28144

On Friday, September 28, 2018 at 10:43:13 AM UTC-4, Chris wrote:
> On 09/28/18 13:10, Richard Damon wrote:
> 
> >
> > 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.
> 
> 
> Gaming might be a special case, but perhaps the way round
> that is to adjust the clock tick period to get the required
> response time ?. I doubt if 2 or 3 mS would be noticeable,
> but there are various other issues, such as how long a key
> must be down to be positively identified. A polling
> approach may not be good enough, depending on polling
> interval and or the system load elsewhere. For absolutely
> instant response, the only way is to add hardware to post
> an interrupt for any keypress, with the interrupt handler
> deciding what to do with it. Whatever solution, the
> keyprees has to get to the consumer process, either through
> polling ar perhaps a signal and task switch, so overall
> system architecture matters a lot and not later into the
> design when problems surface :-).
> 
> The reason I use such techniques is that a lot of the work
> done here is on none rtos platforms, often with inadequate
> hardware and running things like keyscanners in the
> background reduces complexity and allows more flexibility
> in the design of mainline code. Same applies to serial
> comms for example, where  an upper (mainline) and
> lower (interrupt) layer, with queues on tx and rx to connect
> the two, can offload a whole wedge of functionality...
> 
> Chris

Excellent comments.
ed

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web