Arduino

[abdullahseba]

can you make the arduino do multiple things at the same time

[abaxas]

Yes.

Use either a RTOS, interrupts, timers + interupts or just plain old loops

[bwat]

can you make the arduino do multiple things at the same time

No. It's a uniprocessor. You can, however, give the impression to the outside world that it does multiple things at the same time.

[mariush]

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)

[Rerouter]

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)

[bwat]

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 it here. The source code for the kernel described can be downloaded here. The code is 32-bit specific but it's tiny so maybe someone can hack up an Arduino version.

[miguelvp]

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.

[zapta]

can you make the arduino do multiple things at the same time

You 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 programs

void 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 ;-)

[Kdog44]

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.

[linux-works]

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).

[miguelvp]

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).

You 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.

[Richard Crowley]

can you make the arduino do multiple things at the same time

Yes, 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.

[bwat]

can you make the arduino do multiple things at the same time

Yes, 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. 

I 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:

[Richard Crowley]

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   

[bwat]

You 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.

Your 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.

[bwat]

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   

Wrong is wrong.

[miguelvp]

You 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.

Your 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.

A 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.

[bwat]

A 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.

A 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:

but really its a signaling between processes

I would also take issue with this. A semaphore is a coordination primitive and not a communication primitive.

[miguelvp]

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.

[bwat]

so if you reserve "bits" you can't count?

No, because you wrote:

You 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.

The 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.

[bwat]

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.

Yes 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.

[miguelvp]

so if you reserve "bits" you can't count?

No, because you wrote:

You 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.

The 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.

getting 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.

[Richard Crowley]

Wrong is wrong.

Yes, we agree on that. Apparently what we don't agree on is which is "wrong" and which is "right".   

[bwat]

Wrong is wrong.

Yes, we agree on that. Apparently what we don't agree on is which is "wrong" and which is "right".   

Your 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.

[bwat]

getting 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.

In 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.