If I don't what?
a7
I think he means you need to know how to code in order to do it properly without interrupts. 
If you use a physical button susceptible to bounce, it's not "just once," and you need to handle the state detection anyway.
In the CPU world (or PC world), the keyboard and mouse are handled using interrupts. Each key from a keyboard is, essentially a push button. And their events are monitored using interrupts.
In general, and when I say this I mean like 99%, handling buttons should be done using interrupts. And not just because this is done in linux/windows kernel, but because it is a clean way to handle simple external inputs like push-buttons.
Of course, you can do it by polling, depending on what you want to do with that button.
From my point of view, I am using interrupts on my buttons even with the CHANGE mode and I can easily handle many button states very easy: button push, button release, single tap (a quick push-release), double tap, etc.
There is no way to complicate the code with my button polling code, when the ISR can do it for me.
Oh, BTW: if you have a PIR sensor, how do you handle it? Continuous polling or ISR? If you ask me: I will definitely vote for ISR. The code will look way more simpler and clean.
Yes, bouncing is another topic and there is a whole section about debouncing. You can do HW debouncing using eletronic components (few resistors and a capacitor), but you can also do SW debouncing inside the ISR. Bouncing can affect both methods of handling buttons: not just ISR but also polling.
And on what hardware. Things be different on a desktop moochine running MacOS or Linux compared to a microprocessor with 4K Flash and 1K RAM.
If you don't know how to do it without interrupts on an Arduino UNO, for example, it is you who have some learning to do.
The logic and code for dealing with buttons without resort to interrupts is the same kind of logic and thinking that is good to know about in many other circumstances that arise in this kind of tiny system programming.
I suggest to @robert_c that he stop wasting time lecturing us here on this matter. Either we disagree because we know better, or we have no idea WTF you talking about.
I'm unlikely to read anything that would make me revisit many 100s of Arduino sketches I have written without the slightest entertainment of the idea that interrupts would be appropriate, no matter if I might have been able to make them do.
a7
If your_function() happens to be something like this:
const byte buttonPin = 2;
const byte ledPin = LED_BUILTIN;
void your_function(){
static int j = 0;
Serial.print(j++);
for(int i = 0;i < 7; i++ ){
Serial.print(",");
Serial.print(i);
digitalWrite(ledPin,!digitalRead(ledPin));
delay(500);
}
Serial.println();
}
...what would be the normally expected output/behavior?
There are problems with doing certain things within an interrupt context.
I wonder if suggesting the use of bottom-half/top-half lessons here, into the micro-controllers world will ignite some fires? Because, as I see, people here are reluctant to some useful advises that will only make their life much easier.
Probably yes, so I'll stop here.
Are you looking to ignite fires?
If you are going to propose interrupts as a general purpose solution, you need both halves.
Aaaand, you answered your own question 
Aaand, why set a trap in #12?
Questions about what bits of a function fits in an interrupt and what should be left to polling needs asking and answering if you are going to suggest an interrupt as an alternative.
Interested to know how you propose to do that?
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.