Button Command

Using PE 5.2.0 & 18X V8.6

I've always thought of the button command as a bit of a "lost soul" and never really gave it much thought until recently.
For debounce, a simple test input and pause does the job, however, when recently trying to create a menu system I thought I'd explore the "repeat" feature.
This proved to be quite tricky and I don't think the description given in the manual helps. Here's what I found:-

As per the manual:
Button Pin,DownState,Delay,Rate,Var,TargetState,Address

The first thing I got was a syntax error. Fortunately, the error message clearly explained what the problem was. I'd already set up all my symbols for my I/O pins and thought I'd replace "Pin" with the symbol I'd used for that input. But no, it doesn't work like that It didn't want "pin6", it just wanted the "6", so my symbol "Button_A" (which is used elsewhere) can't be used in the Button command line. Why is this convention?

Then the fun started with "Delay" and "Rate".
I put in some nominal values of 128 for each.
Couldn't distinguish between the first push and a repeat. Tried all sorts of values and combinations to no avail.
It wasn't until I started to debug "Var" that I realised what was actually going on. "Delay" is actually a COUNT of how many times you've been through the loop. In a tight loop, the "Delay" is virtually nothing.
Having worked that out and inserted a pause in my loop, things were looking up until I tried to make the pause as small as possible and use the largest "delay".

The manual is quite clear, "delay" can be 0 to 255.
Except 255 is a 'special' value which prevents the repeat from working at all. All you get is one jump to address when "delay"=255. 254 is the maximum value you can have. This is actually a useful feature and should be explained in the manual.

So, here's my description of how "Button" works.

"Pin" uses the OUTPUT convention, NOT the input convention.
"Delay" is how many times the command must be passed before it does the first repeat.
"Rate" is how many times the command must be passed before it subsequent repeats.
"Var" must be set to zero before the command is used (as explained in the manual) but that must be a once only setting. It must be done before you enter the loop which scans your button.

Maybe this is all obvious to everyone else, but it kept me bemused for quite a while

Excellent info. I hope this gets appended, (or amended), to the next manual update.

Hi BB,

some good info there. I have read up on the Button command previously but likewise it has been dormant in the coding.

wrt the "pin" portion of the command:

other input comamnds like pulsin, readadc, readtemp, serin and shiftin (spiin) only take the numeric value (0 to 7) for the input pin. The Button command example does not include the text "pin", so I would been right there.

But still good to know the other quirks in advance of needing to use the command in anger.

"Pin" uses the OUTPUT convention, NOT the input convention.

Click to expand...

No, it uses the normal convention as used by all other input type commands, readadc, readtemp, count pulsin etc. etc.!

Every command, whether input or output, always addresses the pin itself, ie just a number like 3.

pin3 is not the name of a pin. It is the name of a bit variable (notice how it colour codes). That variable contains a 0 or 1, dependant on whether the real-life pin is high or low.

So
if pin3 = 1 then
means
If the variable containing the status of input number 3 = 1, then

The other points are useful and will be added to the manual.

Thanks Technical, points noted.

So how could I make this readable:-

Symbol Btn_A = pin6
Symbol Btn_A_as_required_by_button_command = 6
Symbol Pushed = 1

...first bit of code
if Btn_A=Pushed then....

...within a loop
Button Btn_as_required_by_button_command,Pushed,....

Will I always need to use two symbol statements for the same input?

You can't define a variable (pin6) and a constant (6) with the same symbol pseudo name. So yes, you will always need two different symbol names.

BeanieBots said:

So how could I make this readable:-

Symbol Btn_A = pin6
Symbol Btn_A_as_required_by_button_command = 6
Symbol Pushed = 1

...first bit of code
if Btn_A=Pushed then....

...within a loop
Button Btn_as_required_by_button_command,Pushed,....

Will I always need to use two symbol statements for the same input?

Click to expand...

It is a pain but there's no easy way round it. The way I've worked round it is ...

Symbol BTN = 6
Symbol BTN_PIN = pin6

If BTN_PIN = PUSHED Then ...

Button BTN, PUSHED ...

It could be possible to have "If PIN BTN6 = PUSHED Then" but there's nothing planned along those lines that I know of.

Ah well, we can't everything!
If it is ever changed, please add "symbol LED = portc 6" as well

Added BeanieBots' notes to the sample code in the "08M controlled Adjustable Voltage Regulator" (http://www.picaxeforum.co.uk/showthread.php?t=10139).

The sample code in Post #7 uses the button command to adjust the set voltage.

How about

How about having a 'symboltext' command which makes one particular text string be identified as another text string.
e.g.

symboltext {led2}={portc 6}

main:
high led2
...

(another colour setting added to the colour options)

I'm also now pretty rusty on BUTTON parameters, having originally used this tempting command back in my late '90s Basic Stamp (BS)days. Attempts ~2004 to give it some PICAXE mileage left me unsatisfied, but that's not to say it should be shelved. Perhaps a lucid "Hippy" check out may be in order?

FWIW, a quick BS +button Google shows the likes of http://www.emesys.com/BS2buttn.htm and http://www.eetindia.co.in/ARTICLES/2002FEB/2002FEB25_AMD_CT_MSD_EMS_AN.PDF?SOURCES=DOWNLOAD and also http://www.emesys.com/BS2index.htm#earth

tiscando said:

How about having a 'symboltext' command which makes one particular text string be identified as another text string.
e.g.

symboltext {led2}={portc 6}

Click to expand...

A very good idea that we had not considered. Basically a simple 'replace all' function before the compiler is called. We'll consider it.

Isn’t it known commonly as a Macro?

Thanks BB. I found the docs confusing.

Originally posted by Technical
A very good idea that we had not considered.

Click to expand...

I have requested strings be defined by symbols previously. Now looking forward to new possibilities.

My previous request to PICAXE for inclusion of strings in definitions

I keep requesting an inline assembler. But no-body listens.

boriz said:

Isn’t it known commonly as a Macro?

Click to expand...

In the C-world it would be a #define, macro would traditionally refer to a multi-line in-line expansion but is also used to refer to a single word or line.

boriz said:

I keep requesting an inline assembler. But no-body listens.

Click to expand...

I'm sure Rev-Ed do listen however it's not that easy to implement ( the smaller PICAXE's could not support it due to the PICmicro architecture used ) nor would it be simple to implement in a way which would be usable.

The BAS800 programmer and associated Convert to Assembler function can bridge the gap between PICAXE Basic and Assembler. It is not designed as a commercial compiler but it is possible to build peripheral devices using Assembler that can be controlled by other PICAXE devices.

Thanks for posting this explanation.
I also had wondered about the "button" command, and had experimented a little with it without success.
I was also planning on using debug, but decided to search first, to avoid re-inventing the wheel.

Hopefully the people at Rev-Ed take cue on this issue, as there are several commands on the Manual 2 that I feel are not properly explained.

Another handy little trick i found with "Button" is that if "var" has the same value as "delay", then it is the FIRST jump to "address".

Not wanting to Stir The Pot (would I do a thing like that ) there is a hardware
solution that works very well for preventing the Switch Bounce effect.

A simple 0.1µF (100n) Monolithic Capacitor or Polyester Cap placed across the switch
contacts will absorb most of the switch noise in most cases. If you have a particularly
bad/noisy switch just make the cap a little larger e.g. 0.22µF.

We will quite happily plaster a circuit board with 100n caps to reduce any stray
voltages or ripple and place pullup, pulldown resistors on any unused inputs, The
addition of a small capacitor across a switch contact shouldn't break the bank.

2¢ worth.

boriz said:

I keep requesting an inline assembler. But no-body listens.

Click to expand...

I'm listening and cheering for ya, boriz!

And for those interested in an external hardware solution to contact bounce, check out the link below. The things you can do with this chip is amazing.

http://webs.uvigo.es/doe/DataSheet/mc14490.pdf

Lefty

Agree the button command may be overkill for simple debounce but the button command also handles the simulation of a PC keyboard with tuneable delay and then key repeats if held down.

I've always found it cheaper to insert a "pause 10" line than to use either a cap or a chip for debounce.
When you find you have a particularly 'bouncy' contact, it is usually easier to change the pause value than it is to change the cap.

Using the "button" command just for debounce, well, yes, lots of typing, probably cheaper to use a cap at my hourly rate. Then again, you could just use "if pin=.. pause N". As described in post #1.

Maybe I'm just too lazy and tight fisted. Everyone to their own I guess

Being a hardware man at heart, I'd prefer a hardware solution to a hardware problem, cct board real estate permitting. That MC14490 is a brilliant little chip, but even cross coupled nand gates will do it perfectly at a pinch. No need to worry about whether your delays/timing is right, it's already done for you.

I don't think the cap across the switch contacts is the best method. It will help with high quality switches that have minimal bounce, but once things start wearing out and the contacts bounce longer the cap will be overwhelmed eventually and bounces will get through.

I see the Button command as only usefull for the repeat function, but even that can be corrected with a minimum of hardware.

It's a trade off between board space and program/speed space.
The Button command will take time to execute and use up code space and speed, that are at a premium in the Picaxes.

My $0.02 worth.