Prop to Prob Communication

krazyideas

Hello.

I am writing a program that uses several propeller chips to do a ton of different things.
I have it working just fine.·My problem is that I am useing as many prop plugs as I am prop chips, so that I can control all the different varubles and functions of my program.·I know there has so·be a way to communicate varubles and information between propellor chips I just have no clue where to start so I can learn how.
What I would like to have is a Master Propellor that would take care of all my varubles and the changes I make to them and then pass those varubles onto my other propellors.

I'm up for learning a new trick, so I could eliminate a bunch of unnessasary wires.
I haven't been playing around with programming long, so relitively simple explanations are much welcomed.

Thanks a ton

Post Edited (krazyideas) : 10/16/2009 4:44:12 AM GMT

Mike Green

Each Propeller except the Master is now using pins 30/31 for communication and control. All you need is for one Propeller to take the place of the PropPlugs for all of the others. What you would do is to connect pins 30/31 and the Reset pin on each of these Propellers through 2.2K resistors to a group of three pins on the Master Propeller. You would have two PropPlugs attached to the Master, one on the usual pins for reprogramming the Master program and interacting with it and another on some group of three pins for controlling the Slaves. You could have up to 8 Slaves with the number of I/O pins available.

The Master Propeller could transmit to and receive from any of the Slaves. It could also download new programs to any of the Slaves using Chip's Spin download program (which can be found here: http://forums.parallax.com/showthread.php?p=591445). The 2nd PropPlug could be used for communicating with the slaves from a PC if you wanted with the Master program handling the switching between the Slaves.

ElectricAye

Mike,

Hey, I had heard this was possible but never knew what was involved. That's pretty cool. Thanks for explaining that.


To Krazy,
so this thread can be referenced in the future, could you please give it a more descriptive title? Just click on the pencil icon in the upper right part of the screen and, instead of Where do I start, call it something like Prop to Prop communications or something.

thanks,
Mark

Mike Green

Note: The Slave Reset pins don't need the resistors. If you put them in anyway, it should still work, but I'd recommend using the resistors only in the leads to pins 30 and 31 of the Slaves.

krazyideas

I think I'm getting in a little over my head here. I was trying to figure how this would work, but to no avail.
So before I begin to beat on this brick wall, I have one more question to make sure this will do what I want.

When I learn this trick will I be able to use the master chip to modifi a varuble that a slave is useing without stoping or restarting the slave?

Thanks

Cluso99

Are you just trying to communicate one way - master to slaves, or do you want both directions?

As a suggestion, initially forget about trying to download each slave. Use a propplug to load each slaves eeprom. This will make life simpler.

Now all you have to do is communicate with each slave from the master using FDX serial object. If both directions, you need 2 pins on each slave (say P30 & 31 which is also the download pins). On the master, you will need 2 pins per slave. FDX only handles 1 serial device (2 pins) per cog, and of course you will need a controlling cog (initially spin). So this will give you 7 slaves for starters. There are other objects which handle multiple serial ports per cog, but leave this for later if you require it.

This way, you can easily get your project running. Other things can be added later, such as combining pins and a protocol. But for now, keep it simple.

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

· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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

krazyideas

Thanks

I only want to be able to send from the Master to the slaves.

I will take a look at the links you sent me. Thanks a ton.
It is going to be a few days before I can check them out though, This weekend is crazy busy
Thanks

Mike Green

The Master cannot modify a variable in a Slave (unless you download a new program). The Master communicates with the Slave. The Slave has code in its program that listens for a message from the Master and the Slave modifies its own variables based on the messages it gets. For example, the Master could send the characters "1,1000.". The "1" means change variable #1. The comma acts as a delimiter between the two values and the "1000" is the value to set. The period acts as a delimiter for the 2nd value.

Clock Loop

Communication between props is simple.

I did a project that has 4 props all talking serially. 3 props talk to 1 central prop using serial at 115200 baud. No complicated coding is necessary, just copy the necessary memory from one prop to the next, you can pass values through props also, depending on your requirements, chances are 115200 baud passing of values is plenty of speed, even when propagating that data through a central prop.

http://forums.parallax.com/forums/default.aspx?f=21&m=376422&g=377275#m377275

Repeat   
  go := 0
  
  If Comm.rxtime(1) == 213     'this looks for start number of 213
    BpmStep := Comm.rx        'then receives data and puts it in variable BpmStep

  waitcnt(500 + cnt)  '      

  Comm.tx(214)           'this transmits for start number of 214
  Repeat go from 0 to 58        'this sets the range of memory locations I want to step through
    Comm.tx(Fx[noparse][[/noparse]go])     'this transmits that same memory range one byte at a time
    waitcnt(500 + cnt)  '1ms   'this waits 1ms to let receiver catch up.

And on the other prop

Repeat   
  go := 0
  
  Comm.tx(213)                        'transmit sync number  
    waitcnt(500 + cnt)              'wait for other prop to catch up
    Comm.tx(BpmStep)                 ' transmit BpmStep position
  
  waitcnt(500 + cnt)

  If Comm.rxtime(1) == 214 
                
    Repeat go from 0 to 58              ' get range of memory
      Fx[noparse][[/noparse]go] := Comm.rx 

Pretty easy to do and is fast enough for MY use.

ziplock

I was reading on the Arduino forums a while back, and a few people had the idea of using I/O lines for a serial bus.
I.E, you would dedicate anywhere from four to 16 I/O lines, and you would send individual bits out on each line (to form a serial data packet).
I really can't remember the exact details, but I believe it was faster than the maximum TTL serial speed of the ATMega168.
Anyway, it seemed interesting. If someone knows anything else about it, please post here.

-Adam

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hey! I'm Adam.
But YOU can call me ziplock.

Blog: braindrink.wordpress.com
"The only problem with the gene pool is that there is no lifeguard." -David Gerrold

Clock Loop

ziplock said...
I was reading on the Arduino forums a while back, and a few people had the idea of using I/O lines for a serial bus.
I.E, you would dedicate anywhere from four to 16 I/O lines, and you would send individual bits out on each line (to form a serial data packet).
I really can't remember the exact details, but I believe it was faster than the maximum TTL serial speed of the ATMega168.
Anyway, it seemed interesting. If someone knows anything else about it, please post here.

-Adam

Serial tends to use a single or even two wires. And the speed is limited.
The reason people use serial is because they don't want to use up I/O.

Any communication method can be sped up by running more lines of communication.

Serial requires processing power and strict timing.

What your talking about is basically a parallel data bus.

If you just search the forums for communication or similar keywords, you will see many results that talk about many different methods.

http://search.parallax.com/

One thing the prop can do is have four cogs all transmitting serial data out 4 lines. So your data is now transmitting 4 times as fast.

Post Edited (Clock Loop) : 10/18/2009 5:20:00 PM GMT