BlinkyBoard Button Reliability

dat

It seems difficult to reliably get the BlinkyBoard button to register. It takes me 4 or 5 tries sometimes. Anyone else have this problem? Is it a specific pressure that's required, or does the button need to be depressed for a set amount of time, or am I supposed to use a finger nail or my whole thumb, or is it something else?

Threeethan

I noticed this also - I think the problem is actually that it's not in an interrupt, so it's dependent on when your loops that you actually poll the button. I believe that it's possible to set it up as an interrupt, or you can be careful about where / when you poll the button's state.

Xan

Threeethan is absolutely right, depending on what you're trying to do the button might not work too well, since polling it tells you "is it pressed exactly now?" instead of "was it pressed at any point since I last asked?".

Xan

Can you tell me which, if any, interrupt can work for that?
Trying to find out myself just led me to first experience with the reset pin..

Edit: Looking at the board schematics, apparently the answer is "no".
Atmega32u4 should have an interrupt on the pin you're calling IO_A, but not on the button pin.
So short of shorting (excuse the pun) the two pins together it looks grim.

Matt Mets

The button is connected to PB6 (PCINT6/OC1B/OC4B/ADC13), which should work as a pin change interrupt. I think the steps are to set a mask for that bit in PCMSK0, enable PCIE0 in PCICR, then write an isr to handle that interrupt. I'll try to get it integrated into the BlinkyTape library next time I work on it.

it's unfortunately not one of the ones that Arduino supports natively (i tried, but it wasn't possible to route one of those lines over to the button).

There's a library that might work for it, too:
http://playground.arduino.cc/Main/PinChangeInt

Xan

Thanks for the info! A little googling, a short read through the datasheet, and here's some proof-of-concept code: https://gist.github.com/kav2k/8039241

I was specifically looking to make something dead simple that doesn't rely on libraries.

This sketch deliberately waits half a second between checking button state / updating the display, but an interrupt is used to track the current button state and total push count, therefore being in a delay() or doing other work doesn't hinder it.

Note that the button press detection is STILL not 100% reliable (as the button indeed is a bit fickle in when it switches state), but is much more reliable than checking for pin state in a loop.

dat

I was having difficulty with the christmas lights example specifically. After looking at that code more, I understood what Threeethan meant about the button being polled rather than listened to as an interrupt. That code only polls the button once every color change cycle, which is more than a second, hence the lack of response.

I modified the the christmas lights example into my own program that polls the button much more frequently. The button lag is nearly gone now. I just have to consciously hold the button down and it registers soon enough to be usable.

Threeethan

Hi dat,

Yes - the button polling in that example is not the best, and I think we're going to be updating some of our examples with a register-based polling scheme that should make the button more usable.