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

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

2

Comments

  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 08:19
    I still can't believe that two props can have two serial output programs running at 115200 baud, connect both TX lines to your terminal input, and the data ends up in my serial terminal as perfect.

    Two different chips running the exact same program with the same clock, synchronized using WAITPEQ.

    I wish I had a scope to see some timing shots...

    The fact that two 115200 baud signals can be merged with no garbage is awesome.

    Perfect redundancy achieved?


    Jitter.... could this cause a problem, perhaps i should go with no plls.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 09:33
    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.

    With the attached schematic, the only limitation are the programs in the Articulated boiler.spin, and 4884.spin to determine proper communication sequence.

    All of my 6 props will program properly with this schematic. I tested it with my setup.
    The communication back to the MASTER will work just fine if you don't let any slave stomp on another slaves transmission.

    Each prop would need a way to be uniquely identified (using jumpers on pins, or loading of a file from serial or sd card connected to each slave individually)
    Then each can be assigned a unique number and based on that number, the prop would have a transmission window.

    Then each slave prop can ACK back to the master during its transmission window to see if all are present.

    I would just jumper pins /tie one high on each prop to uniquely identify each one.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 10:48:32 AM GMT
  • Jorge PJorge P Posts: 385
    edited 2010-08-02 10:25
    Chip Gracey stated that you can tie a single Oscilator to multiple props in an old 2006 therad. http://forums.parallax.com/forums/default.aspx?f=25&m=121344 I dont see that you did this in your schematic. He stated that doing this would keep them all exactly in sync.

    *edit* sorry the link is messed up, here it is·http://forums.parallax.com/showthread.php?p=582511

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ---
    http://WhatsAvailable.org Software and Gadgets for Windows 7.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-02 10:39
    Jorge P said...
    Chip Gracey stated that you can tie a single Oscilator to multiple props in an old 2006 therad. http://forums.parallax.com/showthread.php?p=582511</P>

    I suppose you could do that, they could all run from the main props oscillator...

    I like being able to change my slaves clocks. to say, 6.25mhz even tho I don't have a 6.25 crystal.
    Or even make my main prop run on 5mhz, while it outputs 80mhz to every slave so my slaves didn't need their plls.


    I did a test with parallel props and my synchronization method using waitpeq.

    As far as I can tell the programs are not synchronized because of the pll.
    or waitpeq spin is too slow?

    I made my 4884.spin file run the HSS sound system core with SPDIF output.

    I then hooked the spdif output to my digital audio input on my pc, a single prop transmits audio data fine, but when I merge two prop's spdif outputs together, it kills the spdif stream.

    I suspect its from the pll jitter. So I will disable the pll's on my slaves, clock them with 80mhz, and test again.
    (thats if my spdif hss sound system dosen't yell at me for turning off the pll.)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2010-08-02 14:06
    Clock Loop: The single oscillator means using a crystal oscillator circuit and tying all the XI pins together and to the output from the xtal oscillator. You cannot tie all the slaves XI pins to the master's XO pin with the xtal on the master between XI & XO.

    waitpeq in spin may need to be lengthened (I didn't look at your code) as spin is ~50+ times slower.

    You have to be careful joining output pins as the result may not be what you want. You method of using the resistors to prevent conflicts destroying the chips, but you need to see what the net result is in the circuit when some outputs are 1 and others 0. In audio, often capacitors are being used to charge up and multiple output will effect this.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 14:33
    Cluso99 said...
    Clock Loop: The single oscillator means using a crystal oscillator circuit and tying all the XI pins together and to the output from the xtal oscillator. You cannot tie all the slaves XI pins to the master's XO pin with the xtal on the master between XI & XO.

    You have to be careful joining output pins as the result may not be what you want. You method of using the resistors to prevent conflicts destroying the chips,

    I wouldn't recommend using the same crystal to run more than a prop or two...
    I tried it with my setup of props and....

    When I run 6 props from a single 5mhz crystal, slaved off the main props XO, the parallel props fail
    But some of them run.
    The drive output of the crystal, compared to the drive output of the main prop generating the 5mhz seems to be the reason?



    Yea, I don't want to destroy chips, thats why I use resistors, but beyond that, skys the limit. (its how I found out about this programming method)
    One would need to use proper programming technique to avoid odd situations, where props output opposite states at the same time.
    Thus the unique id using a pin tied high, then depending on the pin, that prop waits for the main prop to call its pin, then it replies, 13375



    I also ran my 6 props using 80mhz with pll disabled, and found the spdif data is still not aligned.
    I also noticed when using 80mhz mode on a breadboard, the parallel props fail due to clock noise. damn breadboards.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-05 08:44
    V1.0

    The schematic HAS changed to pull UP 10k on both tx/rx lines so I can use mode %100 on serial communications.

    Parallel communications using the real random object on each slave.

    Master calls to slaves and slaves sound off when they are called upon.

    There is no need to uniquely identify each slave using pins. (unless a slave has specific unique purpose attached to its pins)

    All below attached files are v1.0

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 9:17:13 AM GMT
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-05 09:09
    The real random object generates a new slave ID every time the props are re-programmed.

    A larger random number could be used, but it would require the master prop (articulating boiler) to enumerate a larger pool, taking more time to ID all props.

    But because this process need only run once to find what slaves are using what ID.

    A long sized ID could be used, just transmit byte ranges.

    Post Edited (Clock Loop) : 8/5/2010 9:17:37 AM GMT
    640 x 512 - 107K
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-08-05 16:00
    Clock Loop said...
    The real random object generates a new slave ID every time the props are re-programmed.
    Clock Loop, is there a chance some number will repeat? How about repeats with a 40 prop system? Just curious. Generating and storing IDs that are read back from a certain EEPROM and then mathematically conditioned sequentially also works.

    humanoido
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-05 16:11
    Eventually with enough props you will find repeats, for instance..

    With only a random BYTE, you can only generate 256 possible combinations before guaranteed repeats. (much sooner than that)

    I am sure this could be plotted on a graph.

    Size of random number with number of props, graphed for possibility of repeats found.

    With my 6 props using random number generated out of 256 possibilities, I have had some repeats. Its very rare tho.

    I could tell I had a repeat, when I had only 5 props reply with their ID's. Which did happen a few times.
    I suspected it being a prop that got out of timing, but I think now its more that I had a prop with the exact same id as another, who were replying identically at the same time.


    If one were to use a long sized random number, the possibilities of repeats would be near impossible.


    Knowing you have a repeat ID is easy, you just count the number of replies you get, and if you don't have 40 replies, you have some repeats.

    Post Edited (Clock Loop) : 8/5/2010 4:16:27 PM GMT
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-08-05 16:23
    Clock Loop said...
    Knowing you have a repeat ID is easy, you just count the number of replies you get, and if you don't have 40 replies, you have some repeats.
    Actually I think any repeat is not acceptable. A routine to flush out the dupes could be too much overhead, but I'm open to ideas and suggestions.

    humanoido
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-05 16:43
    Humanoido said...
    A routine to flush out the dupes could be too much overhead, but I'm open to ideas and suggestions.

    humanoido

    Well its as simple as using a random number that is a long not a byte.

    This means that during transmission, you either can't use fullduplexserial to transmit the long, or just use loops to send the long out in "byte" gaps.

    I can code this if you need me to, its very simple.

    This just means the first enumeration of all props will take some time to go through all those combinations to find which ID the props are all using, but once they are all found, your done. And because we are using a really fast device, it doesn't take that long.
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-08-05 16:48
    Clock Loop - yes.. would like to see that simple code version!
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-05 17:25
    Humanoido said...
    Clock Loop - yes.. would like to see that simple code version!

    Byte gives you one of 256 combinations. (this takes 0.57 seconds to enumerate 256 possibilites) I tested this.

    Word gives you one of 65,536 combinations. (this takes about 2 minutes 26 seconds with my slow code) I tested this.

    Long gives you one of 4,294,967,296 combinations. (this takes about 2, 657 hours) or (111 days) or (9,568,256 seconds) or (3.7 months) (LOL!) I will not be testing this.
    DONT TURN THAT OFF, it took me 4 MONTHS to enumerate it. hehe


    Faster code with the long would enumerate much faster.

    I used the word enumeration for a maximum wait time of 2 minutes 26 seconds, for a total combination of 65,536.
    I don't see you having a duplicate even with a word length.

    The attached code uses word and was tested on my setup.
    Thats how i found my enumeration time using a word, I then just did some math to calculate the long enumeration maximum time.

    Post Edited (Clock Loop) : 8/5/2010 6:05:46 PM GMT
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-08-05 19:25
    Clock Loop, that was fast! What were the results of repeats from the word test? If you repeated the first 40 or 100 enumerations several times, like a 100 times, did it cause a dup? I agree, the long would take too long.

    Humanoido
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-08-05 19:37
    Humanoido said...
    Clock Loop, that was fast! What were the results of repeats from the word test? If you repeated the first 40 or 100 enumerations several times, like a 100 times, did it cause a dup? I agree, the long would take too long.

    Humanoido

    Repeating 100 enumerations would take 4 hours.

    Technically its possible to get a repeat the first time you run your very first enumeration.

    But thats similar to wining the lottery. With enough time, repeats are possible.


    Repeated enumerations on the same hardware is NOT the same as enumerations on more hardware.

    I am willing to bet that more prop chips would have a much lower chance of getting the same number,
    due to the thermal, radiation, and general entropy from more hardware spread out.
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-11-05 04:34
    I tested this out to 28 prop chips, works pretty well.
    2000 x 998 - 339K
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-11-05 06:50
    That looks great. Interesting use of breadboards. I had not imagined so many put together but I like it because you can see all the wires. Did you modify the software to get 28 all loaded and running? If you tried this with more props do you think it would work?
  • hinvhinv Posts: 1,252
    edited 2010-11-05 07:19
    Now that is cool!
    Now if you could get them doing some parallelable algorithm, something like a mandelbrot generator.
    And you could do BeauNet without having to have start and stop bits every 32bits.
  • jazzedjazzed Posts: 11,803
    edited 2010-11-05 07:53
    Do you have any way to resolve duplicate IDs?
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-11-05 08:47
    Clock Loop, your project is now added here.
  • RavenkallenRavenkallen Posts: 1,057
    edited 2010-11-05 09:30
    Someone has a lot of propellers, haha(I only got like 5).....Good job anyway..
  • obrienmobrienm Posts: 65
    edited 2010-11-25 14:08
    Clock Loop,
    I would like to state that you have done the propeller community a great service by investigating and documenting your parallel loading of multiple propellers "design pattern". I have verified your schematic and did a minimum prototype using 2+1 propellers and it seems to work excellent.
    I will be using your connection pattern in any mesh of propeller chips as of now. I previously was using the method perfected by Godzich, Christian, Ken and Pems in the 2008 thread "Multiple Propellers & one EEPROM". The older method had a maximum of 12 propellers per EEPROM in practice and it was sequential (very slow). Your parallel method which eliminates the need for a mesh-EEPROM keeps the cogs in sync prior to a potential 7 sequential cognew calls for SIMD example app.

    http://forums.parallax.com/showthread.php?t=107413

    thank you
    /Michael O'Brien
  • MacTuxLinMacTuxLin Posts: 821
    edited 2010-11-25 19:52
    Clock Loop wrote: »
    I tested this out to 28 prop chips, works pretty well.

    May I know how many Amp is your power adapter that ran this 28 props?
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-11-25 22:22
    obrienm wrote: »
    Clock Loop,
    I would like to state that you have done the propeller community a great service by investigating and documenting your parallel loading of multiple propellers "design pattern".

    thank you
    /Michael O'Brien

    No problem, I will now take this time to advertise my services.

    Something like this is too cool for someone to keep to themselves, I had to share it.

    Plus, no company has chosen to employ me in my skill, so my idle hands have gone into public service. Its too bad, because my last employer could have not only used this tech, but could have benefited from other things that I do/create/discover.

    ((i'll insert my personal AD for employable, relocatable, flexible, all around great guy and employee, here))


    The challenge now is for people to do things with it.
    This method of parallel programming using a master slave subslaves could be done in almost any situation where someone is operating identical chips that don't have unique programming verification replys.

    I suspect the prop2 will have unique replys in the programming communication CRC, which would prevent this parallelism from being loaded.

    The reason this works is due to the clone nature of the prop, it dosen't require any kind of encrypted programming, no crc that uses unique random chip based replys, ...

    The clone nature of the prop and its lack of security features is why something like this is possible. (and here parallax is talking about moving to security on prop2... this could be a bad move)

    The strongest reason I was able to do this is because the open nature of the prop and all the free software available in the obex without any fees, i was able to learn the prop's language quickly and easily. And because it is impossible to lock your code, the desire for people to charge fees for their software almost goes away...

    The open and free nature of the prop is what you should be thanking here.
    Its too bad the P2 might kill it all. Perhaps the P3 will revert back to an open only platform.









    The 28 props were all hooked up using a single lm1117
    http://www.national.com/mpf/LM/LM1117.html

    No this is not enough if you were to actually drive outputs, or have the props do things. For my situation, I used many caps, it works, but when increasing the # of props issues arrive from the lack of power, along with my lack of tinning on my prop pins.

    28 props x 300ma = 8.4 amps.
    If you were driving all props at package maximums, then you would need 9 amps.

    If I did it correctly, I would have multiple lm1117's.
    Technically 1 for every 3 props or so.

    (this is probably why, when I tried more than 28 props, it would malfunction, and I have been a bit busy to fix it up and show the full spread of props.) Yes, I have more than 28... quite a bit more actually.
    Soon i'll post pics and info on the full spread.
  • MacTuxLinMacTuxLin Posts: 821
    edited 2010-11-25 23:32
    Clock Loop wrote: »
    The 28 props were all hooked up using a single lm1117
    http://www.national.com/mpf/LM/LM1117.html

    No this is not enough if you were to actually drive outputs, or have the props do things. For my situation, I used many caps, it works, but when increasing the # of props issues arrive from the lack of power, along with my lack of tinning on my prop pins.

    28 props x 300ma = 8.4 amps.
    If you were driving all props at package maximums, then you would need 9 amps.

    If I did it correctly, I would have multiple lm1117's.
    Technically 1 for every 3 props or so.

    (this is probably why, when I tried more than 28 props, it would malfunction, and I have been a bit busy to fix it up and show the full spread of props.) Yes, I have more than 28... quite a bit more actually.
    Soon i'll post pics and info on the full spread.

    Thanks ClockLoop.
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-11-26 03:17
    error 00A4
  • dMajodMajo Posts: 855
    edited 2010-11-26 09:28
    Clock Loop wrote: »
    (and here parallax is talking about moving to security on prop2... this could be a bad move)

    I do not think so. IIRC the security relies on a x-bit encryptyon key stored in a OTP rom on the PropII.
    It's enough that you program the same encryption key on multiple props ant all should be right
    Clock Loop wrote: »
    And because it is impossible to lock your code, the desire for people to charge fees for their software almost goes away...

    Thats probably true. Perhaps we will have less open source contributions but this will open the doors to the comercial/industrial use of the propeller thus maybe lowering chip price because here is where sale volumes are made.

    Massive volumes can allow an onchip flash ... ...

    ... so it shall be good
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-12-12 02:49
    Clock Loop, the slave props don't have an eeprom in the circuit. Is it possible to use Parallax Proto Boards keeping the eeprom on pins 28 and 29?
  • Clock LoopClock Loop Posts: 2,069
    edited 2010-12-12 15:20
    Humanoido wrote: »
    Clock Loop, the slave props don't have an eeprom in the circuit. Is it possible to use Parallax Proto Boards keeping the eeprom on pins 28 and 29?


    You could utilize them if you wanted to, by changing the code that calls the Propeller Loader object. It has different programming modes, so each slave could program its eeprom in parallel. Mind you the replys of good/bad eeprom will go into oblivion, unless you processed the replys of each slave.

    I have not tried slave eeproms, beyond testing my "dual ftdi props" http://forums.parallax.com/showthread.php?124520-Anyone-that-wants-more-data-up-the-USB-serial-pipe-Dual-FTDI-Parallel-Props-(hanno!)

    I show a version with eeproms.


    The problem you (Humanoido) will run into is noise. Although you may have 40 pcb's with props, the length of wire that you need to cross connect all the props is such that, you will need to modify your program to use the onboard crystals, doing this gets the props misaligned from seperate crystals, this would then require a communication scheme using an ack reply/line.

    Using 40 props on a breadboard is very difficult, the program has to be perfect, so does the circuit. Getting 40 seperate pcb's to run like this would be nearly impossible, due to the noise. IF it were possible, it would involve some kind of point to point, as short as possible connection scheme, which was soldered into place.

    If you're really serious about 40 props working together, do it on a single pcb. You could make a pcb with 40 - DIP40 sockets in it. Each DIP40 could trace out to "via" soldering points, and continue on to connect other props. Make all traces so you can cut them at a certain point if needed. Between two "vias", this would allow you to re-connect them if you want.

    IF you use a slower clock that gets passed to the slaves, you might be able to get them all to work like this, on a single clock source. However you don't have much room to use other clock speeds.
    After 10-20 pcbs i think your clock would look too much a mess for props to like.
Sign In or Register to comment.