Fast Inter-Propeller Communication

synapse · 2011-01-13 05:36

All,
I am working on a project that requires many propellers to communicate back to a master propeller. I have tried several different methods one being the spin object in the title. However I found a problem and maybe it is the crystal I am using compared to the spin code in the download. After spending 2 hours tracking down why fullduplex serial wouldn't work for me because the _xinfreq was set to high in the download, and the default baud rate was higher than I expected. I finally got readable messages and unfortunately they all say wrong buffer. which of course if not correct. has anyone else got this code to work and if so has anyone else made any modifications to send strings and maybe use 1 cog instead of 3. I am willing to take the hit. I even tried FullDuplex serial between two propellers but that didn't work either. I must be missing something

Humanoido · 2011-01-13 05:50

You really need to check your wiring and post the diagram, even if you sketch it on paper and simply attach the photo. Also post your code so we can determine why it's not working with the buffer based on the data configuration you want to send and receive. There are other factors that determine whether this will work or not so this information is a requirement.

pjv · 2011-01-13 09:12

Synapse;

How much of a "hit" are you willing to take?

Or better to ask what byte or long transfer rate do you need? Sure, "faster is better", but there are implictions....

Cheers,

Peter (pjv)

synapse · 2011-01-13 09:25

Well let me back up. I will have the schematic and code this evening. I have 7 props talking. One of the props it talks to is the master so to speek. It gathers all the information and makes decisions and logs data to an sd card as well as transmiting all the data over an xbee. That part is done and the individual drivers for each sensor or action prop is handled. The final step is to get them all talking. Each prop has it's own set of 3 pins. On each prop connection to the communications prop to pins p30,p31 and reset. Speed is important and not. I don't belive any thing less than 9600 baud would work. But it could if it was reliable. That is the key.

Mike Green · 2011-01-13 09:54

Not knowing what code you're using and not knowing how things are hooked up, it's difficult to advise you. FullDuplexSerial is good to well over 115KBaud. The default buffer size (16) is a bit small at that speed and there are several variations of FullDuplexSerial in the Object Exchange that have larger buffers (typically 256 bytes). There are half duplex serial routines that work well in excess of 1MBaud, so raw speed is not a problem. The "Fast Inter-Propeller Communication" object is faster yet, but, like FullDuplexSerial or similar half duplex versions, is designed for a single Prop to Prop channel, not for a multi-drop setup (party line). Hopefully, your code and schematic will show us what you're trying to do and we can offer some specific advice.

Bobb Fwed · 2011-01-13 16:25

I am the author of Fast Inter-Propeller Communication. I think I received an email from you regarding the same issues (or at least I received one from someone this morning). The most common problem is with software timing. If not done correctly, wrong buffer will always display in the demo. It is better to test the setup using known data and see if the data sent is the same as the data received. The buffer test included in the demo expects both propellers start sending and receiving at the same time (which is the case in the demo, because it using two cogs in a single Prop).

As said before, wiring and code would be very helpful to help diagnose.

I've recently worked on a new version of the object re-written from scratch which address a timing issue (not the one above) and a RAM alteration problem. But as is, I use the software in a few personal projects. I hope to make the new version more robust, with a better inferface, to allow use with some more industrial Prop communication projects I have in the works. This new version is weeks out though; I have other things on my plate at the moment.

synapse · 2011-01-13 23:43

Yes I did send you an email but I also posted here. I have emailed others in the past with no results so I always double up my effort in my search for an answer.

I have attached the schematic.
I do not have the reset transistor in line that is for use later. for programming.

Primary Propeller Code

IC.start(19, 20, 0, SerialComBaud) 
repeat
...
      IC.str(string("m"))  
      repeat while IC.rxcheck <>-1
          c:= IC.RX
          xb.tx(c)

secondary prop

CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

  'Serial
  SerialComBaud = 9600
  

   
OBJ
  IC : "FullDuplexSerial"      

VAR
  long drougeD
  long mainD
  long rxchk
     
DAT
        b byte "f", 0
                                                                                                                                                                    
PUB Main
  drougeD:=0
  mainD:=0
  dira[16]~~ 'Drouge Pin
  dira[17]~~ 'Main Pin
  OUTA[16]~ 'Drouge to low{Not Active}
  OUTA[17]~ 'Main to Low{Active}
  
'OUTA[pin]~ 'Make P10 low
'OUTA[pin]~~ 'Make P10 high
     
  Init
   waitcnt(2_000_000 + cnt)
  repeat
    rxchk:= IC.rxcheck
    ifnot rxchk==-1 
      b:= IC.Rx      
      if strcomp(@b,string("v")) 
        IC.str(string("V:aXon OS - DualDeploy v1.0.1"))
        CRLF
      ELSEIF strcomp(@b,string("m")) 
        !OUTA[17]      
        mainD:=0
      ELSEIF strcomp(@b,string("d")) 
        OUTA[16]~~
        drougeD:=0          
      ELSEIF strcomp(@b,string("r")) 
        REBOOTALL                        
      ELSE
        IC.str(string("E100 Bad Command"))
        CRLF           
    ELSE
      'Send Drouge Status
     ' IC.str(string("1:0:"))      
      'IC.dec(drougeD)
      'CRLF
      'IC.str(string("1:1:"))
      'IC.dec(mainD)
      IC.str(string("V:aXon OS - DualDeploy v1.0.1"))
      CRLF 


PRI REBOOTALL  
  REBOOT   
                   
PRI CRLF  
  IC.Tx(10)
    
      
PRI Init  |r
  IC.start(30, 31, 0, SerialComBaud)

Dr_Acula · 2011-01-14 06:15

I've done a bit of comms work with wireless. I've learned the hard way:

1) one way comms with wires and leds and slow baud rate
2) two way comms with wires
3) wireless

I'm trying to figure out your schematic. I see a transistor, but there is no resistor on the base, and I'm not even sure from the schematic if propeller 0 is the master or propeller 1 is the master?

Can you explain a little more?

I think we can get this working but it might take a few steps along the way. I once had to drop the baud rate to 110 to debug something, and heck, I even went to 1 baud once. At that speed, with a LED, you can read the bytes yourself!

Leds on data lines do help too.

Do you have a schematic, even scribbled on the back of an envelope, that you could scan in? Or a photo of the layout? There are some things missing on the schematic posted above, maybe they are there and maybe not on the real board? Boring things like bypass capacitors.

I'm sure we can put our collective brains together and get this working! It sounds a very interesting project.

Bobb Fwed · 2011-01-14 08:16

I think your base and collector are swapped on the reset transistor, and like the Doctor said, you need a resistor on the base. But depending on what software you are using (the boot loader?) you can drive the reset of the second propeller directly. Also, why do you have P21 wired to Vdd? I know this isn't why you posted the schematic, you want help with the object, and I will look into that.

synapse · 2011-01-14 08:26

ok So I have updated the schematic to show more of the exact way it is hooked up right now. the transistor will be added later after I get basic communications worked out for the ability to flash the eeprom on p1.

To answer the question about the vdd on p21. that is kinda how I am going to know if additional boards are hooked up. so This will be a stacked type system if I add an additional sensor it is meant to be generic at the master level. I removed it for now because it is unimportant to the problem at hand. Basically I don't want to eat up a cog if it doesn't need to and waste battery if it doesn't need to. that is long term right now I just want the two props talking. so My plan was to check that ping for high and if it is high then init if low don't.

I have some videos explaining this in detail on my website what my long term goal is at www.synapsesg.com

The only difference I have right now on my breadboard from the schematic is instead of pins 30 and 31 on p1 I am using p0 and p1. I was running into issues having to disconnect wires every time I wanted to load new firmware.

Cluso99 · 2011-01-14 19:06

SDA requires a pullup, not pulldown. I presume this is a schematic error.
Really, fdx should work fine - use my "rr004" version with the buffer size set to 256 (note 512 does not work). It's in the obex.
If your spin code takes too long to take the bytes received out of the buffer you could overwrite the buffer (and lose a buffer full of characters).
Sorry I don't have the time right now to look at your code. This problem is definately able to be resolved.

synapse · 2011-01-22 12:17

Cluso99 wrote: »

SDA requires a pullup, not pulldown. I presume this is a schematic error.
Really, fdx should work fine - use my "rr004" version with the buffer size set to 256 (note 512 does not work). It's in the obex.
If your spin code takes too long to take the bytes received out of the buffer you could overwrite the buffer (and lose a buffer full of characters).
Sorry I don't have the time right now to look at your code. This problem is definately able to be resolved.

thanks that was it I had the resistors in pull down not pull up thanks

BigFoot · 2011-01-23 09:58

We are just about ready to start fooling around with this. My new board has an 8 bit data bus and two handshaking
lines between the Prop 1 chips. We are not sure how many of the data bits we will use on the production board but
will keep you updated on the progress.

Fast Inter-Propeller Communication

Comments