Multi Processor Project, best/fastest way to data share?

Status
Not open for further replies.

BambooSam

Active member
Hey guys I am looking for project guidance...

My project is going to consist of 4 microprocessors purely for speed. 3 x MK20s and an atmege328 for communication (USB, Bluetooth, IR). Of course I would just use 1 much more powerful MC but the size of my pcb width cannot exceed the size of the MK20 LQFP-64s footprint.

One MK20 will act as the master mc, the other two MK20s will act as slaves which will be processing image data effects (fractals ect...) simultaneously, after a single frame has finished processing each slave MK20 will send the frame information to the master mc, which then the master mc will do additional processing with both frames.

The atmega328 will be taking care of all communication (USB, Bluetooth and IR) which will then process, notify and share with the master mc.

The slave MCs will be identical, they simply contain image generators that process the settings into frames.

To simplify it:

Screen shot 2014-04-07 at 4.25.43 PM.png


So I am looking for advice on how I should share the information between each device. I need the fastest possible way to transfer the data as extremely high fps will be demanding.

Thank you.
 
Last edited:
Setting aside many obvious questions about this project's goals... just answering about the types of communication, I'd say SPI is generally the fastest, but serial might give you the most desirable performance.

Three things are undesirable about SPI. First, it's easy to act as a master (generating the clock), but difficult to implement a slave. Second, implementations of SPI generally tie up the CPU while moving data, which will be at odds with your goal of maximizing computing capability. Third, the hardware imposes speed limitations on slave mode that put it roughly on par with the upper end of what ordinary Serial can do. SPI is only extremely fast when Teensy is the master and the slave is something like a dedicated display or W5200 ethernet chip designed to run in slave mode at 24 Mbit/sec speeds.

Teensy 3.1 can easily communicate at 1 Mbit/sec serial, and up to about 4 Mbit/sec is possible. Serial1 has the lowest overhead.

That's about the end of generic advice. You've not mentioned a LOT of details that are relevant, like the frame rate, data size per frame and other details of how much is communicated how often. Presumably you've got a good idea of the algorithm and it's CPU requirements?

One more piece of generic advice, however, involves efficiency. Often there's little to be gained by breaking a task up between several microcontrollers. Usually the overhead of managing communication and other stuff negates the gains from having multiple chips running in parallel. But who knows, maybe this project is an exception? I'll certainly be curious to hear as it develops, if you're able to share the technical details. And of course, I wouldn't want to dissuade you from buying many Teensy boards!
 
Last edited:
As far as a desired FPS, I have no set number. I just need it to be as fast as possible, then I will set a fps limit. The size of each frame is roughly (2000 bytes * 2), which is no match for T3.1

One more piece of generic advice, however, involves efficiency. Often there's little to be gained by breaking a task up between several microcontrollers. Usually the overhead of managing communication and other stuff negates the gains from having multiple chips running in parallel. But who knows, maybe this project is an exception? I'll certainly be curious to hear as it develops, if you're able to share the technical details. And of course, I wouldn't want to dissuade you from buying many Teensy boards!

That is what I am afraid of, although I only need to push 4000 byte at most each frame so I do have hope that there will be some gain. Plus when both "slave" mcs push their frames data out they will instantly start processing the next frame while the main mcu processes both frames (much simpler "Color Mixing") >> sends to led strip, reacts to atmega328 (if any), grabs the next frames from "slave" mcs...

And yes I would be buying many pre programmed mini54s from you. ((Hopefully you may be able to offer them in qfn packages in the near future ;) ))

Thank you, I will start experimenting with serial before I get into SPI.
 
Last edited:
Status
Not open for further replies.
Back
Top