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.

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.

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

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

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. 

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.

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
> 

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

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>&nbsp; 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.&nbsp; 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.&nbsp; 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.

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