Anyone that wants more data up the USB serial pipe: Dual FTDI Parallel Props (hanno!)
Clock Loop
Posts: 2,069
This schematic works. It will program both props, and both props will run from the single crystal.
The program that you use should assign each prop with a unique ID, to assign specific data function.
Also align both props internal programs.
example: my "up steam engine big boy" program and thread
http://forums.parallax.com/showthread.php?t=124343
For example one prop could be used to capture the audio and store it to ram, and upload through com port 1
The other could capture video stills store it to ram, and upload through com port 2
Both would have a full FTDI serial pipe to get data back to your program via TWO serial ports.
Technically this would work for X number of props with X number of serial conduits.
I would like to bring this to hanno's attention with viewport.
I suggest that this circuit could be used to double the data rate flowing into viewport?
The circuit was tested and both props will run wired like this.
I would suggest even using the second prop as a checksum/parity or something.
The props could be stacked directly, legs soldered to eachother, if your darn sure your program is correct. Personally I would make an array of 1k resistors between each leg.
I didn't put that on the schematic, but this would let you latch and upstream data from single sources using two props RAM space, not just one.
There is a DualCom with EEPROMs schematic attached also.
The program that you use should assign each prop with a unique ID, to assign specific data function.
Also align both props internal programs.
example: my "up steam engine big boy" program and thread
http://forums.parallax.com/showthread.php?t=124343
For example one prop could be used to capture the audio and store it to ram, and upload through com port 1
The other could capture video stills store it to ram, and upload through com port 2
Both would have a full FTDI serial pipe to get data back to your program via TWO serial ports.
Technically this would work for X number of props with X number of serial conduits.
I would like to bring this to hanno's attention with viewport.
I suggest that this circuit could be used to double the data rate flowing into viewport?
The circuit was tested and both props will run wired like this.
I would suggest even using the second prop as a checksum/parity or something.
The props could be stacked directly, legs soldered to eachother, if your darn sure your program is correct. Personally I would make an array of 1k resistors between each leg.
I didn't put that on the schematic, but this would let you latch and upstream data from single sources using two props RAM space, not just one.
There is a DualCom with EEPROMs schematic attached also.
Comments
Clockloop: You really should qualify your use of the xtal for both props as I think you could cause problems here. The loading to the second prop and the length of the track is liable to cause problems. If you want to use a single xtal (and not an oscillator) then there is a special part like the 74LVC1GX04
I understand its not good practice. I am just saying that two props on a single crystal has worked for me so far many times on a breadboard lol.
I have a dual port ftdi chip connected to two props running on a single crystal, running the same program. The exact circuit I ran was the first one without eeproms. I can run with dual eeproms if anyone thinks its worth it.
I have no idea how out of sync my program was, which is up to the programmer, but my program ran immediately on both props.
If I had a scope my posts would show shots.
Doing pcb work makes designs work even better.
Get your chips centered on the crystal, keep it all symmetrical.
And using better parts like your suggested one.
With my circuit, a single copy of prop tool would be used to do the design/programming.
(but the programmer would need to remember HOW the props will run the code, depending on how you go about identifying each prop, either using pins tied high, or randomly generated internal id)
I didn't notice this before.
The way that the Prop starts off using RCFast and then moves onto the PLL on the xtal leaves this trick doomed or at least a race hazard as to which one gets to switching clock sources first.
IMHO.
Only one prop is allowed to "pulse" the crystal, notice the schematic connections. Also both props use the same reset.
On AVRs this is a fuse setting that actions straight from reset and sometimes this trick can be got away with.
The slave would shut down, due to the program being told that it has a 5mhz external crystal on it. When the prop finds that nothing responds, the prop shuts down. Right?
(RCFAST only continues to operate if the internal program says to do that, but if you tell the prop that it has an external crystal, it won't just switch to the internal crystal in the case that the external one doesn't work, if that were the case, it would introduce a problem for everyone who runs an external crystal. Its better that the prop shuts down in the event of a failed crystal, instead of running at RCFAST, a speed the programmer never planned on)
Worst case scenario, the slave prop shuts down, and the primary prop runs.
This is up to the programmer to prevent, using communication. One could let the primary prop access to the reset, in this case, resetting both props, much like a car that didn't start the first time you try to start it, try again. But I haven't had this happen to me yet.
I understand what your saying, but I found that using props like this works due to all scenarios being solved from smart programming and smart circuit design.
I only wanted to get people to see that its possible for props to be used fairly easily, fairly reliably like this. My tests show consistent results, suggesting that "gotachs" like this can be solved with creative program and circuit design.
Its up to you to program and design for all possible scenarios.
But considering most of us design hobby applications, most of the fun in life is figuring out ways to bend the un-bendable.
This was where I found the problem with the commoned xtal, if the "Blade2" which had the xtal was reset then the PropCMD Prop was left stranded without its 5MHz feed. When the xtal osc (Blade2) was restarted the PropCMD Prop couldn't just pick up from where it left off, and required a reset too. One commoned reset switch, or power cycling the board seemed ok everytime.
I just accepted it and put on the second xtal. If syncronicity between the Props were demanded the I think that a external osc block would be better
Running a crystal signal "off pcb" using long wires, is a bad idea also, this in its self will introduce unacceptable clock propagation delay.
I absolutely agree that this use of a single crystal has limitations, like mandatory joined resets(or a master clocking prop), clock pcb trace length/routing restrictions, program "gotchas" etc...
If you want dual prop redundancy like your setup seemed to try to do (keeping the other prop running even if one of them dropped) then most definitely one would need a non-prop run clock source.
A clock source "stall" like this, has limits on how long the clock can "stall"
I do not know the maximum length the prop's clock can be dropped before the prop will loose its recovery ability, but I bet one could characterize this on a graph, using length of stall over programmed clock speed.
If I had a scope I would have already figured this relationship out, due to a previous project doing odd things(very bad things) with the props clock input..
(like PWM, ...lolz)
The two Props were right next to each other on the same board, the 5MHz track was only 3-4cm long.
Seems you picked a very fitting nickname!
Thanks for letting me know about this approach to increase communication rate between prop and pc. Now someone has to come up with a valid use for such speed. I'm currently very happy with conduit's performance to quickly update PropScope's display in real time, support breakpoint/step line by line in ViewPort, and support live edits to running programs in 12Blocks.
I am looking forward to Propeller 2 specifically it's larger ram, ability to add ram and possibility to directly support USB- with it's higher throughput....
Hanno