BUTTON instruction ?

Catspaw

So I was diddling with the BUTTON command (BS2) and am wondering if I'm missing something about it. The book sez you need to use it in a program loop. understood. Set [whichever] parameter to 255 for debounce with no auto-repeat. o.k. fine.

I'm currently developing/learning about a psuedo-polling structure to my program...trying to look at/wait for serial comm from a PC and looking for button presses.

Here's the scenario. Press a button and have it increment a number to display on an LCD. But, press and hold the button and have it execute ONLY once...until you release the button and press it again.....alot like debouncing and NO auto-repeat.]

However, what I found was that if you put this command in a loop....everytime it whizzes thru the loop while you're holding down the button, it will execute (increment a number)...because the button is still pressed.....basically auto-repeat, effected by the loop as opposed to the a/r function of the command itself.

Inserting PAUSEs caused the timing to stutter.

I had to insert a button state flag to essentially test to see if the button had been released or not. If it hadn't been released, I skip the increment. Once released, the flag is reset and will increment if the button is pressed again.

So, am I missing something about the BUTTON command or have I simply run into what it naturally does?

Note to Paralax: this s[tuff] is alotta fun. Where we're you guys 30 yrs ago?

$WMc%

Catspaw:
'
I can't say thats its right,But thats the way I do it.
'
My gate opener for example looks for the button press or the remote input.(same I/O pin)
When the button is pressed,It jumps to a subroutine with a for/next loop that checks to see if the button has been released.(timer)
If the button has been released, Then read limit inputs and jump to open or close sub.
If the button is still pressed,Then jump to a diagnostic sub.
From here I can view the open/close limits states,Display the "ping" value,And jog the open/close run CR's,And a few more things...( serial LCD )
'
I don't use the "BUTTON" command anywhere in this code.I can't remember using the BUTTON command in any other code either.
'
Hope this helps.

bsnut

Catspaw,

There's always another way to skin the kitty cat without using the Button instruction in your code and here's an example that Jonnymac did on the EFX-TEK.com support forums

Trigger is actually defined as a bit variable; a variable is a value that can change. With the above definition we will read the input level (0 or 1) of the trigger pin (P6) for use in a program. For example, this code is used to 'debounce' a trigger input; debouncing is used to prevent false triggers.

Main:
timer = 0 ' reset debounce timer

Check_Trigger:
PAUSE 5 ' scan delay
IF Trigger = TrOff THEN Main ' check trigger input
timer = timer + 5 ' update timer
IF timer < 100 THEN Check_Trigger ' check timer

In this use the Prop-1 will look at the value of (input) pin P6 and compare it with a constant value called TrOff. If those two values match the program jumps to the label, Main.

And, here's another way that does same thing shown above

  PAUSE 5                                                  ' scan delay
  timer = timer + 5 * PIN6                              ' update timer
  IF timer = 100 THEN Goto_Your_Label         ' goto your code

The only advantage that the Button instruction has over the above code, that everything is done with one line of code and it as features like "Auto repeat" while debouncing the pin you want.

Catspaw

O.K., thanks. As I suspected [but, sometimes I get overly focused and start missing things.)

Ultimately, I didn't like using fixed timing routines because of the stutter. My state flag routine seems to allow execution to occur immediately without the added side effects. I'm assuming that any waiting states will cause me problems down the line. I'm polling three different paths and if something is activated in one routine while a delay is occurring in another, it could be problematic. I haven't graduated to the finer aspects of heavy communication yet...just testing modules and getting the results. When I combine them, I foresee problem resolution expanding and rearing it's ugly head.