Networking Props

Philldapill

Lately, I've been thinking about many different uses for multiple props in one application. I'm not sure how much conversation there has been about networking propellers together so they can talk. 8 cogs is great, but if you have MANY tasks going on at the same time, which require a cog each, why not use 6 cogs per propeller·to do those tasks, and then have 1 cog completely dedicated to recieving, and 1 cog dedicated to sending information. I can think of many applications where I think this would be beneficial, but the cost might offest the benefit. All this would be multiple propellers, btw.

On the subject of networking props, if this is possible, I'm sure there are some applications where you would have propellers running at the same time with the same program. I don't have that much experience with higher level stuff like this, but I've thought about possibly having a single EEPROM for propeller "clones" that would all be connected on the same dataline(pins 31/30). What I had in mind, was the having all the propellers initially off, then when power is applied, the first propeller turns on and downloads the program from the eeprom. Once the program is downloaded, one of the first instructions is to turn on·a transistor (or mosfet or whatever), which would supply power to the next propller. The next would boot up, and apply power to the next, and so on. Once all propellers are on, their programs begin running and "listening" on the data lines that the 2 cogs are devoted to.

Again, this is just an idea. There may be a much more cost effective way of doing all this, but I just love the huge processing power of the propeller and get excited thinking about multiplying that power even further.

Any input, good or bad, welcome.

hippy

Theory not practice yet, but I worked out two ProtoBoards could stack on top of each other and share all lines except XI, XO, P28-P31, and just three links from bottom I/O to top RST, P30, P31 and it's an easy to use (*) dual-Propeller system. Ideally add 100R or so resistors on all the I/O. I don't see any reason they couldn't be stacked higher than two.

(*) Well apart for actually "using it", where coding gets a bit tricky

stevenmess2004

Depending on exactly you want to do there are many schemes you can use. You could use TWI which would allow upto 127 devices, SPI, UART, some form of parallel bus system and about a million possibilities. There was an object posted for high speed serial comms between propellers (around 10-12MB/s I think) by one of the Pauls a while ago but I don't have the link to it. I believe that at least one person has experiment with stacking DIP propellers on top of each other but again I don't have the thread or the results.

The real problem you will have is the software to keep everything in sync.

Philldapill

Nice! I've refined my thinking a little bit and here's what I've come up with.

I would have 1 master propeller that has all available I/O connected to other propellers. I figure the way I would send data would require only 2 I/O for each "slave" propeller connected to the master. I'm not computer science expert by any means, but I think this may be feasible. These 2 I/O lines between the master and slave would function like this:

I/O-A - This would be the "enable" line. Initially, both master and slave would have their pins set as inputs and would "listen" for a transition from low to high. When one cog needs to send some data to the other, the sender would set this line to an ouput and set it high. This would be the start of the data transmission. When this happens, the receiving propeller would hold it's I/O-A as an input until the sending propeller switched it's I/O-A back low(back to input).

I/O-B - When the transition happens on I/O-A, the receiving propeller would begin watching the on/off time on it's I/O-B. I've played around with the IR remote control stuff and it seems that's how it works in a way. Since a remote control only has one "data line", the IR LED, the reciever has to demodulate the signal by watching the times of on and off. The on time remains the same, but the bit received depends on how long between on times. This is how I would send data. This way, I can have two way communication(not at the same time), and only use 2 I/O pins on each propeller. I'm sure this method is pretty slow, but remember, the other cogs are busy doing their own thing... all 49 of them!(7 cogs each propeller for whatever -A/D, processing, etc., and the remaining cog for data transfer * 7 cogs connected to one master propeller = 49 cogs)

Philldapill

Oh one other thing, could the Master propeller possibly output a clock signal that is fed to all slaves? Would this help keep things physically in sync and prevent anything going screwy by the possibility of switching to outputs at the same time? Excuse this if it doesn't make much sense - it's 2am.

stevenmess2004

Last question first, the Master propeller could output a clock to all the other propellers but I don't know how well you could get them synced because you would have to use the PLL (They would be synced but may be out of phase).

Your idea sounds kind of like TWI (I2C).

Some things to consider.
1. Do you want all the props to be able to communicate to each other (peer network) or only to the master (master-slave network)
2. How many cogs do you want to dedicate to communication and what speed do you want?
3. Do you want point to point (more wires but faster) or a bus system (less wires but slower)

Have you seen this thread http://forums.parallax.com/showthread.php?p=639825? It shows some pretty cool stuff using a bunch of propellers.

hinv

The big limitation for a lot of applications for the prop is memory, as far as I see it. If, for instance you had 4 processors in a mesh network so that using 3 links, you could hit the other pops without making more than 1 hop, you would have 128KB available total, minus some overhead. If you could have a link between props that was as fast as hub access, you could use another props memory as if it were local. A table would be needed to say what page (say 256longs) would be used by what propeller&cog, and a server process sitting on one of the cogs of each prop, (written in assembly, of course). The access table would have to be distributed to each prop and kept in sync also which adds overhead, but that could be kept to a minimum. It would be kinda like a mini ccNUMA. Since we are going for Non Uniform, the memory server could serve locally attached sram, or ferroram, Extreme 512k Card, etc, Kinda like an extended LMM
Come to think of it, you could use the same principal for sdcard and other memory mapped peripheral access.
from the extra long Prop II discussion, http://forums.parallax.com/forums/default.aspx?f=25&p=022&m=156993, 6MB/Sec is about the fastest anybody has gotten hub memory access, so the link would have to be a bit above that so that link bandwidth isn't an issue. Latency may be, however.
There was a serial link that got really good speed just a couple of months ago, posted by Beau, or Paul Baker, but I can't seem to find it.

Just my ramblings.

Doug

stevenmess2004

The fastest possible hub access is 80MHz/16*32bits/8=about 20MB/s. It would be possible like this

loop
rdlong outA,hubAddr
add hubAddr,#4
jmp #loop
long hubAddr

Now this has a couple of problems (it will go on forever and it uses every output pin) but if we add another variable and used djnz than it would be possible to do about 20MB/s burst speed.

But what about a serial output? Well, the video units can be used to send out data. If we run them at 128MHz than we could get 128/8=about 16MB/s. You would need some code something like this

loop
rdlong temp,hubAddr
waitvid 
add hubAddr,#4
jmp #loop

However, this has required an extra instruction so we will miss the hub access and your bandwidth will be half of before or about 10MB/s. Now, since you aren't using all the pins you can run this in two cogs and get twice the throughput

I have personally done two 8 bit outputs (to a dac) at about 2MHz giving about 4MB/s and that was pretty easy.

Harley

I'm using just two Props on a pcb. Master generates 5 MHz 'clock' for slave for 5*16PLL=80 MHz clock.

FullDuplexSerial is used for comm both ways, as operations are basically related to keypad inputs. Not the fastest comm between Props but works for this application.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko

hippy

@ stevenmess2004 : Phil Pilgrim (PhiPi) came up with an ingenious mechanism to boost hub access throughput for LMM by executing in reverse and avoiding missing those hub access sweet spots ...

http://forums.parallax.com/showthread.php?p=701330

stevenmess2004

So if we use Phl's idea we end up with this

_xeq1         waitvid
              rdlong    temp,pc
              sub       pc,#7
_xeq0         waitvid
_go           rdlong    temp,pc
              djnz      pc,#_xeq1

This gets us back to 20MB/s from the hub. Now, I think it is safe to run the PLLs at 160MHz which means 20MB/s out of them.

One problem is that you can't generate a clock signal fast enough and how on earth are you going to recieve something that fast as the propeller can only record inputs at 80MHz even if you use 4 cogs.

hinv

What is the fastest link between two props anyone has actually achived?

I found the forum discusion that I was looking for about a serial link between props getting around 14Mbit/Sec
http://forums.parallax.com/showthread.php?p=691952.

Supposedly this can be done at 29Mbit/sec with 4 wires. Obviously, the more lines you throw at it, the more bandwidth you can achieve, to a point. I would be curious of what someone actually has achived. Hopefully, it is possible to outrun hub bandwidth on a 10-bit or so bus.
The good thing about using more than 1 prop is that you get lots of pins, unless of course you use a bus that is really wide.

Anybody know where the PropGFX bus is specified or how much bandwidth they got out of it?

Take Care,
Doug

Baggers

Hi hinv, PropGFX bus isn't specified, as I've made the specs myself, it also handshakes, so can be ANY speed up to ~2MBytes/second, I could have made it a burst mode, like the 14Mbit/Sec one, but using the 8bit bus, but it would have to be locked, and a prop sending it, this way it can be anything connected to it. [noparse]:)[/noparse] could even be a slow 8pin P*C chip in RC mode, and serial shifting to fill the data bus lol. not that you wouldn't just use the serial mode instead for that chip. lol

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

hinv

Hey Baggers, Thanks for the answer, but I would have suspected way more than 2MBytes/second as there are some who have sent that(or in that range) up to a pc via prop-plug for things like propmonitor, etc. I would have guessed an order of magnitude higher rate.
Have you actually benchmarked it?

stevenmess2004, I see what you are saying about the 160MHz limitation, but the assumption is using serial on a single line. With parallel, transfer rates could be much faster.

stevenmess2004

So we could do 20MHz instructions by 32bits or 4 bytes=160MB/s but only for a very short time. If you want to use serial and all the cogs than you would have 8*20=160MB/s but they won't be synced.

Does anyone think it would be possible to use firewire100? The clock for this is around 98 or 99 MHz I think. If you used the mode where you just send or receive a certain amount of data every period than it may be possible. Possibly a form of DV? or is this just a dream