MO pushbutton to change status?

Conrad_Turbo · Post by **Conrad_Turbo** » 30 August 2012, 12:13 PM

I don't use my Zbasic chip enough so I don't write enough code to be proficient at it...but I have a ZE-24PE and have a momentary push button switch connected to Pin 5. I want have some code that will monitor this pin for when the pushbutton is pressed and change the status of a variable. I have some code I have written but will need to tweak further:

'--------------------------------------------------------------------------------------
Option Explicit

'Public Variables
Dim ButtonStateFog as Byte = 0

'Input(s)
Const InputFog As Byte = 5

'Output(s)
Const OutputLeftFog As Byte = 13
Const OutputRightFog As Byte = 15

'--------------------------------------------------------------------------------------
Sub Main()

Call Sleep(0.05)

'Configure Input pins.
Call PutPin(InputFog, zxInputTristate)

'Configure Output pins.
Call PutPin(OutputLeftFog, zxOutputHigh)
Call PutPin(OutputRightFog, zxOutputHigh)

Do

'Scan Fog light pushbutton for change in status
If (GetPin(InputFog) = 0) then
ButtonStateFog = ButtonStateFog Xor 1
Call PutPin(OutputLeftFog, ButtonStateFog)
Call PutPin(OutputRightFog, ButtonStateFog)
End If
Call PutPin(OutputLeftFog, ButtonStateFog)
Call PutPin(OutputRightFog, ButtonStateFog)
Debug.Print CStr(ButtonStateFog)

Call Delay(0.15) ' pause for button(s) to debounce

Loop

End Sub
'--------------------------------------------------------------------------------------

Now the problem with this code is that when I hold the push button it cycles the ButtonStateFog and the output cycles on and off as well. Not really desirable. Also if I increase the delay then it misses button presses as well.

What I would like to do is take this code, have it recognise a button press based on time, so for example if it was less than 0.5 sec, then the ButtonStateFog is changed to 1, if it is greater than 0.5 sec then ButtonStateFog is 2, if the button is pressed for 0.5 sec again then it will shut off (ButtonStateFog is 0). All the while avoiding the cycling problem with the above code written.

Any ideas on what can be done? I have multiple (3) switches that will have this configuration applied to monitor a momentary on pushbutton and have it's own corresponding output.

Post by **dkinzer** » 30 August 2012, 13:00 PM

Conrad_Turbo wrote:I have a ZE-24PE and have a momentary push button switch connected to Pin 5.

Switches are challenging because of a phenomenon known as "contact bounce". When making or breaking contact, there are almost always several open-close cycles that can lead to false determination of switch status. Search for "switch debounce" on the Internet and you should find several discussions on the topic. The one by Jack Gannsel is often considered the best treatment of the subject.

Of course, you can make your life simpler by using a single-pole-double-throw pushbutton and debounce the switch using an S-R latch. An example of that is given in AN213 - External Device Interfacing.

Conrad_Turbo · Post by **Conrad_Turbo** » 30 August 2012, 13:17 PM

dkinzer wrote:
Conrad_Turbo wrote:I have a ZE-24PE and have a momentary push button switch connected to Pin 5.
Switches are challenging because of a phenomenon known as "contact bounce". When making or breaking contact, there are almost always several open-close cycles that can lead to false determination of switch status. Search for "switch debounce" on the Internet and you should find several discussions on the topic. The one by Jack Gannsel is often considered the best treatment of the subject.

Of course, you can make your life simpler by using a single-pole-double-throw pushbutton and debounce the switch using an S-R latch. An example of that is given in AN213 - External Device Interfacing.

I can't use a SPDT if I want time to be involved to change the status though...and besides the switches I got are free, rated to IP68 and fit my application (apperancewise) perfectly. I wish everything could be easy! Haha.

I am aware of debounce, I figured if I had a long enough delay to ignore any debouncing I should be okay? But not too long that it misses when the button is depressed? I will do more online reading. However the way the code sits right now if someone is holding the button on, the output pulses on and off according to the delay. Any way to get around that? Because right now there is no issues with debounce.

Don_Kirby · Post by **Don_Kirby** » 30 August 2012, 19:02 PM

How about something like this:

Code: Select all

'Public Variables 
Public ButtonStateFog as Byte = 0 

'Input&#40;s&#41; 
Const InputFog As Byte = 5 

'Output&#40;s&#41; 
Const OutputLeftFog As Byte = 13 
Const OutputRightFog As Byte = 15 

Const DebounceDelay as Single = 0.05

Public Sub Main&#40;&#41;

	'Configure inputs
	Call PutPin&#40;InputFog, zxInputTristate&#41;
	
	'Configure Outputs
	Call PutPin&#40;OutputLeftFog, zxOutputHigh&#41; 
	Call PutPin&#40;OutputRightFog, zxOutputHigh&#41; 
	
	Do
		
		'Wait for someone to press the button
		Do While GetPin&#40;InputFog&#41;
			Call Delay&#40;0.0&#41;
		Loop
		'Yay! someone pressed the Button
		
		'Now wait a little while to debounce
		Call Delay&#40;DebounceDelay&#41;
		
		'Now wait until the user releases the button
		Do While GetPin&#40;InputFog&#41; = 0 
			Call Delay&#40;0.0&#41;
		Loop
		
		'Now we can update the outputs
		ButtonStateFog = Not&#40;ButtonStateFog&#41; 
		Call PutPin&#40;OutputLeftFog, ButtonStateFog&#41; 
		Call PutPin&#40;OutputRightFog, ButtonStateFog&#41;
		Debug.Print CStr&#40;ButtonStateFog&#41; 
	
	'And do it again
	Loop
	
End Sub

If this [untested] code works the way you are intending it, and your ZX device doesn't have to do anything else, you're all set. If you have other things to do at the same time, you'll need to stuff this code in a separate task so the do-loop doesn't hold everything up.

If you want to add a 'Press and Hold' ability, you could do something like this:

Code: Select all

'Public Variables 
Public ButtonStateFog as Byte = 0 

'Input&#40;s&#41; 
Const InputFog As Byte = 5 

'Output&#40;s&#41; 
Const OutputLeftFog As Byte = 13 
Const OutputRightFog As Byte = 15 

Const HoldDelay as Single = 2.0 'Press and hold - hold time
Const DebounceDelay as Single = 0.25 'Debounce switch lockout delay

Public Sub Main&#40;&#41;
	'Define some variables for a timer
	
	Dim Tick as Long
	Dim TickRate as Single = 512.0
	
	'Configure inputs
	Call PutPin&#40;InputFog, zxInputTristate&#41;
	
	'Configure Outputs
	Call PutPin&#40;OutputLeftFog, zxOutputHigh&#41; 
	Call PutPin&#40;OutputRightFog, zxOutputHigh&#41; 
	
	Do
		If NOT&#40;CBool&#40;GetPin&#40;InputFog&#41;&#41;&#41; Then 'They pressed the button!
			
			'Remember what time it is
			Tick = Register.RTCTick 
			
			'Now wait Until they let go
			Do While NOT&#40;CBool&#40;GetPin&#40;InputFog&#41;&#41;&#41; 
				Call Sleep&#40;0.0&#41;
			Loop
			
			'See if they held it down for the press and hold time
			If &#40;CSng&#40;Register.RTCTick - Tick&#41;&#41; / TickRate >= HoldDelay Then 
				'Yes they did
				'Add your press and hold functions here
			
			Else
				'No they didn't
				'Wait for debounce lockout time
				Call Sleep&#40;DebounceTime&#41;
				
				'And update the outputs
				ButtonStateFog = Not&#40;ButtonStateFog&#41; 
				Call PutPin&#40;OutputLeftFog, ButtonStateFog&#41; 
				Call PutPin&#40;OutputRightFog, ButtonStateFog&#41;
				Debug.Print CStr&#40;ButtonStateFog&#41; 
				
			End If
		
		End If
	
	Loop
	
End Sub

I haven't tested any of this, so keep that in mind.

Regarding the SPDT method, you can certainly use one even with the timed 'Press and Hold' style code if you use a momentary switch. A recent project of mine needed a glove friendly up/down selector with long press/short press ability. I used an On-Off-On DPDT heavy duty weatherproof toggle, and it worked great. I do know how difficult it can be to find just the right switch for a project though, sourcing good components at a decent price can be a real problem, especially when you're not buying thousands at a time.

-Don

mikep · Post by **mikep** » 30 August 2012, 20:03 PM

Don_Kirby wrote:

Code: Select all

		'Now wait until the user releases the button
		Do While GetPin&#40;InputFog&#41; = 0 
			Call Delay&#40;0.0&#41;
		Loop

This code only debounces the push but not the release. It also introduces a delay of 50ms in the code so it definitely needs to be in a separate task, if used asis.

dkinzer wrote:Search for "switch debounce" on the Internet and you should find several discussions on the topic. The one by Jack Gannsel is often considered the best treatment of the subject.

Agreed. The Ganssle (correct spelling) algorithm is implemented in "AN221 - Interfacing Rotary Encoders". This code also uses a separate task and has no wait times. The main loop does nothing until an actual button press and release has been registered by the debounce code. You can remove the "encoder" part of the code and save the rest for the 2 pushbuttons (and add one more for your case).

Conrad_Turbo · Post by **Conrad_Turbo** » 31 August 2012, 10:31 AM

You guys are awesome! It didn't work right off the bat but I played with the code a bit and it seems to be giving me a reliable output.

I had the same general idea with the timer...but just had no idea how to implement it. The only question I have is how did you come to the determination of "Dim TickRate as Single = 512.0"? Converts it to seconds?

Code: Select all

'-----------------------------------------------------------------------------------------------------------
Option Explicit

'Public Variables
Public ButtonStateFog as Byte = 0

'Input&#40;s&#41;
Const InputFog As Byte = 5

'Output&#40;s&#41;
Const OutputLeftFog As Byte = 13
Const OutputRightFog As Byte = 15

Const HoldDelay as Single = 0.25 'Press and hold - hold time
Const DebounceDelay as Single = 0.15 'Debounce switch lockout delay
'-----------------------------------------------------------------------------------------------------------
Public Sub Main&#40;&#41;

	'Define variables for a timer
	Dim Tick as Long
	Dim TickRate as Single = 512.0

	'Configure inputs
	Call PutPin&#40;InputFog, zxInputTristate&#41;

	'Configure Outputs
	Call PutPin&#40;OutputLeftFog, zxOutputHigh&#41;
	Call PutPin&#40;OutputRightFog, zxOutputHigh&#41;

	Do 
		If &#40;CBool&#40;GetPin&#40;InputFog&#41;&#41;&#41; Then 'They pressed the button!

			Call Sleep&#40;DebounceDelay&#41;
			'Remember what time it is
			Tick = Register.RTCTick

			'Now wait Until they let go
			Do While &#40;CBool&#40;GetPin&#40;InputFog&#41;&#41;&#41;
				Call Sleep&#40;0.0&#41;
			Loop

			'See if they held it down for the press and hold time
			If &#40;CSng&#40;Register.RTCTick - Tick&#41;&#41; / TickRate >= HoldDelay Then 'Yes they did

				'Add your press and hold functions here
				Debug.Print "Turtle"

			Else 'No they didn't

				Debug.Print "Rabbit"
				'Wait for debounce lockout time
				Call Sleep&#40;DebounceDelay&#41;

				'And update the outputs
				ButtonStateFog = Not&#40;ButtonStateFog&#41;
				Call PutPin&#40;OutputLeftFog, ButtonStateFog&#41;
				Call PutPin&#40;OutputRightFog, ButtonStateFog&#41;

			End If
			
		End If

	Loop 

End Sub 
'-----------------------------------------------------------------------------------------------------------

I will be monitoring 4-5 switches with this exact same configuration, any tips on how to monitor all these pins without waiting on another pin to finish being pressed? I'm sure only one push button will be used at a time, but it would be nice to hit more than one at a time. Separate task for each pushbutton hey?

spamiam · Post by **spamiam** » 31 August 2012, 12:50 PM

Conrad_Turbo wrote:I will be monitoring 4-5 switches with this exact same configuration, any tips on how to monitor all these pins without waiting on another pin to finish being pressed?

No, not a separate task for each button. One task that repeats and checks each one individually. First, you need to determine how long you might have switch bounce. Most bounce for well less than 10 mS. But I saw a hardware debouncer that required a state change for more than 50mS to register the change. So, I used about 50 mS.

Then how many switches do you need to check?

Then you need to decide how much time you can spend in this task and not in your main task.

I did it this way.

I set up a tast to run every 10ms.

For each time the task occurs, I left shift a variable corresponding to an individual pin state by 1. Then I OR'ed the value with the pin state. My pin was pulled high when the switch was off and low when the switch was pressed. The switch needed to be low for for 5 iterations for it to be considered "LOW", otherwise it was considered high.

All switches would be handled this way in each loop of the task. WHen the switch needs to be checked, you lock your task to prevent a switch to the debouncer, then check the byte representing the switch state, AND it with a byte of as many 1's as units of 10mS you want to debounced, e.g. 0b00011111 for 50 ms (as 5 loops of 10ms), then if that resulting value is greater than 0, the switch is not pressed (or in transition).

If you want to know if the switch was pressed at all since the last time you checked, even if it is not pressed at this moment, then you do the debounce check in the debounce loop, and set another variable if it is "pressed", and only clear it when you check that variable.

There are lots of ways to do this, and still have a pretty swift reaction to a switch change, such as using a pin change interrupt and some logic to do the debounce. Of course there is my favorite: add a capacitor to ground between the CPU pin and a current limiting resistor to make a low pass filter.

Post by **dkinzer** » 31 August 2012, 13:36 PM

Conrad_Turbo wrote:The only question I have is how did you come to the determination of "Dim TickRate as Single = 512.0"? Converts it to seconds?

The constant 512.0 represents the RTC tick frequency. It is recommended to use the built-in constant Register.RTCTickFrequency for this purpose so the code will work without changes on devices having a different RTC tick frequency. Moreover, using that constant is more expressive than the constant value.

Conrad_Turbo · Post by **Conrad_Turbo** » 05 September 2012, 8:49 AM

spamiam wrote:No, not a separate task for each button. One task that repeats and checks each one individually. First, you need to determine how long you might have switch bounce. Most bounce for well less than 10 mS. But I saw a hardware debouncer that required a state change for more than 50mS to register the change. So, I used about 50 mS.

Then how many switches do you need to check?

Then you need to decide how much time you can spend in this task and not in your main task.

I did it this way.

I set up a tast to run every 10ms.

For each time the task occurs, I left shift a variable corresponding to an individual pin state by 1. Then I OR'ed the value with the pin state. My pin was pulled high when the switch was off and low when the switch was pressed. The switch needed to be low for for 5 iterations for it to be considered "LOW", otherwise it was considered high.

All switches would be handled this way in each loop of the task. WHen the switch needs to be checked, you lock your task to prevent a switch to the debouncer, then check the byte representing the switch state, AND it with a byte of as many 1's as units of 10mS you want to debounced, e.g. 0b00011111 for 50 ms (as 5 loops of 10ms), then if that resulting value is greater than 0, the switch is not pressed (or in transition).

If you want to know if the switch was pressed at all since the last time you checked, even if it is not pressed at this moment, then you do the debounce check in the debounce loop, and set another variable if it is "pressed", and only clear it when you check that variable.

There are lots of ways to do this, and still have a pretty swift reaction to a switch change, such as using a pin change interrupt and some logic to do the debounce. Of course there is my favorite: add a capacitor to ground between the CPU pin and a current limiting resistor to make a low pass filter.

As of right now I need to check 6 momentary on switches, all will be set up with the same short or long button press to achieve different tasks. Basically the switches will be controlling sets of lights and different functions with these lights (which is the reason for the short and long button press).

The code I posted earlier (based off Don's post) works just fine with one switch, just need it to work with 5 more now. I am not familiar with polling info from a task, but I'll do some digging as well. If you have any suggestions or examples let me know.

dkinzer, thanks for the explanation.

This is 4 of the 8 lights that will be controlled, the other 4 are on the rear of the vehicle (two on the roof rack and two on the hitch).

Majority of the mechanical stuff is done, just need to wire everything in, complete the programming, and wire up the vehicle. I'll definitely post up video once it's done, thanks to all the help from you!

GTBecker · Post by **GTBecker** » 05 September 2012, 9:31 AM

> ... I need to check 6 momentary on switches...

A method I've used to simultaneously debounce multiple pull-down
switches (wired to the same 8-bit port) uses sampling the byte of eight
pins at a regular rate, say 10mS, and NAND-ing (OR-ing) the last few,
say five, bytes at each sample time. Resulting lows in each bit
position then indicates that the corresponding switch has been closed
for five consecutive samples.

Tom

DocJC · Post by **DocJC** » 05 September 2012, 18:37 PM

Nice lightbar assemby!

You did not ask, but I'll mention it anyway...

Vehicles have incredibly noisy electrical systems, with bi-polar voltage spikes of various magnitudes and durations. This means one needs a very robust power supply for the micro for long term, reliable operation. Temperature extremes and vibration are also important factors to consider.

If this is old news, then ignore this post. Otherwise I'd suggest you Google "Load Dump" for more info on vehicle power supplies.

Good luck with your project. What you have so far looks great!

JC

Conrad_Turbo · Post by **Conrad_Turbo** » 06 September 2012, 9:34 AM

DocJC wrote:Nice lightbar assemby!

You did not ask, but I'll mention it anyway...

Vehicles have incredibly noisy electrical systems, with bi-polar voltage spikes of various magnitudes and durations. This means one needs a very robust power supply for the micro for long term, reliable operation. Temperature extremes and vibration are also important factors to consider.

If this is old news, then ignore this post. Otherwise I'd suggest you Google "Load Dump" for more info on vehicle power supplies.

Good luck with your project. What you have so far looks great!

JC

I do appreciate the info, I do have the zbasic controller on it's own filtered 5V regulator, but I will do some more reading and see if what I have is enough. The FET's will be located at the front and rear of the vehicle and controlled from the microcontroller under the dash (near the push buttons). I'm keeping all the temperature sensitive components out of the engine bay and everything I am using should be fine for extreme temperatures, but we'll find out with real world testing.

Thanks for the info Tom, I appreciate the input. The code I butchered up does what I need for every push button, has debounce and can recognize a short and long button press. Might not be the most efficient way but it still uses 13 bytes of RAM and only 1373 bytes of code.

GTBecker · Post by **GTBecker** » 06 September 2012, 10:04 AM

> ... Vehicles have incredibly noisy electrical systems...

Indeed. Here is the conditioning I needed to provide sufficiently-clean 12v to a rotating marine light project. DH6 blows FH1 if power is reversed, DH7 and DH8 are 22v power Zeners. You might also need more capacitance - or even a separate battery - to avoid brownout reboots at engine start.

You might also consider switching unconditioned power to the lamps - and perhaps ramping them up with PWM to avoid the inrush of cold filaments.

twesthoff · Post by **twesthoff** » 06 September 2012, 10:34 AM

What is the value of LH1 ?

On 9/6/2012 1:04 PM, ZBasic wrote:

> ... Vehicles have incredibly noisy electrical systems...

Indeed. Here is the conditioning I needed to provide sufficiently-clean 12v to a rotating marine light project. DH6 blows FH1 if power is reversed, DH7 and DH8 are 22v power Zeners. You might also need more capacitance - or even a separate battery - to avoid brownout reboots at engine start.

Tom
http://www.ustream.tv/channel/bowcam
http://www.ustream.tv/channel/cape-coral-marine-radio VHF
http://67.207.143.181/vlf9.m3u Lightning, spherics

Attachments:
12vPower.gif

GTBecker · Post by **GTBecker** » 06 September 2012, 16:26 PM

> LH1...

~5mH for my application. I used ~40 turns of #18 on a 5/8" ID ferrite toroid, an FT-82-77, I think - but it is not critical. All it needs to do is slow down the current rise of sharp spikes to prevent blowing up the Zeners (actually 600W TVSs, SM6T22As - small despite the brief large dissipation) and, if there is a substantial resistance (a few Ohms) in the 12V supply, an inductor is probably not required.

In any case, the conditioning must be able to supply the operating current continuously. If each of those lamps draws 5A or so and they are all on, that is a considerable load, much larger than my single 6.5A lamp and motor load - hence my suggestion to switch unconditioned 12V to the lamps, but the lamp-switching Mosfets also then need to handle the spikes - so 100V or larger parts are wise.

ZBasic Forum