Shop OBEX P1 Docs P2 Docs Learn Events
Parallax Propeller Programs Propellers in ParallelV1.0- Tribute to the BigBoy 4 — Parallax Forums

Parallax Propeller Programs Propellers in ParallelV1.0- Tribute to the BigBoy 4

Clock LoopClock Loop Posts: 2,069
edited 2010-12-16 04:48 in Propeller 1
The bottom post has V1.0 Schematic and Program.
I made a program and schematic that shows a single propeller that can program 2 or more propeller chips at the same time on the same RX, TX, RESET, CLOCK lines.

I structured it around the Locomotive "BigBoy" because the parallel programming makes some redundancy possible.

The propeller loader can be used to program propeller chips in parallel.

I do not know the accuracy of how "parallel" the internal programs are really running, but because all props run from a single clock,
the difference if present, could be calculated and accounted for.

***using the TX line as a way to sync all slave props, near perfect program alignment is achieved***

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
TERMS OF USE: MIT License

"Permission is hereby granted, free of charge, to any pers...........................
..............................OMITTED FOR FORUM...............................................
.................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

The dsp/fpga king is dead, long live the prop.

Post Edited (Clock Loop) : 8/5/2010 8:41:09 AM GMT
«13

Comments

  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-07-31 08:16
    I bet that that took some shoveling!!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Why did I think a new, more challenging, job was a good idea ??
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-07-31 10:36
    It works. A pic shows it operational.

    I just have it flashing leds, but the two props don't seem to loose sync over long periods of running.

    Post Edited (Clock Loop) : 7/31/2010 5:29:47 PM GMT
    576 x 768 - 421K
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-07-31 15:25
    So far I can only get 4 prop chips to load parallel(4884.spin) , I suspect it has something to do with the current draw on the main prop.(articulated boiler.spin)

    I am trying different resistor values to see if I can find a sweet spot. I suspect that I might be better of with 4k resistors instead of 1k.

    I don't think the 4884.spin parallel loaded props are EXACTLY in program step with eachother. They most likely have a small offset of X clocks.

    But due to their central and single clock they stay in sync, offset by X number of clocks.

    I should know more when I get a prop configured to be my viewport prop, then I can see the timing on each one exactly and compare them.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-07-31 16:45
    IF I remove the TX wires from each 4884 prop and leave the tx line open (pin30) on all 4884 props, except for the first one, all other props will get programmed properly and run.
    I ran out of prop DIPS to test more props.

    I have 6 props all programmed in parallel and all running on the same clock.
    attachment.php?attachmentid=72087

    I am pretty certain 100 props could be parallel loaded and all run on the same core clock like this.

    I have attached a revised schematic that allows more than 4 props to be programmed in parallel.



    However with this new schematic, there is no way for 7 of the 8 props(4884.spin) to talk back to the main prop(articulated boiler.spin)



    The original schematic shows 8 props, but will only work with 4 when connecting the Tx lines from the 4884 to the main prop.

    Post Edited (Clock Loop) : 7/31/2010 5:45:05 PM GMT
    576 x 432 - 371K
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-01 05:03
    Can someone scope out this setup and let me know how "parallel" the props are?

    You only need 3 props, 1 that runs articulated boiler.spin

    and 2 that run 4884.spin(these props run the binary in the directory, programmed by articulated boiler.spin)

    I tried to use viewport but its still very buggy, the lso doesn't seem to work very well, it misses data alot, etc..
    Here is a screen shot, but i don't know if this info is reliable because of how buggy the program runs for me.

    By the looks of viewport, the props are perfectly in sync, and have started at the same exact time (the programs running on them)

    Pin 16 is the 5mhz clock of all props
    Pin17 to Pin21 are the 4884.spin props outputs.
    Pin22 is a output from the articulated boiler.spin prop.

    Post Edited (Clock Loop) : 8/1/2010 5:40:17 AM GMT
    640 x 512 - 262K
  • HannoHanno Posts: 1,130
    edited 2010-08-01 05:25
    Hi ClockLoop,
    Very impressive! I think Harley was doing similar work clocking multiple props with a common propeller-generated clock. Are you using the 4cog/80msps mode of quicksample? The 5mhz clock on pin 16 doesn't look right. You should see a 5mhz pulse should last 200nsec. Can you post the 4884 and boiler code so I can reproduce?
    Hanno

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Co-author of the official Propeller Guide- available at Amazon
    Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
    12Blocks, the block-based programming environment (thread here)
    and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
  • HannoHanno Posts: 1,130
    edited 2010-08-01 05:26
    Sorry, looks like the spin is attached above- I'll take a look...
    Hanno

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Co-author of the official Propeller Guide- available at Amazon
    Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
    12Blocks, the block-based programming environment (thread here)
    and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-01 05:35
    My viewport prop code is attached.

    I run viewport on a prop all by its self.

    Its configured to use 4 cogs, with a large enough buffer.

    im running viewport v4.3.3
    Conduit v4.4
    QuickSmaple v4.2.1

    The viewport picture shows inputs from 4884 props.

    The clock output from articulated boiler runs the viewport prop and is also input into the viewport pin16
    The 5mhz clock might look bad because its looking at its own clock?

    The inputs(pin17 to pin21) on the viewport prop is connected to each of the 5 RED led outputs (4884, pin15) And the articulated boiler.spin pin15
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-01 06:23
    As far as I can tell, the props are NOT exactly parallel, their internal programs must have a bit of a clock difference.

    I determined this by having all 4884.spin props output a serial number at all the same baud rate.

    If the internal programs were running identical, i should be able to merge all serial outputs from each 4884 prop and still see a clean serial number.

    But when I connect more than a single 4884's serial output to my usb serial, i see garbage on the screen. When I only have a single 4884 connected I see a clean number over the serial line.

    Too bad, looks like this method will not produce perfect parallel programs running at the exact same spot in the code.

    The only way to accomplish that is to have them talk, to sync.




    I still like that I can parallel load them at the same time with this method tho, makes loading 6 props pretty quick.
  • BradCBradC Posts: 2,601
    edited 2010-08-01 06:27
    If you are clock syncing them, then why not start the application with a wait on a common pin, and then launch them all at once. That should get things in sync.
    The bootloader uses rcfast, so there is not a snowballs chance that they will be in any form of sync during the load/start process.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-01 06:33
    BradC said...
    If you are clock syncing them, then why not start the application with a wait on a common pin, and then launch them all at once. That should get things in sync.
    The bootloader uses rcfast, so there is not a snowballs chance that they will be in any form of sync during the load/start process.


    Thats right, darn bootloader...

    I suppose a common pin controlled by the articulated boiler would do well.

    I suspect that I will also have to change my clocks to non-pll due to differences between props... not sure..
    But that can be done easily enough, make the main prop output 80mhz, and turn off pll mode on all 4884 props.

    disabling of the pll was not needed to align internal programs

    But disabling the pll might be needed along with the articulated boiler.spin outputting 80mhz clock to get exactly perfect program alignment.

    Post Edited (Clock Loop) : 8/2/2010 6:35:44 AM GMT
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-08-01 08:20
    When you get the sync part working, I could test it on a 40-prop skyscraper. It should be open ended, i.e. so the system works if more props are added, and it should have the minimum number of prop to prop wires. I plan to upgrade the 40 props to the next level. I may also subtract some props from the 40 to do other projects during the interim.

    humanoido
  • BradCBradC Posts: 2,601
    edited 2010-08-01 11:16
    The sync would be _easy_. Just re-use the master-> slave async IO line you use to program the props. Have the slaves clock up to full speed and wait for the line to drop. Have the master hold it high immediately after programming the slaves, wait a bit and then drop it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-08-01 18:29
    BradC said...
    The sync would be _easy_. Just re-use the master-> slave async IO line you use to program the props. Have the slaves clock up to full speed and wait for the line to drop. Have the master hold it high immediately after programming the slaves, wait a bit and then drop it.
    BradC: wow, sometimes the most simple things in life are the most brilliant and dreamed by genius'. If the master programs 39 slaves (can it do 39?), how long should it wait for the slaves before dropping the line low?

    Humanoido
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 05:07
    Humanoido said...
    BradC said...
    The sync would be _easy_. Just re-use the master-> slave async IO line you use to program the props. Have the slaves clock up to full speed and wait for the line to drop. Have the master hold it high immediately after programming the slaves, wait a bit and then drop it.
    BradC: wow, sometimes the most simple things in life are the most brilliant and dreamed by genius'. If the master programs 39 slaves (can it do 39?), how long should it wait for the slaves before dropping the line low?

    Humanoido

    Thats exactly what I thought BradC, no need to run extra wires, just have master prop send out on same line used to program them.


    Humanoido, I think the limits to how many slaves can be programmed is a limit of drive capability.

    The prop's ability to drive I/O is 40ma per pin, a prop's current draw is so little that one would run out of money before they ran out of drive supply.

    The reason this method works at all, is due to the fact that only a single props reply gets back to the master prop who is doing the programming.

    All other props send out the same data with minor enough variations that a "blind, but emulated" parallel programming takes place successfully.
    Keep in mind that all other props "replys" to the programmer is not heard. (except for one)

    In other words, all but a single parallel prop's TX line should be UNCONNECTED to the MASTER PROP's rx programming line.

    The maximum number of props should be virtually unlimited.

    All would be programmed identically, even if you had 200. They all would take a single prop's programming time.

    We all know the method to get each prop to run their own custom program. (using I/O switches) or even communications.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 05:12
    Humanoido said...
    how long should it wait for the slaves before dropping the line low?

    Humanoido

    I would determine this by scoping the internal program timing differences and looking for "worst case scenario" and use that as a minimum wait time for sync.
  • heaterheater Posts: 3,370
    edited 2010-08-02 05:26
    It will happen that from time to time one or more Props in the collection will fail to program.
    How will you know, apart from manual inspection of flashing LEDs etc.?
    There ought to be some feed back to the master from the slaves performed by the booted program that can indicate failure and the process repeated. But how?

    Given that all props at load time are running off of RC clocks which must all be of different frequency within some range I wonder if it is possible to have an "outsider" whose clock is different enough from all the others that it always fails.

    Worse still if the "outsider" was in the position that returns feedback to the master then all the other Props would fail to program all the time.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,066
    edited 2010-08-02 06:13
    heater is right in that the props use their internal RC osc when loading the code. I know the loader (Chip has published the code) does recalculate the timing of the incoming signal so just perhaps it removes the RC variances from the equation.

    All the slave props will be responding on the same output pin. I am unsure of how you are preventing a conflict here - so what is your circuit?

    Perhaps there is a way to ensure the loading of all props work correctly - you will need to look at the loader source.

    As for the syncing of all props, it is quite easy as discussed. I used this method to sync the 4 cogs 1 clock apart on my datalogger, so I could sample on each clock. You could use this method with 1 prop to sample 32 props (well 28?) and ensure they were all in-sync.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
    · Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 06:14
    PERFECT PARALLAX PROPELLER PARALLEL PROGRAMMING with PARALLELED PROGRAMS.

    Awesome.

    I tested the programs for synchronicity, and its almost PERFECT.

    I can merge two serial lines outputting the same serial at the same time, and no GARBAGE.


    Once in a while I will see artifacts from my serial line... possibly indicating some issue with synchronicity.



    This means that programs can be created that consider the dual threaded output of two prop chips.

    Post Edited (Clock Loop) : 8/2/2010 6:31:12 AM GMT
  • heaterheater Posts: 3,370
    edited 2010-08-02 06:25
    Cluso, as far as I can tell what we have here is one Prop, the "Master" programming another Prop, I will call "Primary Slave". Between these two is a normal two way connection so hopefully the Master and Primary Slave synchronize their timing as does a PC and a Prop when programming.

    Then we have a bunch of other Props, listening to the download, let's call them just "Slaves". Slaves have no return connection, see schematic at he beginning of this thread. So there is no conflict in the return path. There is no return path! They suck the code in as best they can just by listening.

    If all goes well and the RC clocks of all slaves are similar enough then it works.

    If one or more slave downloads fail there is no way the Master knows.

    I'm kind of surprised the Slaves do not go out of synch during the download of 32K bytes.

    Which is why I posed the question. If there is a RC timing outlier it might fail. Or what about mixing Props from different batches?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 06:41
    heater said...
    Cluso, as far as I can tell what we have here is one Prop, the "Master" programming another Prop, I will call "Primary Slave". Between these two is a normal two way connection so hopefully the Master and Primary Slave synchronize their timing as does a PC and a Prop when programming.

    Then we have a bunch of other Props, listening to the download, let's call them just "Slaves". Slaves have no return connection, see schematic at he beginning of this thread. So there is no conflict in the return path. There is no return path! They suck the code in as best they can just by listening.

    If all goes well and the RC clocks of all slaves are similar enough then it works.

    If one or more slave downloads fail there is no way the Master knows.

    I'm kind of surprised the Slaves do not go out of synch during the download of 32K bytes.

    Which is why I posed the question. If there is a RC timing outlier it might fail. Or what about mixing Props from different batches?


    You got it, as far as why this works.

    THE SECRET IS THE SCHEMATIC, not the programming. Look at the attached pdf file. All slave props do not have the same connections as far as their TX.

    I was floored when I figured out that props could be used like this.

    I have had no download failures on the slaves, I do have prop chips that were ordered at all the same time.

    If I connected 4 slaves transmit TX lines back to the Master, they all still worked fine.

    Hook up a 5th one and 2 props will drop out of the chain when you program.

    I tried hooking the TX lines using 1k resistors, then 5 worked when all connected, but a 6th wouldn't work,
    This is when I came to the realization that what i was doing was emulating the props, they didn't need to be connected at all. (save for 1) And with more than 4 connected, their RCTIMEs were starting to screw up the communication.



    *** PARALLAX COULD SELL BATCH PROP CHIPS FOR THIS PURPOSE.***

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    TERMS OF USE: MIT License

    "Permission is hereby granted, free of charge, to any pers...........................
    ..............................OMITTED FOR FORUM...............................................
    .................. OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. "

    The dsp/fpga king is dead, long live the prop.

    Post Edited (Clock Loop) : 8/2/2010 7:09:01 AM GMT
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 07:13
    This method of multi chip programming using a single chip as the emulator for all other chips should be tried with all known situations.

    PICs, stamps, sx's etc...

    Ya never know what someone will come up with on a different platform using this method.
  • kuronekokuroneko Posts: 3,623
    edited 2010-08-02 07:18
    @Clock Loop: So can you actually upload 32K without issues? I'd have thought that, given the time it takes (~14sec @80MHz), there is lots of potential for getting out of sync (slaves @ RCFAST only).
  • heaterheater Posts: 3,370
    edited 2010-08-02 07:30
    kuroneko, I'm very surprised to.

    What do you mean ~14sec @80MHz?

    There is no 80MHz at load time. Only the RC oscillator.

    Anyone know what's in the Prop's loader code. The stuff it runs from reset from ROM. Does it have some clever tweaks in there to synch itself to incoming edges?

    Now that I think about it I seem to remember Chip said here that this could be done a year or two back. Not sure if he ever actually did it though.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 07:35
    kuroneko said...
    @Clock Loop: So can you actually upload 32K without issues? I'd have thought that, given the time it takes (~14sec @80MHz), there is lots of potential for getting out of sync (slaves @ RCFAST only).

    Good point, I tried this based on your suggestion; and....

    I just tested uploading near 32k, (I included a 25k rar file in the 4884.spin DAT section.)

    This filled my main prop program to 7,214 longs, 25k of that gets downloaded into each 4884 parallel prop.

    This makes my 4884.binary file 6,727 longs. And this gets downloaded fine.


    No prop drops out, they all take longer to load, but load fine.


    This was tested on this setup: 1 Master prop, 6 slaves.

    Post Edited (Clock Loop) : 8/5/2010 8:46:53 AM GMT
  • kuronekokuroneko Posts: 3,623
    edited 2010-08-02 07:43
    heater said...
    I'm very surprised to.

    What do you mean ~14sec @80MHz?

    There is no 80MHz at load time. Only the RC oscillator.
    I know, but you can't run the PropellerLoader with RCFAST. I am/was assuming that the master prop runs at 80MHz (feeding all the RCFAST slaves). As for 14sec, the transfer rate is - on average - clkfreq/4400, 32K will therefore take about 14sec.
  • BradCBradC Posts: 2,601
    edited 2010-08-02 07:45
    kuroneko said...
    @Clock Loop: So can you actually upload 32K without issues? I'd have thought that, given the time it takes (~14sec @80MHz), there is lots of potential for getting out of sync (slaves @ RCFAST only).

    No way, the bootloader resynchronizes on each bit so it is not possible for the timing to drift that far. The clock frequency would _really_ have to change dramatically in that 14 seconds for it to skew far enough to mis-time a bit.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
  • kuronekokuroneko Posts: 3,623
    edited 2010-08-02 07:46
    heater said...
    Anyone know what's in the Prop's loader code. The stuff it runs from reset from ROM.
    http://forums.parallax.com/showthread.php?p=711064
  • heaterheater Posts: 3,370
    edited 2010-08-02 07:50
    BradC, to be clear, when you say "bootloader" I'm taking that to mean the loader code in the Props ROM.

    If that code is resynchronizing on every bit then this system should be quite reliable.

    Still, the Master Prop cannot tell if all has gone well yet.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • BradCBradC Posts: 2,601
    edited 2010-08-02 07:54
    heater said...
    BradC, to be clear, when you say "bootloader" I'm taking that to mean the loader code in the Props ROM.

    Yes
    heater said...

    If that code is resynchronizing on every bit then this system should be quite reliable.

    Still, the Master Prop cannot tell if all has gone well yet.

    No, there is no easy way to provide feedback.

    On the reliability, I ran a loop that loaded a prop with a large file > 100,000 times from Linux and got 2 failures. I'm pretty sure they were scheduling blowouts due to a slow disk though rather than an issue with the comms.

    Provided your reset timing is in the middle of the window, and you are using ~115k baud then it should be pretty solid. 230k requires an extra bit time delay at the end of each long to allow the code enough time to write it to the hub and get back to wait for the next bit if the prop is over about 40 Deg C.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Sign In or Register to comment.