Two Props Communicating?

Kirk Fraser

I have my first two propellers wired according to the diagram in the Propeller Manual. I'm wondering how to wire them for communication. Is it correct to just wire the 4 lines GND, RST, Tx, Rx from each chip together in parallel? Should the Tx and Rx be reversed? What if there are 10 Propellers?

The Alternative Serial Port Connection in the Data Sheet like the Prop Plug would put the communication all in a PC having many ports. I want one computer port accessing my Propeller net with individual access to the cogs by software, if possible. How do I accomplish that?

Thank you.

Mike Green

You can't just wire a bunch of Propellers in parallel with the RST, Tx, and Rx connected to each other. If you wire all the RST lines together, grounding that will cause all of the Props to reset and they'll all try to start communicating with a PC attached to Tx and Rx to see if there's a program to download from the PC. That won't work very well. In particular, wiring the Tx pins together could possibly damage one or more Propellers as they try to send different data simultaneously out the Tx pins. One Propeller will try to drive the Tx line high while another Propeller may try to drive the Tx line low ... that's a short circuit.

You need a separate RST connection from each Propeller to the PC's DTR line and you need a separate Tx connection from each Propeller to the PC's Rx line. You can connect all the Rx lines from the Propellers together to the Tx line from the PC.

NOTE: When I talk about a connection between a PC and a Propeller, I don't mean a direct connection. You'll need some kind of voltage translation interface, either the 3 transistor circuit downloadable from Parallax or an interface using a MAX3232 to interface the PC's serial port's RS232 signals to the 3.3V logic signals of the Propeller. If you leave this out, you'll destroy the Propeller(s).

The above is about connecting one or more Propellers to a PC for programming purposes. If you're just going to send data back and forth among the Propellers, you don't need the RST connection. You can also use an open-collector non-inverting buffer in the Tx leads to make a party line so that any Propeller can send to any other as long as only one is sending at a time. You can also use RS-485. This is similar to what's shown in the Nuts and Volts columns (#55 and #56 here) for use with a Stamp. The same idea can work with a Propeller.

th3jester

For the senior design I just finished, I have a Propeller USB board communicating with a Spinneret board ( another propeller board). They talk continuously back and forth with a little error between communication as I didn't implement error checking as it wasn't needed. I will share my code if needed. The connections for this are simply 2 wires, a TX pin on one Prop goes to the RX on the other and vice versa. Errors can easily be reduced by reducing the amount of data sent, i.e.- I am sending 10 longs in a buffer, if you reduce that to 1 long then there is almost no error. This is similar to the way the Prop communicates to LabView via USB.

Kirk Fraser

Thanks for the insights and reference Mike Green and th3jester. It looks like the RS-485 network would serve when I move to nearly a dozen Props but for now I'd appreciate th3jester's code to start smaller.

I once communicated between a BS1 and my computer with one wire using something very simple like the Serin and Serout commands. It didn't do much, only transmit a string, but that would be enough. I'm concerned about the short problem Mike mentioned using that approach. I could daisy chain the network using serin on one pin and serout on the other, then pass legal data but process packets with the correct address. That might make the network slow but it should take care of trying to overwrite data as it's passing through without an interrupt. Would a one wire daisy chain work as good as the RS-485? I suppose not, I'd need at least a second pin to tell if the cog is ready to receive.

I don't know how to detect errors lower than the character level. Should I add the CRC object to reduce packet errors?

Basically my project is a robot with lots of joints. I want the computer to display each position in real time and take position commands too. So my data will be brief but often continuously changing. I'm not sure what speed it would need to communicate at but getting around the whole network seems like a bottle-neck.

th3jester

Here is the code I use to communicate between two Propellers. In the VAR section you will have to create the arrays for the buffers. You can also take out the repeat k from 0 to 8 and just have the send and receive commands. That will only transmit and receive one long though, but it causes less errors.

The below goes into one Propeller.

PUB Communicate | k 

'''''''''''''''''''''''INTER-PROPELLER COMMUNICATION'''''''''''''''''''''''''''''''''''''''''''''''''' 
 waitcnt(clkfreq + cnt)
Repeat


   TxRx.str(String("!v=")) 
  repeat k from 0 to 8                     
    TxRx.PutLong(SData[k])
  repeat k from 0 to 8 
    RData[k] := TxRx.GetLong

The below goes into the other Propeller.

PUB Communicate | i

Repeat

        
   TxRx.waitstr(String("!v="), clkfreq*20) 
   repeat i from 0 to 8  
      RData[i] := TxRx.GetLong
   repeat i from 0 to 8                    
      TxRx.PutLong(SData[i])

To communicate with a computer without using the Parallax Serial Terminal (or other terminal programs), you could use the same code used for communicating with LabView. Just remember that the Computer will be acting like the Master and the Propeller is the Slave, so the Computer program you will be using needs to send the "sync" pulse first. Here's what the code looks like on the Propeller.

ser.waitstr(String("!v="), clkfreq*20) 'wait till sync string is received 
   RData := ser.GetLong                   'send RData to LabVIEW, 32-bit long
   ser.PutLong(SData)

The computer program needs to transmit the string "!v=" and then transmit data and then it receives data.

Interconnecting several Propellers.....not too sure how to do that, maybe 1-wire or an I2C setup. I agree with Mike that you have to be careful about shorting the pins.

EDIT: Most errors are caused by collisions which are usually caused by incorrect timing. If the timing is dead on then there shouldn't be a lot errors, you will have to deal with errors cause by outside noise. I've tried using a CRC yet was unsuccessful with it.

Kirk Fraser

Thank you th3jester. It looks like your sync bytes travel on the same wire which make it easier. It looks like if I have one cog do the network, broadcasting the other cog's data, that's most of what I need. Your CRC experience saves me from wasting time.

If I wait for the sync on each chip interpreting it as a clear to send it would still potentially have collisions. So it looks like I'll need to lock out all but one at a time in a sequential pattern like the cog hub switch.

I'll have to read the RS-485 article more carefully too.

th3jester

Notice the first two blocks of code I posted. Only one chip will be waiting for the sync pulse. The other chip is sending the pulse. You are correct in that if you have both chips waiting and sending the pulse then there will be collisions.