How do I have this device call a function when an input is changed rather than having to poll for an update?
And will that allow it to run two functions called by updated inputs in parallel? (i.e. different threads/processes)
No multithreading, but you probably don't need it.
What's wrong with continuously reading the pin values? Is this for analog or digital input?
Hello!
How do I have this device call a function when an input is changed rather than having to poll for an update?
You use interrupts.
http://www.arduino.cc/en/Reference/AttachInterrupt
What's wrong with continuously reading the pin values?
What if the change occured while executing a different section of code?
I have been thinking about this question as well. This may not help you with designing your program, but:
What's wrong with continuously reading the pin values?
Procedural code can't continuously read anything. Code executing in a loop can however continually read things. (The latter means repeatedly).
Sorry if this sounds a little pedantic, but when it comes to program design we should be careful in our use of terminology so as not to obfuscate what is going on.
If the input is human-generated, continually reading the pins should be OK. (If you press a button and nothing happens, you will usually press it again.) A loop that runs many times per second is bound to detect it sooner or later. If it's an automatic input and can happen many times in quick succession AND it's crucial not to miss any, it sounds like interrupts is the way to go.
No multithreading, but you probably don't need it.
Isn't using interrupts the equivalent of multithreading?
Isn't using interrupts the equivalent of multithreading?
Not even close.
A timer driving an interrupt that switches between execution contexts is the basis of multithreading on a single microprocessor, but that doesn't make interrupt handling equate to multithreading by a long shot.
What interrupts provide in the context of microcontrollers is non-sequential execution. Without interrupts your program is the only code executed on the microcontroller, and it executes sequentially without interruption based exclusively on the flow control in your code. An interrupt handler is a way to "stop and go do something else", then return to the sequential execution of your program at the precise point where it was interrupted.
-j
As it happens, when time/work/family permits, I'm working on a simple IR decoder that is interrupt driven, which posts received commands into a queue.
The reason for going down that route is that I don't want the system to freeze out while I'm reading the IR data in (or seeing if it's available).
I used to tell my students that an interrupt was a call to a subroutine trigged by hardware.
What you do with it after that is up to you.
Isn't using interrupts the equivalent of multithreading?
Not even close.
I disagree. In a pedantic sense, using interrupts gives you the equivalent of one "thread" for each interrupt level that your cpu supports, at least in terms of the concurrency, contention, synchronization, and reentrency problems that you may run into.
What the original poster wants is some more opaque event-handling, which is most simply done by polling the input repeatedly:
void loop()
{
if (Serial.available()) handle_serialinput();
if (check_inputpins()) handle_inputchange();
if (check_analogThresholds()) handle_analog();
if (check_time()) handle_timers();
my_work(); /* handle other things */
}