Multiple Props
Mike Green
Posts: 23,101
I got a PM from someone who wants to use multiple Props and was wondering about using one Prop to furnish the clock for the others and whether this would offer any advantages in interProp communications. I don't have personal experience with this sort of setup, but others have tried it. Perhaps we could get an update from those that have tried it. My own thoughts:
1) The XIN and XOUT pins are really designed for use with a crystal or resonator (or an external oscillator with XIN). Any additional load on XOUT might keep the built-in oscillator from working. What others have done is to set up one of the cog counters to produce the desired clock and connect that to the other Props' XIN pins.
2) The thought was to try to synchronize the Props to speed up communications. I suspect it's possible using the WAITPNE/PEQ instructions and some careful negotiation between the Props to lock two cogs in different Props together.
1) The XIN and XOUT pins are really designed for use with a crystal or resonator (or an external oscillator with XIN). Any additional load on XOUT might keep the built-in oscillator from working. What others have done is to set up one of the cog counters to produce the desired clock and connect that to the other Props' XIN pins.
2) The thought was to try to synchronize the Props to speed up communications. I suspect it's possible using the WAITPNE/PEQ instructions and some careful negotiation between the Props to lock two cogs in different Props together.
Comments
Don't know if I missed the point on this thread. But for some time now I have two Props running; one has a 5 MHz crystal, uses FreqSynth to output a 5 MHz to the second Prop.
Presently am communicating between the two Props in Spin. Don't yet know of problems if assembly were used and any synch'ing problems which could exist.
Don't know how many Props could be driven via an I/O pin and distributed to the N-1 other Props. My setup was on solderless breadboard originally; now is on pcb with the two Props end to end, one Props EEPROM in between. So the 'clock' has just over a 3" trace. Scoping it, doesn't look too shabby.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
You do not "counter reset" or use any special sync signal with your inter-communications other than the primary using FreqSynth?
If you don't mind my asking, what kind of comm are you using (SPI,I2C,Parrallel,BitBang-Homegrown)?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
The question is what advantage "phase locking" will bring? Bootstrapping from a single EEPROM might be an interesting feature, hoping that the reset will behave absolutely deterministic. But I expect many more problems...
Deviation in Clock Speed might influence very strict synchronious protocols.
I DO NOT do any sort of synchronization. FullDuplexSerial is presently used to pass information between Props. At this time I forsee no need for assembly language code to communicate. The functions each Prop performs are only loosly associated; otherwise I'd of been in trouble as there are only a few unused I/Os on each Prop.
The RST/ lines are common and tied to a reset line from another board (which has a reset pb switch). Note: when one is programmed the other Prop is also reset; however, this does not pose a problem.
The main Prop also provides for TV out (to a b/w 5" monitor) for debugging purposes. Makes for a pretty usable arrangement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
I'm doing a project where I use 17 propellers in a parallel bus, one of them is the master, and the last 16 are slaves, I'm transfering data bytes from the master to the slaves at a data rate of 400Kbytes/sec, and it's working fine !!!
Some tips.
I used one 80MHz oscillator chip each four slaves, and I configure the "xinput" correctly for that.
I also used too much the WAITPNE/PEQ instructions, I did all the code in assembly.
I used three lines between the master and all slaves to sincronize them correctly.
And I used the same code for all slaves, except I change the "slave identification" variable in each slave code.
The data bytes were read form a SD card with the Rokicki code.
I will post some of that code, (in the thread where I began to ask about that), my problem now, is that I'm too busy to post it ...you know...I want to do a special version
of it for the forum people, and still I have not time to do it, because I'm trying to get finished that project. But I will ... be sure of that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
I forget to·post the thread name, where I began to ask about this.
It is: http://forums.parallax.com/showthread.php?p=639825
There are many pictures of the boards, and I will post more.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards.
Alberto.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E3 = Thought
http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! The average PC while browsing the internet typically uses less than 30% of it's potential, why not donate a portion of the rest for cancer resaerch?