Arduino - Page 1
Forum section: electronics / beginners

author: abdullahseba
author_rank: Frequent Contributor
timestamp: July 15, 2014, 08:44:31 am
content: can you make the arduino do multiple things at the same time

author: abaxas
author_rank: Regular Contributor
timestamp: July 15, 2014, 09:03:15 am
content: Yes.Use either a RTOS, interrupts, timers + interupts or just plain old loops

author: bwat
author_rank: Frequent Contributor
timestamp: July 15, 2014, 09:09:27 am
content: Quote from: abdullahseba on July 15, 2014, 08:44:31 amNo. It's a uniprocessor. You can, however, give the impression to the outside world that it does multiple things at the same time.

author: mariush
author_rank: Super Contributor
timestamp: July 15, 2014, 09:32:41 am
content: Like bwat says, it depends on what 'at the same time' means to you.Arduino can't run two programs at the same time like your computer processor can, but you can be clever and write a program that does two or more separate things by spending a tiny bit of time in each second for every separate thing you want your Arduino to do.For example, let's say you want your Arduino to read a temperature, show it on a lcd display and send it to the computer using serial port. You can do all these by writing a program that gives each of these tasks a few milliseconds and rotate between these 3 things all the time : read temperate from sensor (takes about 2 ms, showing it on lcd display takes 1ms, sending to the computer takes 1 ms, then you wait a bit so human can read temperature on lcd display before reading temperature again fron sensor).To your eyes, it looks like Arduino works instantly, but it actually takes 3-4 ms to do those things one at a time... Arduino can't send data to lcd display AND to the computer at same time, it can't parallel them like a regular computer can do with applications (well, in a super simplified explanation, in reality it's an extremely complex subject)

author: Rerouter
author_rank: Super Contributor
timestamp: July 15, 2014, 10:26:00 am
content: that example is a good ones, as both measuring the temperature and updating the display have delays involved, which instead of taking the normal blocking arduino route and writing delay(10) or what ever is required, you could use a timer, and have each bit check to see if its time has been reached, and when it does, run,so you start your temp measurement its code then adds whatever delay it required to the current timer value, while its waiting for that value to be reached the LCD loop moves the cursor and writes the last value, then adds its delay for the next loop, (each task has its own variable to compare against), sometime later the measurement completes, stores the value, and begins the next,during those gaps between each piece of code running, you can shove in other tasks, with most example implementations you would need a task to delay the rest for a very long time to cause something to be missed (as its based on a comparison, it being late means it is run) to better explain myself, the micros timer on the arduino takes about 15 minutes to wrap around on itself, meaning a task would need to hold up the rest for over 15 minutes to make it miss running once,this is also where blocking / non-blocking code comes in, as writing delay(10) simply means the processor can do nothing else during that time, but you know it will complete very predictably, while the time approach allows anything and everything to run in the gap or directly after another, but you can have some variance in how long it takes for a particular task to get a chance to run, (code written first runs first)

author: bwat
author_rank: Frequent Contributor
timestamp: July 15, 2014, 10:33:57 am
content: People are starting to introduce periodic scheduling which is nice to see. I wrote a little booklet on hard real-time kernel design which covers the maths of these sorts of things. You can download ithere. The source code for the kernel described can be downloadedhere. The code is 32-bit specific but it's tiny so maybe someone can hack up an Arduino version.

author: miguelvp
author_rank: Super Contributor
timestamp: July 16, 2014, 03:29:38 am
content: Don't know much about Arduino, but surely it can drive simultaneous bits at the same time right?Don't know if you could do 8 or 16 simultaneous PWMs I guess it depends if you can drive multiple pins with one output word.

author: zapta
author_rank: Super Contributor
timestamp: July 16, 2014, 03:51:24 am
content: Quote from: abdullahseba on July 15, 2014, 08:44:31 amYou can run as many program as you want on a single Arduino, almost like having an arbitrary number of parallel Arduino. The rules are very simple, avoid long blocking functions such as delay() and write your emulated arduino programsvoid setup_arduino1() {...}void loop_arduino1() {...}...void setup_arduinoN() {...}void loop_arduinoN() {...}Then implement the real setup and main as follows:void setup() {setup_arduino1();setup_arduino2();...}void loop() {loop_arduino1();loop_arduino2();...}It's that simple ;-)

author: Kdog44
author_rank: Contributor
timestamp: July 16, 2014, 06:28:09 am
content: I assume you are talking about parallel processing. No I do not think the atmega chip on most Arduino DEV boards can do parallel processing. But, as mentioned before you could write your code in a way that emulates parallel processing.

author: linux-works
author_rank: Super Contributor
timestamp: July 17, 2014, 02:24:02 am
content: there was a cute hack of using 2 arduinos running on the same xtal, running in lock step, using separate code and not sharing anything but the common 16mhz clock.its cheating but its true parallel processing. just nothing shared, though (lol).

author: miguelvp
author_rank: Super Contributor
timestamp: July 17, 2014, 04:43:25 am
content: Quote from: linux-works on July 17, 2014, 02:24:02 amYou could reserve some bits of memory to each processor where only one can write and the other can read and vice versa on a separate fragment. So you can lock (what we used to call semaphores) the other for read/write of memory segments. Use some other blocks for interprocess communication (or what we used to call pipes) and they both should be happy sharing memory. Same thing can apply to I/O. For only two processors it should be pretty painless.

author: Richard Crowley
author_rank: Super Contributor
timestamp: July 17, 2014, 05:59:54 am
content: Quote from: abdullahseba on July 15, 2014, 08:44:31 amYes, and no.NO single-core processor can ACTUALLY run concurrent threads. However, they CAN keep track of many threads and switch between them so fast that to us "slow" humans, they APPEAR to be doing multiple things concurrently.Historically, there were systems with MULTIPLE processors that could run truly concurrent threads, and, of course there are multi-core processor chips now that can truly run multiple concurrent threads. But they are often used in a mode where the main task will use most or all of the cores in parallel to speed up the processing. Of course, some tasks are easier to split into multiple, parallel threads than others, and new compilers make "multi-threading" easier to implement. As well as new chip designs using sophisticated "pipelining" techniques, including "guessing" where to go next, and then abandoning the wrong guesses, etc.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 06:46:27 am
content: Quote from: Richard Crowley on July 17, 2014, 05:59:54 amI think you're using the word "concurrent" in a way that isn't really correct to this programmer's ears. You seem to be discussing parallelism which is a different thing. The Arduino seems to have some support for concurrency ant the coroutine level. Please see the intro to this video for an explanation:

author: Richard Crowley
author_rank: Super Contributor
timestamp: July 17, 2014, 07:02:54 am
content: Since a single processor can do only one thing at a time, the word "concurrent" has been "pre-dumbed-down" in the computer world to refer to what I was saying that "slow humans" perceive as several things happening at once. The word "concurrent" retains its original definition out in the Real World. Discussion of the semantic minutia of "parallel" vs. "concurrent" seem beyond the OP's question. Or perhaps that is exactly what he was asking

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 07:04:03 am
content: Quote from: miguelvp on July 17, 2014, 04:43:25 amYour locking is bus arbitration, not a semaphore. At best it could be called a hardware mutex but it's not a semaphore.Semaphores:The Structure of the THE Multiprogramming System, Edsger W. Dijkstra (1968). The semaphore is introduced to the world in the appendix.Bus Arbitration and Semaphores Implementation:Unix Systems for Modern Architectures, Curt Schimmel, 1994. Chapter 11 gives the details on how to implement the functions P and V on top of a locking primitive.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 07:11:41 am
content: Quote from: Richard Crowley on July 17, 2014, 07:02:54 amWrong is wrong.

author: miguelvp
author_rank: Super Contributor
timestamp: July 17, 2014, 07:26:19 am
content: Quote from: bwat on July 17, 2014, 07:04:03 amA semaphore is a generalized mutex, and it divides blocks of memory so both processes have access to some memory. I'll ready your links later but really its a signaling between processes(a semaphore that is) to allow bidirectional inter process communication.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 07:35:41 am
content: Quote from: miguelvp on July 17, 2014, 07:26:19 amA semaphore needs to count and you can't implement your counter with your reserved bits of memory. A mutex needs only one bit which is why I said you could maybe get away with calling it a mutex, but there's no register there to hold a count. Actually your specification that "only one can write and the other can read" makes the mutex a bit hard as both process would need to be able to (atomically) test and set bits.Also:Quote from: miguelvp on July 17, 2014, 07:26:19 amI would also take issue with this. A semaphore is a coordination primitive and not a communication primitive.

author: miguelvp
author_rank: Super Contributor
timestamp: July 17, 2014, 07:42:59 am
content: so if you reserve "bits" you can't count?BTW a mutex is a binary semaphore, everything was a semaphore before the new terms of locking and mutexes came into play.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 07:47:22 am
content: Quote from: miguelvp on July 17, 2014, 07:42:59 amNo, because you wrote:Quote from: miguelvp on July 17, 2014, 04:43:25 amThe count needs to be updated by both computation abstractions (processor, processes, threads, tasks, whatever). They can't do this with your scheme as they have their own private bits.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 07:53:04 am
content: Quote from: miguelvp on July 17, 2014, 07:42:59 amYes but you need more resources to implement a semaphore than you do with a mutex. A mutex can be implemented with primitives to enable/disable interrupts on a uniprocessor, or with a spin-lock on a multiprocessor. A semaphore also needs counter.

author: miguelvp
author_rank: Super Contributor
timestamp: July 17, 2014, 02:26:46 pm
content: Quote from: bwat on July 17, 2014, 07:47:22 amgetting further off topic, but just because one processor only can write on what the other processor can read it doesn't mean they can't maintain a count.

author: Richard Crowley
author_rank: Super Contributor
timestamp: July 17, 2014, 03:39:43 pm
content: Quote from: bwat on July 17, 2014, 07:11:41 amYes, we agree on that. Apparently what we don't agree on is which is "wrong" and which is "right".

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 05:19:20 pm
content: Quote from: Richard Crowley on July 17, 2014, 03:39:43 pmYour misuse of the technical term "concurrency" is fine as long as you keep it to yourself but when you start communicating with others, especially beginners, it starts to be a problem. I beg you to stop doing this and use the proper terms as the rest of us understand them.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 05:27:26 pm
content: Quote from: miguelvp on July 17, 2014, 02:26:46 pmIn that case you will need an interprocessor communications mechanism to implement a semaphore which would make semaphores unnecessary. As I said in the beginning your description wasn't really a semaphore.I've been writing operating systems since 1993, and for about 15 of those years I was doing it professionally. I'm not mentioning this to try to "prove" I'm right by some appeal to authority, it's just that I've implemented a few semaphore primitives in my time and never before have I heard or seen your locking scheme described as a semaphore. I'm actually interested to see the source of such a system if you had it available.

author: miguelvp
author_rank: Super Contributor
timestamp: July 17, 2014, 05:42:03 pm
content: Quote from: bwat on July 17, 2014, 05:27:26 pmThe semaphore is the interprocess communication.Before mutexes and locks they all were referred as semaphores before, then the industry came with the term mutex to describe a binary semaphore.At work now but maybe I'll draw some diagrams on how both counting and binary semaphores can be achieved with share memory. What else could you use anyways?as for your other point about concurrency, the only difference between concurrent and parallel is that concurrent is independent of other processes and parallel might be dependent on other processes.One is about dealing with events at the same time the other is about processing tasks at the same time. But Richard never said one was the otherQuoteErlang for example is concurrent, and it has no problem running on a single core.

author: zapta
author_rank: Super Contributor
timestamp: July 17, 2014, 05:51:00 pm
content: Quote from: bwat on July 17, 2014, 05:19:20 pmI think this thread is any way above beginners heads.The right answer is yes, an Arduino can do multiple things at the same time (e.g. blinking leds, operating a stepper motor and writing to serial port), just the same as one can take three university classes at the same time or participate in multiple chat threads at the same time.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 06:12:07 pm
content: Quote from: miguelvp on July 17, 2014, 05:42:03 pmThen you're doing it wrong. As I mentioned earlier a semaphore is about cooperation not communication. You can build interprocess communication mechanisms on top of a semaphore but a semaphore is not an interprocess communication mechanism. The only communication is between the processes and the common data structures (a counter and possibly a priority queue for blocked processes which is usually in the kernel). The cooperating processes do not communicate with each other via the P and V interface functions. They may use P and V to enable communication.Quote from: miguelvp on July 17, 2014, 05:42:03 pmI know, I gave you a link to the PDF that introduced the semaphore to the world.Quote from: miguelvp on July 17, 2014, 05:42:03 pmYou maybe misunderstood me. I'm looking for an implementation not diagrams. I would rather see you provide an implementation that is constrained by the description you gave earlier. I've never claimed it was not possible with shared memory. I'm just saying your private memory mechanism isn't a semaphore unless you add counters and, it now seems, an interprocess communication mechanism.Quote from: miguelvp on July 17, 2014, 05:42:03 pmNo that's not correct. Events have nothing to do with it.Quote from: miguelvp on July 17, 2014, 05:42:03 pmI really am not going to say any more on this as I feel like I'm going round in circles. Please look up the term using several sources.

author: miguelvp
author_rank: Super Contributor
timestamp: July 17, 2014, 06:57:08 pm
content: I come from an unix background so:http://tldp.org/LDP/lpg/node7.htmlBut I agree with zapta, this is way beyond what the OP asked and more for academics.BTW what Operating Systems did you write? just curious.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 07:15:51 pm
content: Quote from: miguelvp on July 17, 2014, 06:57:08 pmFair enough, they call it a communications primitive but I, as you may have noticed by now, disagree! I think they've just lumped everything together.Quote from: miguelvp on July 17, 2014, 06:57:08 pmYeah but you've probably thought more about these things in the last 24 hours than you have in the last year. Getting these things put down into words helps solidify understanding. That's not such a bad thing.Quote from: miguelvp on July 17, 2014, 06:57:08 pmI've worked mainly in the telecoms field. I've worked on operating systems for telecoms infrastructure products used in fixed line, GSM, and LTE. (switches, base stations, network controllers etc.). I've also worked on the terminal side writing device drivers for Symbian smartphones. Obviously these are closed systems but I once wrote a little booklet/tutorial on hard real-time kernels where I develop a simple kernel. You can download the pdf (http://barrywatson.se/download/Everyman.pdf) and the code (http://barrywatson.se/download/Everyman.tar.gz). It's a quick read and feedback is appreciated.

author: miguelvp
author_rank: Super Contributor
timestamp: July 17, 2014, 07:35:10 pm
content: Quote from: bwat on July 17, 2014, 07:15:51 pmI once though about doing that but they been closing down so many over the last decade that I'm glad I did not go to that field, and today M$ got rid of most Nokia employees it seems.Edit: 1,100 of them from your neighbors in Finland.I'll take a look later after work.

author: bwat
author_rank: Frequent Contributor
timestamp: July 17, 2014, 07:42:36 pm
content: The telecoms infrastructure field is a great place to work if you like building solid systems. The terminal side (telephones etc.) is horrible as the number one priority is get it delivered for the Christmas market and worry about quality later.

author: zapta
author_rank: Super Contributor
timestamp: July 17, 2014, 09:30:54 pm
content: Quote from: bwat on July 17, 2014, 06:12:07 pmTo paraphrase a great man, it depends on the meaning of the word 'communication'. If 'I just grabbed this resource so don't use it until I will tell you I am done", or "I just inserted 7 items to this queue so you can process them" is not communication than you are right. ;-)

author: bwat
author_rank: Frequent Contributor
timestamp: July 18, 2014, 06:04:00 am
content: Quote from: bwat on July 17, 2014, 06:12:07 pmLooking at the Dijkstra paper again. He uses the term mutex in the appendix so the term is as old as semaphore itself in this context. That was news to me.Quote from: zapta on July 17, 2014, 09:30:54 pmNo, this is all about the scheduling of operations not communication. The semaphore enables communication, it is not the communication itself. There are three types of concurrency primitives we see in programming languages A mechanism for introducing independent sequential threads of control, called processes.A mechanism for processes to communicate. Communication involves the exchanging data, either through shared memory locations or by explicit message passing.A mechanism for processes to synchronize. Synchronization restricts the ordering of execution in otherwise independent threads, and is used to limit the program's nondeterminism where necessary.To quote the inventor of the semaphore QuoteI really can't see me calling a semaphore a communication primitive so I'll say no more. Feel free to continue calling it what you wish. Dijkstra, E. W.http://www.cs.virginia.edu/~zaher/classes/CS656/p341-dijkstra.pdf Reppy, John H.,Concurrent Programming in ML, Cambridge, 1999.

author: Rick Law
author_rank: Super Contributor
timestamp: July 19, 2014, 04:31:19 am
content: I think the OP is confused by marketing (that you need more core to do more things)... One does not need multi-core for the machine to multi-tasks.Concurrency does not start with multicore or even hyperthread. Pre-hyperthread late Pentiums has multiple instruction pipelines and multiple instruction decoders. So, multiple things are going on within the same clock-cycle and within the lone core. Mean time, time-slicing and time-sharing was nearly as old as the first computer.If I may inject a reminder as a segway back to the OP's question.TheArduino UNO is a dual processorboard. The ATMEGA16U2, and the ATMEGA328. The 16U2 subsystem handles communication and other board-management tasks at the same time while 328 handles the user-written logic.But, these are too esoteric for typical users. However, it explains why the question "what do you mean by doing things at the same time" matters...Now to the questions:Can it run two application at the same time? No.Can a single application do multiple tasks at the same time? YesOne can view the loop() function as a time-slices, and you can have it call say 4 different things - each one returning gracefully if it has nothing to do or if it completed what it must do. so the loop() essentially do:void loop() {doTask1();doTask2();doTask3();}** The tasks are done in sequence, however, the time delta between tasks is so short it can be view as "at the same time" in most cases. You may view it as cheating, but even multi-core system shares the same memory so they can not really both read the same memory at the same clock cycle. (or the same USB port, or the same whatever)This requires each task to come back quickly when it is done, and not sit there and waste time such as a delay(nnnn) blocking everyone else. This was called "cooperative multi-tasking" by some, and was the cornerstone of early (pre Windows95) Microsoft Windows and other "Operating Environments". Many did not call Windows an "Operating System" then since it was on-top of the real OS which was PCDOS or MSDOS).So, task1 could be running your thermostat, task2 could be running your air-pump for the fish tank and task3 could be a simple clock display. Key is, they are all integrated into the same single program.So, you can do multiple tasks as long as you integrate all the tasks into the same program.Even while Windows was doingcooperative multi-tasking, other systems implementedpreemptive multi-tasking. NotablyDoubleDoswhich partitions the system into two, preemptively take control away from one application and switch over to the other based on time. So you have one physical machine divided logically into two, each one has a slice of time (time-slicing).Preemp or not, how ever many cores you got, you merely decreases the percentage of the time one task waits on another - as no doubt at some point, it will hit a piece of hardware inside that is not sharable. Arduino has one core, so everything is serialized. With say a two-core arduino, some things still must be serialized (such as the ADC).The OS (in this case, everything under the loop() call) controls how it time-slices and your lone loop() is your time-slice which is "all the time Arduino management doesn't use". You can serialize your many tasks you want it to do, giving each a part of your time to do it with, and write it each task with in mind to "cooperate" - others are waiting. You can do as many tasks as you want within the resource limit.So, I think that answers your question about "can Arduino do multiple things at the same time" and explained a bit why others are kick the question back with "what do you mean..."

author: Skimask
author_rank: Super Contributor
timestamp: July 19, 2014, 04:33:00 am
content: I don't think the O/P cares anymore!

author: bwat
author_rank: Frequent Contributor
timestamp: July 19, 2014, 07:54:11 am
content: Quote from: Rick Law on July 19, 2014, 04:31:19 amThe ATMEGA16U2 is adedicatedmicrocontroller used as an I/O chip according tohttp://arduino.cc/en/Main/ArduinoBoardUno. It could be replaced with a nonprogrammable digital circuit and it would not make a difference to the programmer. Your calling the Arduino UNO a "dual processor board" is no different to saying that a desktop PC with a single core CPU is a multiprocessor machine because it has microcontrollers in the keyboard, the harddisk controller, and the monitor. The term uniprocessor meant that the board has onegeneral purposeCPU that can run a user program. If anybody can get the Arduinos's ATMEGA16U2 to run user defined code they should let me know so I can correct my statement.Edit:Just seen that you can program the ATMEGA16U2 via the DFU bootloader. It looks like the bus between them would be TXD and RXD pins. So you could call it a multiprocessor machine if you replaced its firmware.

author: Rick Law
author_rank: Super Contributor
timestamp: July 19, 2014, 09:37:43 am
content: Quote from: bwat on July 19, 2014, 07:54:11 amre: "our calling the Arduino UNO a "dual processor board" is no different to saying that a desktop PC with a single core CPU is a multiprocessor machine "Indeed all my PC's were multi-processor machines.- My single core 486 PC was a multi-processor machine. It has a 80486 CPU, an 80487 FPU, a GPU, another CPU managing the SCSI...- My PC Limited (renamed to Dell) 286 PC had an 80287 FPU, an ATI GPU...- My Atari 800 (6502) had a separate processor for graphics with "collision detection" (to detect game images colliding indicating a hit).- My SOL20 (Z80, I think) had another processor doing the 650K "hard sector" Micropolis floppy... Could be 8080, but too long ago, I forgot.Even a lowly SD card has it's own build-in processor to do the memory management... So add another processor to the count.The "UNO being dual processor" was to make the to the OP that multi-tasking has nothing to do with whatever CPU you are running. The CPU, however many cores, is not the world. There is a lot more to a machine than the cores - and - however lowly the machine, there is always something going on in parallel. Even my 8086/8088 (HP200 with TimesTech upgrade to CPU speed and Ram) was quite happy doing multi-tasking with DoubleDOS.Multi-tasking is not dependent on multi-threading or multi-cores or multi-processors SMP machines. It just depends on how the OS and the apps are written. To think of multi-tasking requiring multi-processors or multi-core or as a pure CPU function is just way way way outdated thinking back when analog computers were the only game in town.Rick

author: bwat
author_rank: Frequent Contributor
timestamp: July 19, 2014, 10:01:07 am
content: Quote from: Rick Law on July 19, 2014, 09:37:43 amYour 8086/8088's multitasking had nothing to do with things going on in parallel, at least not at the level of instruction parallelism and above.Quote from: Rick Law on July 19, 2014, 09:37:43 amNowhere in the thread has anybody made the claim that that multitasking requires more than one CPU.

author: Rick Law
author_rank: Super Contributor
timestamp: July 19, 2014, 10:33:11 pm
content: Quote from: bwat on July 19, 2014, 10:01:07 amre: Nowhere in the thread has anybody made the claim that that multitasking requires more than one CPU.I infer from the OP's question "can you make the arduino do multiple things at the same time" that he/she is concerned about the ability of the MCU to do multitasking. I therefore want to share with him that even something a lot slower can do multitasking and that multitasking is not "made possible only by something special" in the hardware such as multi-thread/multi-core/multi-processor. Something as slow (by today's standard) a PDP8 or a lone 8080 can multitask just fine.I think the OP is just getting started. It is good for him/her to know that this whole "do more than one thing" really depends on what he means by that statement, and that if he learns to maximize what is there smartly, he can do a lot with what he got.

author: gxti
author_rank: Frequent Contributor
timestamp: July 20, 2014, 01:52:50 am
content: OP did a hit-and-run. Post a vague and unanswerable question and watch in glee as dozens of speculative responses pile up.

author: zapta
author_rank: Super Contributor
timestamp: July 20, 2014, 04:27:39 am
content: Quote from: gxti on July 20, 2014, 01:52:50 amWe the suckersActually it clarified to me the difference between concurrency and parallelism (check the Rob Pike's video).

author: Rick Law
author_rank: Super Contributor
timestamp: July 20, 2014, 04:35:25 am
content: Quote from: zapta on July 20, 2014, 04:27:39 amNaaa... Look at the bright side, we did more idea exchange and we learned more from each other; or at the very least, blew some steam by arguing with each other.The one thing I appreciate from reading this forum is the vast spectrum of experience and knowledge this forum's participants shown.