Which is the best way to test that a button is pressed
AndyProp
Posts: 60
In computing there are many ways usually to skin a cat.
When checking the state of a pin, it can be done with a falling edge interrupt or frequently checking the pin state and likely even reading from some register. ( I suppose that is what happens when checking a pin)
I am working with an encoder as bellow and followed JonnyMacs very good tutorial on Youtube, and gone over his code with a toothpick too. But then I started to wonder about variations of testing the switch on the encoder, variations that might be better or worse. Why worse?, well its about exploring.
The way I would usually go about this in the other world AT... that I am more familiar with is to create a falling edge interrupt whenever the button got pressed, then disable the interrupt to stop bounces while performing the code related to the button. Ive read here quite a lot that Interrupts are pointless and I agree.
Basically its about checking the state of a pin, in this case i/o pin 40
How about in a main loop where a pin is tested for going low, and once it does the pin gets disabled as an input until the next time it is required.
A bit like
1:
Test the pin state
if the pin is low, jump to the button pressed code
Back to 1
Button pressed code.
Disable the button pin from being an input
Do some stuff
enable the pin
Return
Comments
In general, you can just use the internal pullups to do this kind of thing and just wait for the pin input to go low.
Don't think you can or need to disable it from being an input...
While the P2 supports the use of edge interrupts, those are only available when coding in PASM. If you're coding in Spin, there is such thing as disabling an input. In my encoder object there is a method called check_press() to validate a button press, and force_release() can be used to ensure the same press event isn't used for multiple actions.
On the P1 there was WAITPNE which I found very handy for such cases. On the P2 you should theoretically use the event system to wait for a pin state change. But I've never managed to get that working.
For the shaft encoder, I adapted Jon Titus' Smartpin code page 23 for my forth implementation. Works well. Here's the code I made for Taqoz Forth. You can see the little lumps of assembly language it takes.
Regarding the button, the simplest way to read it is to poll the state every 300mS or so - that's plenty fast enough for most applications.
Cheers, Bob
My Spin2 object for encoders also uses the smart pins, and a debounce method for a button when needed.
For these manually driven rot encoders polling at about a rate of 1 ms is sufficient and does a good job for debouncing. Can be done as a "polled task" in background in Taqoz.
This is reminding me about the new P2 digital filters.. From P2 Documentation:
I think they were mainly intended for things like switch debouncing.
Is anyone actually using them for this?
I have, but I tend to relay on my manual debouncing routine more.
Yes, debounce is entirely what they are for. The circuit is unanimous voting so doesn't work that well for anything else.
Of note, I've often found the Schmitt-trigger input mode is perfectly sufficient without any extra debounce assist.
I made very good use of an interrupt in one project - https://forums.parallax.com/discussion/175543/propspi-emulation-of-a-generic-spi-ram-chip-using-the-prop2/p1 It sped up the responsiveness to randomly timed CS toggles a lot.
PropSPI has all the hallmarks of what you're talking about. There is a bunch of checks involved on ensuring the handling of state change is de-glitched. And is using the Schmitt-trigger input mode.
@evanh Schmitt trigger is a really good idea. I have to remember that one... So many tools, it's easy to forget some...
I saw you had these in a version of the encoder project, this is what you mean by pin filtering?
mode := P_QUADRATURE | dif.[2..0] << 24 ' configure for quadrature case filter ' pin filtering enabled? 0 : mode |= P_FILT0_AB 1 : mode |= P_FILT1_ABthe "Jon Titus' Smartpin code" page is really interesting, its a big load to read but really very interesting what can be done with Smartpins, one ability of using logical operators on two pins jumped out of the page, that's cool. Actually that document deserves a website of its own where all the topics could be placed in a menu/list based format. Its a whole load of really useful information that might otherwise go unnoticed. does it get updated, is there a newer version?
Bob, are you WRD the author of the 'HELLO Propeller II EXAMPLES User Notes' that I have been reading for a month?
Now I see that its identical to "Jon Titus' Smartpin code".
Which one is most up to date? or are they both similar.
Cheers
I haven't written any Smartpin articles, but have contributed to Taqoz forth. Like you say, Jon Titus' work deserves attention. Cheers, Bob
Yes, they can be used for de-bouncing of switches and glitch suppression of noisy signals, i.e. enforcing an minimum on and off time and suppress short pulses. But the term "digital filters" is a bit misleading. You'd normally expect something like an IIR or FIR filter and that is NOT what they are. They don't have a deterministic phase delay and add jitter to the signal. Therefore I avoid using them for anything that goes into a time critical control loop tike encoder signals for servo positioning. An analogue RC circuit and a schmitt trigger input is better in those cases.
Yes. In fact it was Evan who recommended that addition which was helpful for the cheap encoders we got from Amazon. I found that levels 2 and 3 could swamp the readings of the encoder so I removed them. The purpose here is just to clean-up switch bounce (within the encoder).