Complete noob here. Have some programming and electronics knowledge - enough to be dangerous anyways. Have a Yun with specific project in mind and have run some examples etc to get my head around basics. So I'm going to be asking some duh questions here to hopefully step me through the project programming wise.
First thing that seems odd to me (based on programming in other dimensions) is that it appears sensing inputs has to happen in a recurring loop. I think one example I looked at checked the pins and delayed 100ms and checked again and on and on. This seems archaic to me. Is there not a chance you could miss a button press if the loop delay is long enough? Why would the processor not just raise an interrupt on state change? Is there some way to use interrupts on a Yun? I have 8 inputs.
Using blocking delay() is bad most of the time. The Arduino language has built in functions millis() and micros() that can be used for non-blocking delays and timing. A bad example is none the less an example.
mediamad:
Why would the processor not just raise an interrupt on state change? Is there some way to use interrupts on a Yun? I have 8 inputs.
It's possible to use interrupts, although each microcontroller has different restrictions about what sort of interrupt is supported on what pins. The problem is that all of them have very limited abilities to manage interrupts and are not suitable to do anything complex within an interrupt context - even with this approach, you almost always end up with the interrupt handler just notifying the main thread that there is something to do. So, ultimately you are still back to a polled solution and the use of interrupts has just added significant complexity to the design without solving the underlying problem. The conventional approach which works pretty well is most cases is to simply poll for whatever events are relevant. Interrupts would be reserved for situations where latency of responding to input events is critical.
groundfungus:
Using blocking delay() is bad most of the time. The Arduino language has built in functions millis() and micros() that can be used for non-blocking delays and timing. A bad example is none the less an example.
How would you use millis()? By creating an if condition that compared millis() to some previous value ie. >= previousMilli + 50? Is this what your suggesting? Sure would be nice if you could just create a timer that executed a list of functions when it elapsed.
It's possible to use interrupts, although each microcontroller has different restrictions about what sort of interrupt is supported on what pins. The problem is that all of them have very limited abilities to manage interrupts and are not suitable to do anything complex within an interrupt context - even with this approach, you almost always end up with the interrupt handler just notifying the main thread that there is something to do. So, ultimately you are still back to a polled solution and the use of interrupts has just added significant complexity to the design without solving the underlying problem. The conventional approach which works pretty well is most cases is to simply poll for whatever events are relevant. Interrupts would be reserved for situations where latency of responding to input events is critical.
I guess my concern is if using a momentary switch you have the potential to miss the activation correct?. Seems only logical in modern day that they would just build in DI events.
I don't see any reason to delay 100 mS between checking pins. What's the point?
Certainly interrupts can catch a very fast event, but generally pushing a switch on (say) a remote control you are expected to give it a good shove and not just get in and out in a millisecond.
Sometimes we see people going to a lot of trouble to do interrupts, but have their main loop do nothing, or practically nothing. If your main loop is executed a few hundred times a second, it can be testing switch values as well. And remember, detecting the interrupt is one thing, doing something useful is another. So often you set a flag, and then test that flag in the main loop. So the point of doing that, compared to testing the switch itself in the main loop, can sometimes be a bit obscure.