Shop OBEX P1 Docs P2 Docs Learn Events
Interprop(?) communications — Parallax Forums

Interprop(?) communications

Q*bertQ*bert Posts: 59
edited 2009-04-06 13:24 in Propeller 1
I've been looking at using a MAX7219 or MAX6969 to reduce pin demand for driving LEDs, but with recent price drop for Props it doesn't make nearly as much sense as it used to. I can add a second Prop for <$10 and have a lot more pins and horsepower for other uses available.

With the explosion of multi-Prop designs lately, is there a generally accepted way to do reliable Prop-to-Prop (is that interprop?) communications? Is simple serial interfacing good enough, or is anyone using sort of error-checking protocol?

Comments

  • Bill DrummondBill Drummond Posts: 54
    edited 2009-04-05 23:47
    This is something I''ve been thinking about. What if we used windows DLL's as a templent? Each Processor would have a set of psudeo registers.
    The master Processor would send a packet of the registers and a Subroutine number. The slave processor would perform the requested subroutine
    and send back a packet with the status and results in the registers.
  • yetiyeti Posts: 819
    edited 2009-04-06 00:06
    How do multiple propellers on one i²c bus behave?
    Making them master and slave would give each prop a unique number (as slave) to be addressable like any other i²c device. As master, every prop could talk to the slave part of the other(s)...
    And amy other i²c master (PIC, AVR, ...) could trigger requests to props too in such an environment.

    ...and this would only need the same pins as for the eeprom now...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Coming soon: Neat sig with bells and whistles!
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-04-06 00:18
    The easy way is just use FDX (FullDuplexSerial). Pass what you like. If the props are close (and no pcb noise issues meaning good design practices) no problems with 115200. Don't forget to have one do TX while the other does RX on the same pins and v/v.

    If you want higher speed and lengths of lines and synchronisation, see Beau's thread for 14Mbps 32bit serial. Forget I2C or SPI as there is a protocol on top and it is unnecessary as you control both ends. I will be doing this for my TriBladeProp boards.

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

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · 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)
    · Search the Propeller forums (via Google)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Bill DrummondBill Drummond Posts: 54
    edited 2009-04-06 01:07
    Is there a easy way to share access to a I2C device, example: here is a buffer loaded to diplay on the TV/Vga?
  • Brian FairchildBrian Fairchild Posts: 549
    edited 2009-04-06 06:58
    CSmith said...

    ...for driving LEDs...
    Keep an eye on your total currents. While each IO pin is rated to 40mA, the total package should not be asked to take more than 300mA, ie less than 10mA per pin.
  • kwinnkwinn Posts: 8,697
    edited 2009-04-06 13:24
    I have to agree with Brian. When driving loads that require higher currents such as leds you need a driver chip anyway so you are better off using something like a MAX7219 or one of the TPIC chips. That is not to say that using a Prop as a slave I/O device is not a good idea. There are many applications where a peripheral with some smarts would be a great choice.
Sign In or Register to comment.