Most code examples I see for implementing a button use an interrupt for event changes. Looking at the code example for the FEZ Hat the buttons use the IsDIO18Pressed property inside of a timer tick method. I’m curious the difference between the two methods or is one way preferred in certain scenarios.
Like everything…it depends. First, by “interrupt” in this context (C#) you mean “event”. Personally, I prefer to use events over a timer whenever possible. However, there are times when it makes complete sense to do otherwise.
- If there is no event available. Then all you can really do is poll the property using a timer (or loop…).
- If you are worried about receiving too many events. Timers allow you to do something a fixed number of times on a schedule you can [mostly] control. In your example, it may be that they are using a timer instead of an OnPressed() event as a way to debounce the button.
There are probably other scenarios but those are the first that come to mind.
1 Like
Use hardware interrupt for asynchronous, urgent and Infrequent operations.
Use timer or loop for synchronous, not urgent and frequent operations
Not sure how you can call using a timer synchronous. It also uses events (and handlers) and is as much asynchronous as using an event raised from a button. Because the timer event may actually be raised after the same button event would have been raised, I’d call it even more asynchronous than the button event. Of course, using a loop would definitely be synchronous.
@ ianlee74 - synchronous when in a loop.
@ ianlee74 - I should of say loop, not timer.
@ Posted - Good example for need of using timer, or using loop in the separate thread is for SD Card detection and mounting/unmounting. The SD_CD (Card detect) pin is available, but SD card can be removed from the slot without triggering the event. So in this case constantly checking if SD Card is available will be more reliable then hardware interrupt.
If you have a lot of them (10+ buttons to monitor) then poll. If you expect frequent events, then poll. If it’s a small number of infrequent button presses, then events.
Even for 50+ buttons I would still use interrupts. I believe that pooling would be waste of processor time.
@ EvoMotors - What happens if someone presses all 50 buttons at once? How many event handler threads would be created to handle all of those.
If your device have to accept 50 hardware buttons simultaneously, then you have to do whatever is necessarily to make it work.
2 Likes
Someone pressing 50 buttons at once is an unusual use case? Well, perhaps not for a martian…
@ Mike - Or a piano. If you hit all the 61 keys, it makes a legitimate noise.
1 Like
Hm, if you have a device with 50 buttons, it’s complex enough to handle 50 events at once (I would think) if you implement some kind of priority/order-management…
Yet another reason to use events is that they include a timestamp (to the ms) for when the event occurred. Without this (from polling…) then you would have no idea the order in which buttons were pressed (if you cared).
Well, it does make a noise…
Yes, that’s probably what I meant.
Thanks to everyone else for the replies. It does help me understand the different approaches.
As for the 50 keys, I’ll just tell the users to not press them all at once. Users always follow instructions…
1 Like