Call me cautious, but I would be concerned about how reliably sharing a crystal would be over time. Connecting two devices seems Ok based on experience, but there is insufficient information for analysis. For crystal mode I have observed that having just the XI connected on the "clock-slaved" device is not sufficient for operation. So, it appears necessary for all XO's to be connected ... which is a big red quality flag. Setting the Propeller program to non-crystal mode and using a stand-alone clock would be much better.
Phil, the booter protocol adapts to the rate of the data-stream. Still, there is risk about it not working, but if someone is willing to test it ... well ok [noparse]:)[/noparse]
mctrivia said...
Search for my prop galore project schematic is there
Thanks Matt, do you happen to remember roughly what the schematic is called? - there's a boat load of them in them thar threads!
@Phil,
oops - I should have been more specific. Yes, I was thinking of only·the common clock, not one tx/rx, which does seem a tad gnarly. The external oscillator would be a pretty simple circuit, yes?
thanks
- H
[noparse][[/noparse]Edit - Steve... our posts crossed in the mail pipes... let me mull over what you said ... interesting]
On second thought I recently uploaded eagle pcb and schematic to 18 and under thread
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
jazzed said...
Phil, the booter protocol adapts to the rate of the data-stream. Still, there is risk about it not working, but if someone is willing to test it ... well ok [noparse]:)[/noparse]
This is something I've given a *lot* of thought to recently. There is possibly one gotcha.
After the ram load has occurred the prop does bit of setup, zeros the remaining ram, then does a complete checksum of ram before responding to the PC to say everything is ok.
If you have a prop running slowly and a prop running fast, *and* the fast prop happens to be the one that talks back to the PC, then the PC will stop sending $f9 bytes out and when the slower prop wants to respond with its OK, it will time out and try and boot the non existent eeprom.
This could be worked around by writing a loader that actually ignores the response coming back from the prop and pumps out $f9's for the worst case timing.
It's not very likely (as the props would need to be running at significantly different speeds) but it certainly is possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Steve: thanks for the diagram - just what is needed! All the other comments are very helpful and interesting. It looks like there are possibilities to having multiple props and loading the same program into each prop using a more simple method than brute force.
Jazzed you always come up with some of the most interesting stuff thanks for the schematic on the dual props but I have a question how would you program the props do run separate programs???
Looking at the schematic the proplug is shared by the prop chips so wouldn't they both be programed with the same code at the same time?? If I am wrong how would you program the second prop from this design Thanks man I have been dying to build a multi prop board for a while now and would love to know how it works
If the devices can both be loaded like this, then you can "add ID bit(s)."
What it means is on both propellers you choose a pin that your program will read decide what to do based on the pin state.
For example, if you choose pin 27, on one Propeller, you tie it to VSS, on the other Propeller, you tie it to 3.3V.
For a Propeller stack, you need to make sure these pins are not shorted [noparse]:)[/noparse]
The disadvantages to this are you lose a pin and you have to pack all Spin code for both Propellers into one binary.
I would rather use separate EEPROMs for each Propeller and a different configuration.
This would allow a spin program for each Propeller, and ID bits are not necessary (but I would still reserve some).
I would also connect pins P0..11 on each Propeller for a parallel bus ... much easier hardware than a "serial mesh."
Then you can start writing big and fast programs on propeller without adding external memory [noparse]:)[/noparse]
Other opportunities can emerge from this like an SD-CARD boot-loader, etc....
Except that it "may not" work for reasons cited in other posts above.
Good thing there's not a lot of investment in time, effort, or materials required.
There are better alternatives as discussed that will work, and work reliably.
Sorry, Steve. I didn't mean to impugn your post. But it looked like humanoido had taken the diagram at face value without considering the context of the surrounding discussion.
Jazzed thanks I should have mentioned I was more curious about running the props in a parallel configuration than I was at running them in a minimal configuration.
So taking your schematic I would add 2 crystals , 2 eeproms If I understand you ,, run the prop pins P0-P11 together but address the eproms separately so for sake of discussion connect one eprom to prop Pin 29-28 and the other eprom to prop 20-21 is this correct
I am not clear on why I would run the two props pins P0-P11 together?? Is this some way to address both props at the same time Thanks
Jazzed I don't know if I ever thanked for the Propalyzer I have it working on my Hydra with a Pod clip pack its awesome with the exception of the Pod pack you can not beat the price you should market it with your own prop board or at least get Parallax to do a sticky its quite incredible
mikediv said...
Jazzed thanks I should have mentioned I was more curious about running the props in a parallel configuration than I was at running them in a minimal configuration.
So taking your schematic I would add 2 crystals , 2 eeproms If I understand you ,, run the prop pins P0-P11 together but address the eproms separately so for sake of discussion connect one eprom to prop Pin 29-28 and the other eprom to prop 20-21 is this correct
I am not clear on why I would run the two props pins P0-P11 together?? Is this some way to address both props at the same time Thanks
@mikediv,
Make the circuits identical with one each EEPROM on each Propeller pins 28-29. This way you can program the Propellers differently. Use separate crystals as you mentioned ... which is a simple solution for clocking. And you can use full serial interface for programming/debug. Don't forget to use .1uf decoupling capacitors on both sides between power/gnd and a 10K pull up resistor on the RESn line. You could stack as many Propellers as your power-supply (or EEPROM programming patience) will allow. Many things are possible.
Soldering P0-P11 pins together can allow for fast communication between 2 or more propellers without a big mess of wires.
The P0-P11 pins can behave as a parallel bus with control and data. P0-7 will be data, P9 will be Read command, P10 will be Write command, P8 would be optional ready. In single master mode, the Primary (master) Propeller will drive P11 (write-only) and Secondary(s) will monitor P11 (read-only), and P8 would be monitored by by the Primary (read-only) and driven by the responding Secondary while in a wait-state. A marginally faster configuration would use P24-27 for signalling instead of P8-P11 since a long can be written more quickly like that from the Primary. An "any master" bus is also possible, but I don't have details for that now.
Thanks for the nice words on Propalyzer. I'm glad you are getting value from it. It is listed in the "Propeller: Getting Started and Key Thread Index" sticky.
Phil said...
Sorry, Steve. I didn't mean to impugn your post. But it looked like humanoido had taken the diagram at face value without considering the context of the surrounding discussion.
I was simply looking for a diagram with a working circuit that I could build. I only see Steve's circuit which he took time to create and it was greatly appreciated, suggesting that it could work to a limited extent, which I fully understand. If anyone has another simple circuit to connect "n" props together, that works better, lets see it please!
humanoido,
Not sure what kind of success you had with the other drawing. I'm actively working on a similar design now, but I've changed the clock to use a 74LVT00 for driving multiple secondary Propellers. The attached drawing shows 8 Propellers, I'm using 5 now for software development (will add 3 more soon after I have some communication code working). The multiple RX connected download is working fine so far. Oops, I forgot: there is a 0.2uf capacitor on the clock-source Propeller/74LVT00. Some day I'll add an EEPROM.
jazzed: thanks for this design! I'm having fun exploring all the circuit options
provided in this thread and your design is really significant and I'm interested
in building one. It provides many good ideas for multiple prop versions.
An OctoProp fits the succession of larger propeller chip aggregates and the
minimal circuit is appreciated!
humanoido: I've been writing code for this, and have found that the serial download is unreliable - Phil and BradC explained why. I'll be daisy-chaining the reset and download interface maybe tomorrow. The main disadvantage of this is that bootup will be slower. The advantages are I can tell the device it's ID number so pins can be saved, and a secondary channel is available for lower speed asynchronous event management. I've been using the RWN pin for debug only, so it has no functional use at this time, but it could become the ACK pin. I'll post a new schematic with these changes tomorrow.
I would use a crystal oscillator and then buffer with a the schmidt inverters of 74LVC14. That way all props will receive identical clocks and the loading will be minimal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Synchronized clock would be more reliably produced since it would not depend on the timing of the inverter which would be about 4ns max propagation delay for 74LVT00 ... I would certainly not use a 74HC00. The only reason I chose a NAND gate is that's all I got in a fast low voltage inverter.
humanoido, Here is the Parallel/Serial version. PropID0 loads PropID1 which loads PropID2, etc...
As mentioned before loading will be slower, but should be reliable once software works (I wrote a C Propeller boot-loader recently, so it should be easy).
One might ask why serial and parallel? In addition to downloads, serial data is is used for back-door console commands (user and/or redundant link) and asynchronous event notification for task completion score-cards, interrupt queuing, etc... This makes it possible to use all cogs at once to work on one or more given problem(s). Parallel data is used for higher performance burst transfers.
I'll modify my 40 COG prototype tomorrow and add 3 more Propellers if everything goes according to plan.
jazzed said...
humanoido, Here is the Parallel/Serial version. PropID0 loads PropID1 which loads PropID2, etc...
If you look at the propeller loader object, the text says this:
Chip Gracey said...
This object drives the other Propeller's RESn line, so it is recommended that
the other Propeller's BOEn pin be tied high and that its RESn pin be pulled
to VSS with a 1M resistor to keep it on ice until showtime.
Steve, using and oscillator to feed a set of 6 inverters (schmidt's all from the same package) will render almost identical delays and thus each set of props will be fed almost identical clocks. Your circuit actually has a delay between the first and all other props.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso said...
Steve, using and oscillator to feed a set of 6 inverters (schmidt's
all from the same package) will render almost identical delays
and thus each set of props will be fed almost identical clocks.
Your circuit actually has a delay between the first and all other
props.
What total length of delay are we talking about? Is it significant?
I have 5 Propellers booted using a slightly modified PropellerLoader.spin with the last schematic presented, but oh what a P.I.T.A. to build and load! The main image has to carry several device images embedded. Need another loader approach. At this point, one of the EEPROM connection schemes looks attractive ... no way I'll use a serial mesh. The least hardware would be to keep the reset methodology and tie all Propellers to the EEPROM. Guess I'll try that tomorrow.
jazzed said...
The main image has to carry several device images embedded. Need another loader approach. At this point, one of the EEPROM connection schemes looks attractive The least hardware would be to keep the reset methodology and tie all Propellers to the EEPROM.
So have a single propeller start loading from the eeprom first, and then turn the props resets off in succession.
I saw someone mentioned the Nth propeller. I made a post about that a bit back.
The biggest difference between what is discussed here, is the circuit I drew up uses:
A different clock locking method.
The way it goes about this is a single prop loads from the eeprom and has a crystal attached to ONLY IT.
Then that "master prop" programs and clocks and talks to the next prop. To the Nth.
But like mentioned here the embedded program is a pain.
I noticed the idea of using a logic IC as a clock was discussed.
But I don't think any one mentioned using one prop to clock the next.
Sync as far as clocks can be maintained by just communication,
or if your really picky, you just feed back a clock, and count.
A "clock loop".
The prop needs 5mhz, can make 5mhz, and can READ 5mhz. And COUNT 5mhz.
The prop can just count its own generation of 5mhz to keep track of your program in relation to its slave, and vice versa.
There is probably a million ways to clock lock props.
humanoido: The delay is from the xtal to the output of the inverter (i.e. the inverter delay). This can be deterimined from the datasheet of the inverter being used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The purpose of having exactly the same clock or clock in sync for all Propellers would be for using high-speed serial 14MB/s + links between Propellers. While this is a good option for optimizing the number of propeller pins available and allowing very flexible communications between propellers especially in a serial mesh, it is not the fastest performance or most mechanically convenient design possible. Using a clock from one Propeller to another is interesting, but for me it's another wasted pin. The multi-propeller discussion has been going a very long time [noparse]:)[/noparse] This is the first time I've had time to actually work on it though.
Just an update. I have 5 Propellers booted and running "Host/Device" 8-bit bus data transfers. I changed the boot method from "Chained Serial Download" to "Common I2C EEPROM". The schematic is simpler for booting than the chained serial schematic.
All Propellers boot from one EEPROM one Propeller at a time. This makes software development and testing considerably easier. Each Propeller pin 8 is connected to the next Propeller reset pin (BOEn is tied high). The Host Propeller launches an I2C device handler in a COG for each Device Propeller to query for it's slot assignment (all PASM code for now). The Host Propeller knows it's the first one booted because the I2C can respond with 0 or $ff since there is no device running at the device address to respond.
At some point the I2C could be put into mult-master mode, but it will be difficult. Without multi-master I2C, the asynchronous out-of-band communications notification mechanism would be impossible. This is an area of study and is possible according to Phillips research, but I'm burned out on it right now [noparse]:)[/noparse]
Parallel data on the bus is running at about 20Mbits per second now without optimization (using hub operations and currently limited to 256 bytes per transfer). I'm using the ACK to throttle the data right now. I think throttling can be eliminated, and that would allow a higher data-rate. Regardless of how fast the bus can go however, there is only one bus, so the aggregate throughput would be fixed at the bus rate. Increasing the parallel bus data transfer rate is next on my agenda.
@Cluso99, I'm curious. How many clock-slaved high speed serial links you can run at once?
jazzed said...
Just an update. I have 5 Propellers booted and running "Host/Device" 8-bit bus data transfers. I changed the boot method from "Chained Serial Download" to "Common I2C EEPROM". The schematic is simpler for booting than the chained serial schematic.
All Propellers boot from one EEPROM one Propeller at a time. This makes software development and testing considerably easier. Each Propeller pin 8 is connected to the next Propeller reset pin (BOEn is tied high). The Host Propeller launches an I2C device handler in a COG for each Device Propeller to query for it's slot assignment (all PASM code for now). The Host Propeller knows it's the first one booted because the I2C can respond with 0 or $ff since there is no device running at the device address to respond.
Excellent work! Which schematic shows the update? Where is the posted software to drive it? A test program would be nice.
Comments
Phil, the booter protocol adapts to the rate of the data-stream. Still, there is risk about it not working, but if someone is willing to test it ... well ok [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 8/11/2009 7:20:19 PM GMT
Thanks Matt, do you happen to remember roughly what the schematic is called? - there's a boat load of them in them thar threads!
@Phil,
oops - I should have been more specific. Yes, I was thinking of only·the common clock, not one tx/rx, which does seem a tad gnarly. The external oscillator would be a pretty simple circuit, yes?
thanks
- H
[noparse][[/noparse]Edit - Steve... our posts crossed in the mail pipes... let me mull over what you said ... interesting]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
On second thought I recently uploaded eagle pcb and schematic to 18 and under thread
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
This is something I've given a *lot* of thought to recently. There is possibly one gotcha.
After the ram load has occurred the prop does bit of setup, zeros the remaining ram, then does a complete checksum of ram before responding to the PC to say everything is ok.
If you have a prop running slowly and a prop running fast, *and* the fast prop happens to be the one that talks back to the PC, then the PC will stop sending $f9 bytes out and when the slower prop wants to respond with its OK, it will time out and try and boot the non existent eeprom.
This could be worked around by writing a loader that actually ignores the response coming back from the prop and pumps out $f9's for the worst case timing.
It's not very likely (as the props would need to be running at significantly different speeds) but it certainly is possible.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Looking at the schematic the proplug is shared by the prop chips so wouldn't they both be programed with the same code at the same time?? If I am wrong how would you program the second prop from this design Thanks man I have been dying to build a multi prop board for a while now and would love to know how it works
If the devices can both be loaded like this, then you can "add ID bit(s)."
What it means is on both propellers you choose a pin that your program will read decide what to do based on the pin state.
For example, if you choose pin 27, on one Propeller, you tie it to VSS, on the other Propeller, you tie it to 3.3V.
For a Propeller stack, you need to make sure these pins are not shorted [noparse]:)[/noparse]
The disadvantages to this are you lose a pin and you have to pack all Spin code for both Propellers into one binary.
I would rather use separate EEPROMs for each Propeller and a different configuration.
This would allow a spin program for each Propeller, and ID bits are not necessary (but I would still reserve some).
I would also connect pins P0..11 on each Propeller for a parallel bus ... much easier hardware than a "serial mesh."
Then you can start writing big and fast programs on propeller without adding external memory [noparse]:)[/noparse]
Other opportunities can emerge from this like an SD-CARD boot-loader, etc....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 8/12/2009 4:41:29 PM GMT
1. You can't reliably share a crystal.
2. The loader protocol may prevent (or make it difficult to) load several Props simultaneously.
-Phil
Good thing there's not a lot of investment in time, effort, or materials required.
There are better alternatives as discussed that will work, and work reliably.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
So taking your schematic I would add 2 crystals , 2 eeproms If I understand you ,, run the prop pins P0-P11 together but address the eproms separately so for sake of discussion connect one eprom to prop Pin 29-28 and the other eprom to prop 20-21 is this correct
I am not clear on why I would run the two props pins P0-P11 together?? Is this some way to address both props at the same time Thanks
Jazzed I don't know if I ever thanked for the Propalyzer I have it working on my Hydra with a Pod clip pack its awesome with the exception of the Pod pack you can not beat the price you should market it with your own prop board or at least get Parallax to do a sticky its quite incredible
Make the circuits identical with one each EEPROM on each Propeller pins 28-29. This way you can program the Propellers differently. Use separate crystals as you mentioned ... which is a simple solution for clocking. And you can use full serial interface for programming/debug. Don't forget to use .1uf decoupling capacitors on both sides between power/gnd and a 10K pull up resistor on the RESn line. You could stack as many Propellers as your power-supply (or EEPROM programming patience) will allow. Many things are possible.
Soldering P0-P11 pins together can allow for fast communication between 2 or more propellers without a big mess of wires.
The P0-P11 pins can behave as a parallel bus with control and data. P0-7 will be data, P9 will be Read command, P10 will be Write command, P8 would be optional ready. In single master mode, the Primary (master) Propeller will drive P11 (write-only) and Secondary(s) will monitor P11 (read-only), and P8 would be monitored by by the Primary (read-only) and driven by the responding Secondary while in a wait-state. A marginally faster configuration would use P24-27 for signalling instead of P8-P11 since a long can be written more quickly like that from the Primary. An "any master" bus is also possible, but I don't have details for that now.
Thanks for the nice words on Propalyzer. I'm glad you are getting value from it. It is listed in the "Propeller: Getting Started and Key Thread Index" sticky.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I was simply looking for a diagram with a working circuit that I could build. I only see Steve's circuit which he took time to create and it was greatly appreciated, suggesting that it could work to a limited extent, which I fully understand. If anyone has another simple circuit to connect "n" props together, that works better, lets see it please!
Not sure what kind of success you had with the other drawing. I'm actively working on a similar design now, but I've changed the clock to use a 74LVT00 for driving multiple secondary Propellers. The attached drawing shows 8 Propellers, I'm using 5 now for software development (will add 3 more soon after I have some communication code working). The multiple RX connected download is working fine so far. Oops, I forgot: there is a 0.2uf capacitor on the clock-source Propeller/74LVT00. Some day I'll add an EEPROM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 8/30/2009 8:40:32 PM GMTprovided in this thread and your design is really significant and I'm interested
in building one. It provides many good ideas for multiple prop versions.
An OctoProp fits the succession of larger propeller chip aggregates and the
minimal circuit is appreciated!
humanoido
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 9/2/2009 6:01:41 AM GMTAs mentioned before loading will be slower, but should be reliable once software works (I wrote a C Propeller boot-loader recently, so it should be easy).
One might ask why serial and parallel? In addition to downloads, serial data is is used for back-door console commands (user and/or redundant link) and asynchronous event notification for task completion score-cards, interrupt queuing, etc... This makes it possible to use all cogs at once to work on one or more given problem(s). Parallel data is used for higher performance burst transfers.
I'll modify my 40 COG prototype tomorrow and add 3 more Propellers if everything goes according to plan.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
If you look at the propeller loader object, the text says this:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
So have a single propeller start loading from the eeprom first, and then turn the props resets off in succession.
I saw someone mentioned the Nth propeller. I made a post about that a bit back.
http://forums.parallax.com/showthread.php?p=835453
The biggest difference between what is discussed here, is the circuit I drew up uses:
A different clock locking method.
The way it goes about this is a single prop loads from the eeprom and has a crystal attached to ONLY IT.
Then that "master prop" programs and clocks and talks to the next prop. To the Nth.
But like mentioned here the embedded program is a pain.
I noticed the idea of using a logic IC as a clock was discussed.
But I don't think any one mentioned using one prop to clock the next.
Sync as far as clocks can be maintained by just communication,
or if your really picky, you just feed back a clock, and count.
A "clock loop".
The prop needs 5mhz, can make 5mhz, and can READ 5mhz. And COUNT 5mhz.
The prop can just count its own generation of 5mhz to keep track of your program in relation to its slave, and vice versa.
There is probably a million ways to clock lock props.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
All Propellers boot from one EEPROM one Propeller at a time. This makes software development and testing considerably easier. Each Propeller pin 8 is connected to the next Propeller reset pin (BOEn is tied high). The Host Propeller launches an I2C device handler in a COG for each Device Propeller to query for it's slot assignment (all PASM code for now). The Host Propeller knows it's the first one booted because the I2C can respond with 0 or $ff since there is no device running at the device address to respond.
At some point the I2C could be put into mult-master mode, but it will be difficult. Without multi-master I2C, the asynchronous out-of-band communications notification mechanism would be impossible. This is an area of study and is possible according to Phillips research, but I'm burned out on it right now [noparse]:)[/noparse]
Parallel data on the bus is running at about 20Mbits per second now without optimization (using hub operations and currently limited to 256 bytes per transfer). I'm using the ACK to throttle the data right now. I think throttling can be eliminated, and that would allow a higher data-rate. Regardless of how fast the bus can go however, there is only one bus, so the aggregate throughput would be fixed at the bus rate. Increasing the parallel bus data transfer rate is next on my agenda.
@Cluso99, I'm curious. How many clock-slaved high speed serial links you can run at once?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
humanoido