Cluster of Microcontrollers?

Have questions about a SparkFun product or board? This is the place to be.

Moderators: phalanx, TS-Tim

Postby silic0re » Tue Jan 30, 2007 1:34 pm

Hi all,

I'm not sure if anyone's tried this before, but I thought I'd post it to see if the idea is sound. I'm not quite done wiring up the board yet, but I think I may have a way to program the PICs using only one ICD2 connector.

The general idea is this: Have the program, MCLR, and GND pins of each PIC connected together (and connected to the ICD2 header). Then connect the power pin on each chip to a series of switches, such that one can enable the power to all, none, or some subset (e.g. one) of the pics. The idea, hopefully, is that to program a given PIC one would just disable the power to each of the other PICs and hope that there isn't any interference on the program/MCLR lines from the unpowered PICs.

Any thoughts? It's almost wired up anyway, so I guess I'll know soon enough either way. :)
silic0re
 
Posts: 349
Joined: Wed Apr 26, 2006 5:35 pm

Postby jasonharper » Tue Jan 30, 2007 2:12 pm

That's not going to work - any signals on the PGC/PGD pins of an unpowered PIC are going to attempt to power it, via the protective diodes on those pins.

/MCLR is the pin you want to use for programming multiple PICs from one connector - have one PIC's /MCLR connected to the programming header, ground all the rest (so that those PICs cannot accidentally try to drive the shared PGC/PGD lines).
jasonharper
Support Volunteer
 
Posts: 845
Joined: Wed Mar 02, 2005 12:14 pm
Location: Oklahoma

Postby silic0re » Tue Jan 30, 2007 4:33 pm

Hmm, intuitively it seems like i'd have to have a double-throw switch per PIC that way (one side to ground, the other to MCLR) -- I wonder if there's a way to do it with just a single-poled switch?
silic0re
 
Posts: 349
Joined: Wed Apr 26, 2006 5:35 pm

Postby saipan59 » Tue Jan 30, 2007 6:35 pm

How about this:
Each MCLR is connected to a soft ground via a relatively large resistor (maybe in the 50K range?).
Each MCLR is also connected to the cathode of a diode. The anodes of all the diodes are connected together. That common-anode point goes to a single jumper, which then goes to +5V. When the jumper is in place, every PIC can run.

When you remove the jumper, all the PICs are in reset, because of the soft-ground resistors.
Now use a dual-row header to use a jumper (or use a DIP switch pack) to select which PIC's MCLR gets connected to the programmer. The diodes prevent the other PICs from seeing the programming voltage (or from coming out of reset).

Pete
saipan59
 
Posts: 228
Joined: Wed Nov 22, 2006 9:04 am
Location: Colo. Springs

Postby jasonharper » Tue Jan 30, 2007 6:43 pm

Well, you don't absolutely have to ground the other /MCLRs if you are certain that no PIC EVER sets PGD or PGC as an output...

I'd probably do this with a 2-row pin header: PIC /MCLRs on one side, other side all connected to the ICD2 /MCLR. Put a jumper at the location for the PIC you're currently working with.
jasonharper
Support Volunteer
 
Posts: 845
Joined: Wed Mar 02, 2005 12:14 pm
Location: Oklahoma

Postby rewguy » Mon Feb 05, 2007 12:30 am

I agree with Phiba. Most software is inherently single-threaded, and the overhead of making it multithreaded often outweighs the gain in parallelism. Plus communication between processing elements becomes a nightmare (i.e. clustred architectures). Still, this doesn't mean that this project isn't interesting.

Check out this:

http://instruct1.cit.cornell.edu//cours ... index.html

There's a lot of good info in his report about UMA and NUMA architectures and their differences.
rewguy
 
Posts: 20
Joined: Sun Mar 28, 2004 10:14 am

Postby silic0re » Mon Feb 05, 2007 3:28 pm

Hi rewguy,

While Philba's comment about the difficulty in parallelizing common tasks that are often single-threaded is true, that doesn't necessitate that there is no effective (or even easy) way to parallelize most tasks. Part of the challenge (and the fun) is to come up with different ways of approaching the problem, and different (potential) solutions.

That being said, there are of course a ton of problems that are inherently parallel, and when run on a system of N processors, approach a performance equal to (the time to execute on a single processor) over N. The problem of verifying the primality of a list of numbers (that I described earlier) is one of these class of problems.

It's very true that interprocessor communication can become very complicated when the number of processors becomes large. What's even more of a problem, if the overhead for the communications architecture isn't handled in hardware, then you have to eat up processor time to communicate. Thankfully for this simple project the PICs include hardware I²C, so the communication can be at least somewhat offloaded to hardware. That being said, I²C is just a simple bus topology, so there are of course some serious limitations when it comes to interprocessor communications compared to something like a grid, ring, tree, hypercube, or whatever. I'm hoping, for this first try, to keep things as simple as possible, and then to get into more creative topologies. :)

I remember finding that project -- it does look very interesting!
silic0re
 
Posts: 349
Joined: Wed Apr 26, 2006 5:35 pm

Postby Philba » Mon Feb 05, 2007 9:54 pm

I sure wish you were right but the fact that this kind of machine is no where near mainstream should be a pretty good indicator.

In general, part of the economic equation was that by the time a machine was built with a given processor, the next generation was rolling out. Single processor performance of the gen N+1 processor has been enough to make the parallel version of gen N uneconomical. Especially given the complexity of creating parallelized applications. If that isn't true, how come so many ventures folded? Look at Intel, they pulled the plug on their parallel supercomputer group. I know a number of people that worked in that industry - the sales just weren't there because the applications didn't exist and were incredibly expensive to build.

and to recap, I'm not talking about a multicore machine but one with a large number of parallel processors.
Philba
Support Volunteer
 
Posts: 2503
Joined: Sun Feb 13, 2005 11:33 pm
Location: Seattle

Postby silic0re » Sun Mar 04, 2007 11:03 am

update:
i will post pictures soon!
i'm having some small issues with the pic programmer and the SD card, but hopefully i'll have them both sorted out in short order.

silic0re
silic0re
 
Posts: 349
Joined: Wed Apr 26, 2006 5:35 pm

Consider the Propeller

Postby rokicki » Fri Mar 09, 2007 1:15 pm

The propeller chip has eight cores already built in, costs $12.95 for one (and there are quantity discounts, I think), comes with 32K RAM (and 32K ROM), executes at 20Mips each core for an aggregate of 160Mips, and can be arranged so each prop "programs" another so you can have a master prop do all the program loading if you want. It's available in a 40-pin DIP.

Each chip has 32 GPIOs that can be used to implement whatever sort of interprocessor communication you might want.

Of course there's no C compiler yet and that could be a showstopper for you.
rokicki
 
Posts: 11
Joined: Mon Dec 18, 2006 7:08 pm

Postby silic0re » Fri Mar 09, 2007 10:46 pm

hey rokicki,

that's a great idea -- thanks for pointing it out to me. it looks like the propellers have some neat things going for them, like 8 of them being on a single chip and their relatively high speed, but it also looks like there's a lack of math functions or solid documents for them. At least with dsPICs there's a great assortment of documentation and development/debugging software. That being said, it'd still be very interesting to get some benchmarks on a dsPIC versus a single propeller COG.

It's kind of funny, but my pic cluster board has space for 10 dsPICS, yet if one of the COGs is roughly equivalent to a dsPIC it would mean the propeller could replace virtually the entire board! :) But I suspect that this isn't the case, especially for the math functions. Any thoughts?

One of the nice things about the propeller architecture is that you could concievably devote one of the cogs to routing (somewhat like the connection machine, which had 16 single-bit processors and a router on a single chip). That might make things a lot cleaner and simpler when dealing with large numbers of processors... especially with the shared memory and the potential for one cog to serve a program for the others. Too bad the combined program/memory space for a single cog is only 512 x 32-bit! :(.
silic0re
 
Posts: 349
Joined: Wed Apr 26, 2006 5:35 pm

Postby new299 » Sun Mar 11, 2007 9:29 pm

I don't think PICs would give you much of a computational advantage over a PC. They are what? 16MHz? A PC is around 3000MHz? 6000Mhz of power dual core... So you'd need 375 PICs to perform the same number of operations as a PC in the same amount of time. That's before any communications bottlenecks it's simply the upper bound... (and you'd need more than 375 to get any connection machine style speedup)

There are other processors that fair better, the Blackfin by if I remember correctly analog devices is around 750Mhz and dual core, it could be really cool.

Another option is an ARM based system. Gumstix had some clusters of their PXA255 based system they were using to compile code a while ago...

Apart from the speed issue there is another advantage that using microcontrollers might give you, and that's lower power for equivalent processing power... might be especially interesting for companies like google for whom craming the maximum amount of power in to the smallest amount of space is a real issue.. and a problem that is limited by heat dissipation and therefore power consumption. I wrote up something on all this a while ago:

http://4g.soton.ac.uk/~new/green.html
new299
 
Posts: 2
Joined: Sat Sep 17, 2005 6:05 pm

Postby silic0re » Sun Mar 11, 2007 11:31 pm

just a quick update before bed -- i've whipped up this quick webpage for the cluster.

http://cogsci.mcmaster.ca/~peter/piccluster.html
silic0re
 
Posts: 349
Joined: Wed Apr 26, 2006 5:35 pm

Postby saipan59 » Mon Mar 12, 2007 6:48 am

I don't think PICs would give you much of a computational advantage over a PC. They are what? 16MHz?

I think nobody here believes that it would be 'faster', but it's still an interesting experiment. If the big MPU-makers thought that it was practical, they'd be all over it. This is also where I question the relevance of the Propeller (other than as a hobby/educational device) - why haven't Microchip, Atmel, Cirrus, etc., already made a multi-core MPU? Surely they could if they wanted to, unless there's a patent issue.

BTW, the PICs we're talking about here run at up to 120 Mhz (30 MIPS).

Pete
saipan59
 
Posts: 228
Joined: Wed Nov 22, 2006 9:04 am
Location: Colo. Springs

Postby saipan59 » Mon Mar 12, 2007 7:04 am

just a quick update before bed -- i've whipped up this quick webpage for the cluster.

http://cogsci.mcmaster.ca/~peter/piccluster.html

Very nice! Looks like good, clean construction (of course we can't see the rat's nest of wires on the bottom side of the board - just kidding!).

Maybe you should do a PC layout of your design, using surface-mount PICs. Each board could have say 9 or 16 PICs on it. Use a simple connector scheme to allow the boards to 'stack' (I did a project this way recently - ask me for details). The edges of the boards could have single-row or dual-row right-angle headers for I/O. Stack 3 or 4 boards to make a 'cube'. I'm not sure what you would use it for, but it would be Way Cool!
As an example, using ExpressPCB you could get 3 copies of your board for about $60 delivered.

Pete
saipan59
 
Posts: 228
Joined: Wed Nov 22, 2006 9:04 am
Location: Colo. Springs

PreviousNext

Return to SparkFun Product Questions

Who is online

Users browsing this forum: No registered users and 7 guests