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.
How do you read digital inputs from microswitch, jumpers, dip-switches...?
Started by ●September 20, 2018
Reply by ●September 22, 20182018-09-22
Reply by ●September 22, 20182018-09-22
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 problemHow does that work? Just because you're reading the switches only occasionally, doesn't mean you're not going to read them in the middle of a bounce.
Reply by ●September 23, 20182018-09-23
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
Reply by ●September 23, 20182018-09-23
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.
Reply by ●September 24, 20182018-09-24
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
Reply by ●September 24, 20182018-09-24
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!!
Reply by ●September 24, 20182018-09-24
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
Reply by ●September 25, 20182018-09-25
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.
Reply by ●September 25, 20182018-09-25
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
Reply by ●September 28, 20182018-09-28
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... > > ChrisMy 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.
