Shop OBEX P1 Docs P2 Docs Learn Events
Prop-to-Prop Intercommunication: Best Practices? — Parallax Forums

Prop-to-Prop Intercommunication: Best Practices?

Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
edited 2013-06-13 19:40 in Propeller 1
So I'm working on a little Prop/2/Prop stuff, and being a guy who likes elegant solutions, I added some male/female pin headers to a couple Quickstarts, plugged them together and jumped in.

The first things I start to notice.. Seems that a lot of noise occurs on the connection, handled with pull down. Second, it appears that my current top reliable speed (fullduplexserial) is around 19200.

Has someone established a "best practices" to Propeller intercommunication and interconnection somewhere? I'm getting the feeling that this path has probably been blasted down and I'm nooddling my way to it.

Jeff

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-06-12 20:21
    I've found Tracy Allen's version of the four port serial driver works better than fullduplexserial. I've pretty sure I've used the four port object at least 57600 baud probably higher for Prop to Prop communication.

    I use a 10K pullup on each line myself.
  • KeithEKeithE Posts: 957
    edited 2013-06-12 21:06
    Do you have a scope? That baud rate is so low it's hard to believe. I would want to see what's going on the interconnect.

    Can you try running this on one prop and having it communicate with itself so you eliminate the interconnect. Just in case it's something else.

    I don't understand how weak pullups or pulldowns would help at all. The lines are always driven correct?

    Did you look at Beau's posts (from similar threads box) in http://forums.parallax.com/showthread.php/99222-Propeller-DEMO-(14.5-Meg-Baud)-High-Speed-Prop-to-Prop-Serial-Communication
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-06-12 21:11
    KeithE wrote: »
    I don't understand how weak pullups or pulldowns would help at all. The lines are always driven correct?

    I don't know if a pullup helps with Tracy's version or not. I know with an earlier serial driver I'd get a bunch of zeros as input if I didn't use a pull up. I think the problem was the serial object didn't detect framing errors. Here's a link to Tracy's comments about it.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2013-06-12 21:14
    Beau Schwabe claims >8 MBaud, 100% reliable Prop-to-Prop comms over 10 ft. of unshielded speaker wire here:

    -Phil
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-06-12 21:21
    Jeff, I've run 115k and I believe 230k between prop using PropForth. If I recall, I just had 220 ohm resistors inline to protect the pins. I don't think there were pullups...I'll have to check my notes in the morning.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2013-06-12 22:07
    Thank you Duane

    What a huge improvement! Switched out FullDuplexSerial for the suggested object. Pushing 57600 with only an occasional glitch. (I'm not even implementing the proper pull down resistors yet.)

    Here's a link to the project I'm working on for this.. I'm attempting to expand my PMC project to two Quickstarts. (It looks completely doable now.)

    http://propellerpowered.com/forum/index.php?topic=491.0
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-06-13 01:34
    Pushing 57600 with only an occasional glitch

    Still doesn't sound quite right. Shouldn't be any glitches with a short link, even up to 4x this speed.

    ? post a picture. I'm wondering about strange things like earth hum loops.

    If you can get the speed up to 115k then it opens up the possibilities with propellers programming other propellers. I have played around with this and it is great fun - store programs on an SD card on the main propeller, and then use that to program other propellers. The slave propellers don't need eeproms.
  • KeithEKeithE Posts: 957
    edited 2013-06-13 08:02
    I still don't get the need for pulldown resistors. I could see using pullup resistors to keep the lines in the idle state until embedded software has a chance to boot up and starting driving the lines though.
  • KMyersKMyers Posts: 433
    edited 2013-06-13 10:34
    I would do the pull ups plus a 220 ohm resistor between pins. Could it be ringing (reflections) between pins and such short distance?

    Just my 2 cents worth, alays like some isolation....
  • prof_brainoprof_braino Posts: 4,313
    edited 2013-06-13 11:03
    As Phil said in #5, the synchronous serial runs crazy fast. I think the bit time is the same as the system clock. Sal says the MCS has not seen an error beyond the "pull the wire" test, and hasn't found a maximum length yet. I think the longest wires in the lab were over 10 feet.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2013-06-13 12:23
    Boosted speed today to 115K. No issues or glitches detected. Currently running with RX--TX pin directly connected. I'm pretty sure it's faster than the BASIC will need for display or music purposes.

    Sending a program from one Propeller to another could get interesting. @DrA, didn't you do something like this recently?

    Jeff
  • Cluso99Cluso99 Posts: 18,069
    edited 2013-06-13 13:17
    I use 115,200 without resistors all the time without problems, and FullDuplexSerial_rr004 (buffer size mods). Something is wrong with your setup/timing. However, since you are connecting 2 pcbs together, I would add a series resistor for protection in case the same software is loaded in both props in error which would result inboth props outputting on the same pins.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2013-06-13 17:10
    Glad to hear you have it working fast now :)

    re
    Sending a program from one Propeller to another could get interesting. @DrA, didn't you do something like this recently?

    What I did was search the obex and found a program from years ago which allowed a second prop to be programmed. I think it was from parallax and goes right back to when the propeller first came out. The problem back then is the prop had no mass storage, so if you wrote a 32k program and decided to program another propeller with say, half that, then you only had 16k. Less if you tried to store multiple different programs as data files in a main spin program.

    So what I wanted to test was whether there would be any glitches if you read a file off an SD card in pieces (512 bytes) and send those pieces out via the protocol above. And the good news was that it worked fine.

    The code is thus simply any SD card object, and 'programming another propeller' object and you just open the SD card .bin file and send it out.

    What would be really handy would be an IDE that would make programming multiple propeller chips easier. eg you could have tabs open for all the propellers in the group, and you could direct a compiled program to either go to a master propeller, or via a master propeller to a nominated slave propeller, or to an SD card on the master propeller. So an F10 and F11 but for all propeller chips in a group.

    One can think of all sorts of clever things. A group of propeller chips but you save money by only needing one SD card and one eeprom. One could even think of software than could handle the abstract idea of 16 cogs running in parallel with seamless intercog comms.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2013-06-13 18:02
    I just posted a copy of the project to my forums. I was able to find around 12k of space (opened 8k to my project, while adding SIDcog.) It appears to be working very nicely.

    Now I've got a create a second GRAPHICS mode which can be switched on from the second Propeller.

    Jeff
  • cavelambcavelamb Posts: 720
    edited 2013-06-13 19:40
    KeithE wrote: »
    Do you have a scope? That baud rate is so low it's hard to believe. I would want to see what's going on the interconnect.

    One ground line, 30 signal lines.
Sign In or Register to comment.