My question is can we do multitasking in arduino any other board? for example, I want two programs in arduino, one program for controlling motor according to UV or IR sensors reading and other program for lighting some LED according to temperature sensors. Is it possible to run both simultaneously?
No, it's not possible to run 2 programs simultaneously, but almost: it's possible to make your arduino process small amount of each of your programs at a time, so that it will look like it is multitasked. Look for "state machine", or, if your programs are complex, look for an RTOS library.
nigga:
My question is can we do multitasking in arduino any other board? for example, I want two programs in arduino, one program for controlling motor according to UV or IR sensors reading and other program for lighting some LED according to temperature sensors. Is it possible to run both simultaneously?
Yes we can!
But only "cooperative multitasking" is possible, not "preemptive multitasking" which can be done with PCs that have some kind of "operating system" that provides time-slices for "preeemptive scheduling". Microcontrollers have no operating system and therefore they have no preemptive multitasking.
So if you want to have "cooperative multitasking", you must "keep the loop() function running several thousand times per second" all the time, and every "blocking function" call is absolutely forbidden. So you may not use anything like "delay()", "pulseIn()", "Serial.parseInt()" or any other function that is blocking the program execution for longer than a few microseconds perhaps.
If you are able to program all your software without using the "delay()" function, you most likely will be able to program (pseudo-)multitasking software.
But only "cooperative multitasking" is possible, not "preemptive multitasking" which can be done with PCs that have some kind of "operating system" that provides time-slices for "preeemptive scheduling". Microcontrollers have no operating system and therefore they have no preemptive multitasking.
So if you want to have "cooperative multitasking", you must "keep the loop() function running several thousand times per second" all the time, and every "blocking function" call is absolutely forbidden. So you may not use anything like "delay()", "pulseIn()", "Serial.parseInt()" or any other function that is blocking the program execution for longer than a few microseconds perhaps.
If you are able to program all your software without using the "delay()" function, you most likely will be able to program (pseudo-)multitasking software.
Pre-emptive multi-talking is entirely possible on an Arduino, there is just very little justification for its use in all but a very few applications. Pre-emptive multi-tasking has been used on 8080s, and even 8051s, and many other ancient, tiny MCUs, from the '70s.
I've written a proof-of-concept pre-emptive multitasking kernel for the Arduino - not really
enough memory on an Uno for it to be very useful, but on the Mega its pretty reasonable
since there is enough memory for several threads/stacks of useful size.
It makes life more complicated though, and you have to worry about interlocks using things
like I2C, SPI, etc. There are various changes needed across a lot of the Arduino runtime to
make it work though, its not something you can write as a library. You also loose a lot
of controll on realtime performance - you can add priorities, or do round-robin, but its
not clear what a best overall design should be.
It is nice to be able to go delay() and have another thread automatically scheduled - so
somethings get simpler (no state machines needed, just use a thread for each task).
There are various multitasking "nanokernels" around, don't have the links to hand.
One issue that makes using such a framework a real pitfall for beginners is that each
thread has to have a stack, and if that stack is too big you get crashes and grief. If
stacks are large by default you don't get many threads and a lot of RAM is potentially
wasted. On more powerful processors you can pull tricks like dynamic stack-resizing,
but that needs either virtual memory hardware or compiler support for pointer/raw
discrimination.
I have thought about adding dummy macros into the source as hooks for scheduler/
multitasking support, so that all you need to do is adding alternate macro definitions
in variant.h or similar, but never got round to re-factoring my code or suggesting
it publically - one day(!)
Ray Livingston:
The size of the microprocessor does not matter. What is critical for pre-emptive multitasking is RAM (limited on Arduino) or disk space (non-existant on Arduino.)
About nigga (as distinct from nigger), Spears observes (p. 239) that:
It is currently used by younger African Americans (roughly under 30) and some non-African Americans to mean ‘male’; it applies to males of any ethnicity in much the same way as does guy.
So, far from being racist (note that it was being used of Zimmerman), Trayvon’s use of nigga exemplifies the younger African American and broader use of the term without a specific racial coding, a use already previewed in Clarence Major’s 1994 Juba to Jive: A Dictionary of African American Slang, and in Geneva Smitherman’s 1994, 2000 Black Talk: Words and Phrases from the Hood to the Amen Corner.
I suggest we skip the talk on NIGGA and stay with the topic.
I chuckle when I see comments like, "What are you doing that needs multitasking?" Unless you've tried it, you can't come close to appreciate the programme design power in your hands. Let me explain.
SPLat Controls in Australia have a multitasking technology that is quite simple to use with their controllers. Assume you have two independent programmes: one called pushbutton and the other FillControl. The first simply monitors a group of pushbuttons and sets flags to be read by other programmes. The second has a focus on filling a tank as a function of the pushbutton flags. You could say they are functions but actually the descriptive, "TASK" is more applicable.
The code:
Launchtask Pushbutton
LaunchTask FillControl
RunTasksForever
If there is a timing event or even a pause, there is no effect on this technique. The controller will check the timing or pause condition, if it hasn't been met, it will leave the task and execute the next task at the point it had left off. If that second task has a timing or pause condition and its conditions hasn't been met, it leaves that task and returns to the first where it left off. If there are no timing or pause conditions in the task, the first line in the task should include yieldTask to exit the task. Seems odd but when the controller returns, it starts off where it left off.... skips the leave statement, executes the task, returns to the top and leaves. Of course, under the hood we have files points and such that we need not have to worry about.
I love the concept and used their product a number of times. It reduces programming and fits nicely into object programming techniques. They do have a low cost controller called EC1 you could try out. Hope they still have it.
I would love to use Arduino in a similar fashion. Mega2560 could have the power to do it. Anyone?
Torontofred:
I would love to use Arduino in a similar fashion. Mega2560 could have the power to do it. Anyone?
One approach to do so would be creating a "Finite State Machine" as a software framework.
Or if it gets more complicated a set of "several concurrent Finite State Machines".
You just write the simple "state functions" for your state machine, and within these functions you define the conditions that will switch over from one state function to another state function.
Of course, all "blocking" function calls such like "delay()" are strictly forbidden to use in such a framework. If you need pausing a state for some time, you'd have to use the "timeout" method of the state machine to stay within a "waiting state" and then switch over to another state when the timeout has become true.
What you describe is most likely a set of two concurrent FSM:
PushbuttonFSM
FillcontrolFSM
The PushbuttonFSM will possibly just need one timeout function: Every few milliseconds the state times out, then the pushbuttons are read, then the same state restarts.
And the FillcontrolFSM will perhaps need different states, like "filling", "depleting", "highLevelAlarm", "emptyAlarm" or "waitForNextAction".
In terms of just having two (or more) apparently simultaneous tasks: does it make any difference using the FSM or just the succesive calls to the functions to attend every job in the loop() (I mean, the "doing several things . . . " technique)?
It really depends on the response time you need, and how long each process takes. If a human is judging response time, it does not matter. If time is critical, the FSM can respond quicker.
vffgaston:
In terms of just having two (or more) apparently simultaneous tasks: does it make any difference using the FSM or just the succesive calls to the functions to attend every job in the loop() (I mean, the "doing several things . . . " technique)?
The fewer the number of subsystems within a complex system and the fewer the number of individual processing states/steps, the less it pays to break down complexity by using the FSM technique to create single and simple "state functions" for every step to be processed.
In programming, you always will be able to do the same thing in four different ways at least:
the right way
the wrong way
the usual way
and my way
When doing programming for a company, you will probably have to follow "style guidelines" or even have to use special "code frameworks" provided for a given task. In hobby programming, you can decide for what you might think to be useful.
I usually do not prefer the "doing several things . . . " technique in my Arduino programs, but one of these two programming techniques: