Using two arduinos for more processing power

Hey guys,

I was thinking of spanning a project over two Arduinos.
One will run the LED strip code, and the second will run everything else and issue display commands to the first.

That’s an example that comes to mind, but I’m open to discussion about any projects/applications of two Arduinos for more processing power.

It’s probably better to use a faster chip (something like an ARM based Teensy comes to mind) when you have a lot of processing to do, but I thought i’d ask anyways.

Panici: I was thinking of spanning a project over two Arduinos. One will run the LED strip code, and the second will run everything else and issue display commands to the first.

You aren't exactly giving us much to go on.

How many LEDs? What, exactly, is "everything else"? What sort of display commands?

That's an example that comes to mind, but I'm open to discussion about any projects/applications of two Arduinos for more processing power.

Well, if you are dead set on using two Arduinos, regardless of whether you need two or not, then go for it. Or, if you want one Arduino to be cotrolled by another, say by radio, IR remote, Ethernet, Bluetooth, etc, then that too, would require two Arduinos. If you don't actually need two Arduinos, though, you might want to program one, and SEE if you have the power, memory room, and speed to do it. If not, THEN is a good time to split the workload.

It's probably better to use a faster chip (something like an ARM based Teensy comes to mind) when you have a lot of processing to do, but I thought i'd ask anyways.

It's always a surprise to people, to find out just how much an Arduino can do in a really short time. Try with one before you decide on two.

For a master-satellite processor setup like this I'd suggest using Arduino Pro Mini's for the satellites as they are small and cheap (although you need a usb->serial cable to program them (or ArduinoISP)).

The main Arduino could be a Mega to provide more memory and pins.

If you want more processing power a Due (3.3V) could be the master, and the satellite Pro Minis be 3.3V versions. But the choice of voltage may be forced by something else. Since SDcards are 3.3V that could be a consideration.

If you just need more pins there are IO expanders and shift registers and so forth.

lar3ry: You aren't exactly giving us much to go on. How many LEDs? What, exactly, is "everything else"? What sort of display commands?

I was using that as an example. What comes to mind is bitbanging a long string/grid of WS2811 based RGB LEDs.

Have one Arduino responsible for that, and it receives display commands from the "Master" unit that is doing the rest of the work. (Whatever that may be, just brainstorming here)

I'm really just looking for ideas on how to expand the power of an arduino.

MarkT: For a master-satellite processor setup like this I'd suggest using Arduino Pro Mini's for the satellites as they are small and cheap

That was exactly my thought. Third party Pro Minis can be had for under $4 each now. So putting two together for a processing power boost seems like a good idea!

Hi,

If it's just power you're running low on, and there's no need for additional processing you'd also be able to provide that by using a second power supply for the addressable LEDs. Do you have an idea of the current required for your project yet? That will determine what you can use - just remember to connect the GND from the external supply to your Arduino even if it doesn't directly supply the Arduino too.

Cheers ! Geoff

strykeroz: Hi,

If it's just power you're running low on, and there's no need for additional processing you'd also be able to provide that by using a second power supply for the addressable LEDs. Do you have an idea of the current required for your project yet? That will determine what you can use - just remember to connect the GND from the external supply to your Arduino even if it doesn't directly supply the Arduino too.

Cheers ! Geoff

D'oh! I meant power in the colloquial sense, as in processing capacity/speed.

Panici: D'oh! I meant power in the colloquial sense, as in processing capacity/speed.

Ah. My bad entirely. Here we use the metric term 'grunt' :)

As long as the tasks can be properly partitioned I think offloading tasks to slave CPUs is perfectly valid, in fact I've just finished a system for an industrial-control company that does just that, 10 PCBs of which I think 7-8 have their own CPUs, one (the master) is a Mega2560 and the others 328s. Even the power supply has on-board smarts.

One reason for this is that the modules sit on a DIN rail with a built-in 5-way bus, 2 for power, 1 for reset and 2 for I2C. Thus all sorts of info can be obtained with just a couple of signals, for example the PSU can report which power source is being used, voltage levels of main and backup sources, current used, temperature of the huge FETs and diodes etc. Meanwhile the master CPU can forget all that stuff until it wants to know or there's an alarm condition.


Rob

The problem with using multiple MCUs in a system is that the task of communication itself on each device requires substantial resources - code space, interface pins (2) and CPU cycles (lots!).

If you are driving the WS single-wire bus chips, then you cannot interrupt the part of the code which dumps the data to them, but they do not require to be refreshed regularly so you alternate this function quite separately with whatever else you need to do to determine the patterns to be displayed. That "whatever else" is likely to be just as easy to define in full, as to communicate with another module to be told the pattern and replicate it in local storage as an intermediate step.

Paul__B: The problem with using multiple MCUs in a system is that the task of communication itself on each device requires substantial resources - code space, interface pins (2) and CPU cycles (lots!).

If you are driving the WS single-wire bus chips, then you cannot interrupt the part of the code which dumps the data to them, but they do not require to be refreshed regularly so you alternate this function quite separately with whatever else you need to do to determine the patterns to be displayed. That "whatever else" is likely to be just as easy to define in full, as to communicate with another module to be told the pattern and replicate it in local storage as an intermediate step.

Hmm I figured this might be the case. Basically the overhead from the extra communication is too much.

So I guess the real question is, how can we get two arduinos communicating with very little overhead.

In the example of the LED shift regs yes there is no real advantage as long as the total transfer time is short, ie high speed and/or not a lot of LEDs, but if there were a 1000 LEDs and a refresh rate of 1mS it might be a different story. It’s horse for courses.

how can we get two arduinos communicating with very little overhead.

That probably depends a lot on the nature of the comms required, pulsing a single pin may be enough, hardware parallel FIFOs are good if you need some real throughput. On a chip with a hardware FIFO on the UART there’s almost no overhead in sending some bytes. And you can exchange a single byte using SPI in no time at all with almost no cost to either CPU. And then there’s dual-ported RAM memory-mapped into the address space of each processor.

So it depends.


Rob

Graynomad:

how can we get two arduinos communicating with very little overhead.

That probably depends a lot on the nature of the comms required, pulsing a single pin may be enough, hardware parallel FIFOs are good if you need some real throughput. On a chip with a hardware FIFO on the UART there's almost no overhead in sending some bytes. And you can exchange a single byte using SPI in no time at all with almost no cost to either CPU. And then there's dual-ported RAM memory-mapped into the address space of each processor.

Hi Rob, You've presented some interesting options there. 1. UART hardware FIFOs 2. SPI 3. Memory mapped dual-ported RAM.

At first glance, I would think that memory mapped RAM would be the fastest and most complex option. Do you have any suggested reading to learn more about it when it comes to AVRs?

SPI seems to be popular with Arduino and associated shields, so I should be able to read up on that easily.

UART hardware FIFOs would be similar to serial communication no? Any links you could suggest for me to learn more about this would also be appreciated.

Thanks in advanced!

I would think that memory mapped RAM would be the fastest and most complex option. Do you have any suggested reading to learn more about it when it comes to AVRs?

In general it’s probably not a good technique for AVRs as they don’t have the facility for external memory. The exception is the ATmega2560. It wouldn’t necessarily be complex as the DP RAM chips handle just about everything, but they tend to be expensive. An example is the CY7C144AV

http://octopart.com/partsearch#!?q=CY7C144AV

These would allow very fast inter-CPU comms, but it’s hard to imagine an AVR-based application that needed an interface that was much faster than the two processors involved.

Some UARTs have hardware FIFOs, AFAIK no AVRs do so you’d have to use an external one like the SC16IS740, it has a 64-byte FIFO so you could blat 64 bytes to that, trouble is it interfaces with SPI or I2C so you loose a lot of the advantages due to the serial interface.

Now if you were using a chip like an LPC it has a 16-byte internal FIFO for the UART and DMA to boot, so a 16-byte packet would be almost no overhead on the CPU at all.

If your protocol is just a single byte then you won’t do any better than SPI (on most AVRs, but with the 2560 you could memory-map an 8-bit register, that would be very fast).

And then there’s real FIFOs like the IDT2805, seriously fast and one-way so there’s no memory access contention issues.

And I have seen dual-ported serial SRAMS but don’t seem to have info on them. I did a DP design once using a standard SPI SRAM (see attached pic), this allowed an ATmega1284 and a LPC1227 to talk via the 23LCV1024 SRAM chip. (like most of my stuff it was never built :()

None of this is applicable to flashing a few LEDs in a string at low refresh rates though :slight_smile:


Rob

I once used two older Arduinos to drive enough relays (which controlled flourescent tubes in a huge 7-seg display) It wasnt the processing power I lacked though, but the CMOS BCD-7SEG decoder got freaked out by the lamps (no tubes, it toggled the relays just fine. With tubes ... random ) Owning to deadline and the fact that the Ardino could controll the relays (through driver transistor/diode) and remain unaffected but whatever noise came down the line (couldn't see anything on the scope) I just ran out of pins and another Arduino was on hand.

I just used the serial port between the two, simplex (meaning only one direction was wired). For ease of managing the uploads (as the program was simple) I used the same program in both Arduinos where one input pin held high/low decided if the particular Arduno was the master or slave. Somewhere in the Exhibition thread is the picture....

The others have made the point. Rather than split the job as controller/displayslave you might be better splitting halfdisplaywithcontroller/otherhalf. The more communication you need between the Arduinos, the more processing power it uses.

There are 2 boards with 32 bit processors from Microchip. Aside from the greater processing power of the 32 bit chips, these chips have a sort of master-slave DMA port on them. I really don't know anything about these boards, whether or not those ports are accessible, but if so, that would make for REALLY high-speed communication between boards. It's been quite some time since I read about these chips, but I think I2C and SPI may use a DMA too, if you're really interested in high speed communication, it might be worth looking into these.

Graynomad:

I would think that memory mapped RAM would be the fastest and most complex option. Do you have any suggested reading to learn more about it when it comes to AVRs?

In general it's probably not a good technique for AVRs as they don't have the facility for external memory. The exception is the ATmega2560.

And the ATmega64***** series, and the ATmega128***** series, and the better USB-AVR, and some other AVR's. I got a 512k card for my MEGA2560 for less than $30 shipped, Rugged Circuits still has them on sale.

One thing that Panici should do is look into standalone AVR's and use one as his co-processor and make it a 1284P. It's got 16K SRAM, is capable of addressing external RAM directly as internal RAM and cost $7. It has 3 serial ports that can run full speed SPI in master mode only, perfect for hanging dedicated SD cards on or for any highspeed data device. You can get near 1 megabyte/sec transfers in burst mode. Use the regular SPI for a network bus.

Besides stand-alones, IIRC Crossroads sells a board or kit to build a dual-1284P Arduino-compatible.

The absolute best page I have yet seen on programming breadboard Arduino's with ATmega1284P included: http://www.gammon.com.au/forum/?id=11637

Also if you want the processor without all those extra pins, cores for the 8 pin ATtiny45 and 85 are available and you can park them flush on a socket, 3 will fit on a 24-pin socket, 4 on a 32. The larger tiny85 only has 8K flash and 512 bytes RAM with 6 I/O pins if you disable reset and run on the internal clock. Perhaps a whole raft of them on an I2C bus?

And the ATmega64***** series, and the ATmega128***** series

I didn't think that was the case as the 1284 is IMO the best AVR around and I thought I was quite familiar with it.

I can find no mention of an external memory interface on the 1284/644 chips, except for this paragraph in the data sheet

12.3.1 Alternate Functions of Port A The Port A has an alternate function as the address low byte and data lines for the External Memory Interface.

Which is plain wrong, not supported by the following table of pin usage, and word for word the same as the 2560 datasheet, so I suspect it's a cut-and-paste job gone bad :)

It has 3 serial ports

2 last I looked, are we talking about the same chip?

That said I agree that the 1284 is a great processor, and 16k RAM is not to be sneezed at. I'm using them in a new system we're working on right now. It's just about the right mix of IO and memory which is why Freetonics called their new 1284-based board "Goldilocks".


Rob

Now I go back and look for the parts that had me thinking so, I can only find external memory docs in the 640/1280/1281/2560/2561 datasheet and that costs an extra cycle to perform. Those AVR's can.

There's also serial RAM that any AVR should be able to use.