Connecting multiple props together
DiverBob
Posts: 1,097
in Propeller 1
I am in the process of connecting 6 individual RoboPi Propellor boards together along with a master propellor board. I have a seperate transmitt and receive wire coming off the master and then connecting to the same data pins on each board. So the master can transmitt a request ($,board#) and then waits for the response. The individual RoboPi boards will only respond if they are selected and then they should send a response back to the master.
The code works great if only one RoboPi board is connected to the master but as soon as I add another board the code no longer works. It doesn’t matter which RoboPi board is connected, it just can’t be more than one connected for it to work. The wire connections are made directly to the propellor pins designated for RX or TX. Based on the symptoms I believe the problem is the wiring setup. I verified the wires on the cable are not open or shorted. I did a search in the forum but was unable to find anything outside of single prop to prop communications. Do I need some type of termination on the line or not? I will continue to test and experiment but was hoping someone else has an idea.
The code works great if only one RoboPi board is connected to the master but as soon as I add another board the code no longer works. It doesn’t matter which RoboPi board is connected, it just can’t be more than one connected for it to work. The wire connections are made directly to the propellor pins designated for RX or TX. Based on the symptoms I believe the problem is the wiring setup. I verified the wires on the cable are not open or shorted. I did a search in the forum but was unable to find anything outside of single prop to prop communications. Do I need some type of termination on the line or not? I will continue to test and experiment but was hoping someone else has an idea.
Comments
PS - Unless you want one slave to answer while the master is sending to another.
Corrected "output" to "input"
What you need to do, depends on how the driver was written.
If it makes no effort to tristate or open drain the send data from the slaves, you will need some means to handle/avoid one slave's low trying to drive other slaves 'hi's.
That cold be a schottky diode to each slave and a common pullup. Then only the sending slave pulls the master RX low and the one idling hi, have no effect.
which node drives or use open-drain/wired-and/wired-or. Or you can add resistors at each node and do collision
detection (which needs some means of sensing voltages in the middle).
I've been running with separate wires for rx and tx so I wouldn't need complex coding to prevent signal issues but in the course of fixing these issues I've essentially created the framework for full duplex operation over a single wire. Now the master polls for a specific leg, the leg responds, and then the master polls the next leg. So data collisions shouldn't happen with this setup anyway. Now if I can just figure out the rxtime command I'll be all set up!
Bob
If two or more modules were inadvertantly set to output at the same time the net result would be zero and no harm done.
there is contention. The protocol you chose/contrive is what prevents contention. Some protocols
don't even prevent contention, but snoop on the line to detect contention. There is clever use of
contention in the OneWire device discovery protocol, for instance.
The commonest bus arrangement is master/slaves, with the slaves only responding after a request
from the master, and the master arranging to give commands and allow time for slave responses.
This requires each slave to have a unique identifying number or address so only one replies at a
time.
This is basically the protocol I am using now. It works, at least with a single slave so far!
I’m going to give these ideas a try and see what happens.
Just one on the master side is fine.
To help with scope probe testing, you can do a (eg) 3k3 pullup, and a 33k pulldown.
That idles at Vcc - 0.3V, which is comfortably logic 1, but you can now easily see on a scope when the slave enables and disables the tristate drive with this scheme.
Unfortunately I am getting the same results where a single slave hooked up works great but as soon as I add a second slave, neither slave outputs back to the master.
With this setup I essentially have a single slave as a transmitter and all the other slaves and master is an input (with only the master actually listening at this point), very similar to the setup where the master is transmitting to all the slaves at one time and the slaves just listen for a command that pertains to them before they react. This works fine on one port of the 4 port serial object but not on the other port.
What does a scope say about the slave-RX side loading ? Can you parallel slaves ok, and have a clean slave-RX ?
Here is the master and leg code with the current changes in place.
I added some debugging statements to the leg code where I could see the incoming requests from the master and the response from the leg. With this running, if I plug in another leg to the master transmit wire (pin 9 on master to pin 2 on leg), the results are that the leg that was working no longer works and the PST output no longer shows the data requests from the master. Removing the wire from pin2 restores the feed again.
I'm at a loss to explain why this is happening with all the leg pin 2 being inputs and just waiting for their leg to be called.
Bob
I need to break the scope out again, haven’t used it for anything serious for quite awhile!
I’ve also been reading as many of the old threads on serial interfacing as I can find to see if I can get a hint on which direction to go next. If I can’t resolve this problem I may have to resort to putting in another 4port object and dedicate seperate pins on the master for each leg instead (I need to check if I still have and extra cog available). Going to keep researching and hopefully either find a solution or someone might have an idea.
The scope may think you have a x10 probe, when you actually do not... ? (often there is a tickbox for that)
Sounds like a simple loading issue.
The Send side may have a deliberate large series resistor, and the receive sides may have already pullups or pulldowns. Trace the exact wiring.
What baud rate is this ? - Slow it down during tests, then speed it up later.
Enjoy,
Mike
I used the 4 port serial setup so port 0 is communications to the computer terminal (troubleshooting purposes), port 1 is a dedicated master transmit wire that puts out the leg movement commands to the leg computers.
Port 2 is a feedback loop where the master queries the individual legs and then the leg sends back a response. When I was running the feedback loop in its own cog I needed the seperate port so it was independent of the movement. I still need to get all the movement commands out to the legs quickly but there is a delay between the movement request and completion of a mechanical movement. Now that the feedback and movement request commands are in the same main event loop I need to think this through and see if there is a better way to get the feedback information without delaying the movement requests.
I uploaded a PDF of a drawing of the port configuration a couple of posts ago, the Master Tx (pin 11) is port 1, it works just great, no issues encountered with it. There are no resistors in series with the wires, only 10K pull-ups on Port2 rx and rx lines. Port 2 is where I have the problems, its got to be something in the code that is wrong, I’m just not seeing what it could be at this point. The wiring has been verified several times and if only one leg is connected (doesn’t matter which leg is connected) the code works. It’s only when I add the second leg computer that it stops working. Very confusing at this point for something that should be fairly simple.
Probably not your problem, you could try my setup and see if you can get it to work.
This would at least allow you to see conflicting props stomping on each other without the hardware fighting also.
(one prop tries to pull the tx line high while another pulls it low, this causes serious hardware and software malfunctioning, from my experience, and required a full reset of all props to get the system working again)
Also SLOW the baud speed wayyy down at first, till you get it right, 9600 or something.
https://forums.parallax.com/uploads/attachments/43620/76285.pdf
Link to the related forum post is in my signature.
Take a multimeter on 200 mA range, and connect to pull down the RX line(s) thru the meter for one and two connected boards. A 10k resistor alone will measure 330uA per load.