Is there a better way to network multiple propeller boards?
DiverBob
Posts: 1,109
in Propeller 1
I have been building a large hexapod for the last 4 years and it uses one propeller board for each leg. I plan on using a separate propeller as a master computer to control the 6 leg computers and another prop board for accessory control. Right now I'm using a 4 port serial object but wanted to explore some other methods of control. The 4 port serial object has each slave prop wired to its own dedicated Tx and Rx line on the master for communications. This method requires 1 cog for every 4 lines, not a problem on the slave boards but I'm running out of cogs on the master.
Before I commit to a specific design, wanted to see what other methods have been used successfully. The speed of the Rx/Tx is not critical since the transmitted commands cause DC motor movement (much slower process) although faster is nice. I've searched and seen several items along this line in the past but the new forum makes it difficult to do the same type of searches in just the prop forum.
Any suggestions are welcome!
Bob Sweeney
Before I commit to a specific design, wanted to see what other methods have been used successfully. The speed of the Rx/Tx is not critical since the transmitted commands cause DC motor movement (much slower process) although faster is nice. I've searched and seen several items along this line in the past but the new forum makes it difficult to do the same type of searches in just the prop forum.
Any suggestions are welcome!
Bob Sweeney
Comments
http://forums.parallax.com/discussion/134641/demo-high-speed-multi-prop-to-prop-communication/p1
Really looking forward to seeing the roving hexapod. Sounds fantastic.
@DiverBob,
I played around with @Beaus code. You need two cogs for each board and the propeller boards are basically connected as a ring. One pin in, one pin out.
If one fails the whole communication behind that one fails. Your master can detect the failure and stop moving.
The basic idea is to 'share' a common HUB buffer between all Propeller Chips. It gets just send around and around. Each Propeller can read or write any location in the buffer. But it makes more sense to set up certain areas inside the buffer as dedicated to one Propeller.
In a sense like a usual 'mailbox' address works with assembler COGs.
Instead of sending commands serial your master just writes in his own hub and Beaus driver runs this over to all the other ones. And as fast as props can.
I think this is very useful for multi Prop communication.
But you need two COGs and two pins per Propeller and enough HUB ram left in all of them for the common buffer.
As for the programming it is as cool as possible. Your master writes some command in his HUB and all clients can read it out of their own HUB.
The common buffer is a HUB memory part shared between Propeller Chips like the normal HUB is shared between COGs.
Enjoy!
Mike
Sorry but, where is the source ? I can't find it on the thread nor on obex...
Even if you use simple 8-bit data you can use some of those as address and control especially from $80-$FF codes if all data is encoded as ASCII characters. Software simply looks for an address character that matches its address and accepts the rest of the stream up until another address or special control character. KISS.
If you avoid FDS and use a serial driver that either transmits or receives then you can easily achieve baud rates >1M baud with nice clean timing. I can clean up a serial driver I have and post it here but I will be very tied up for the next couple of days though before I can get around to it.
BTW, that could just as easily have 9-bit mode so you can still send any 8-bit character as data or whatever whenever the 9-bit is set which looks like a stop bit to any 8-bit device but if the 9-bit is low then we can interpret the 8-bits as and address or control character.
Youll find it in that thread. Just read on through a bit.
I believe the attached file is what you are looking for.
The communications protocol right now is pretty basic, I transmit and receive the following string sequence, '$,leg number, command, value'. An example would be '$,1,2,305' means for leg 1 tibia motor to move to 30.5 degrees. A common return value from a slave would be '$,2,3,20'. This tells the master that leg 2 coxa completed a move.
With the current configuration the master is the center of a star network with independent lines to each slave. I was thinking of 2 possible methods. One is using separate TX and RX lines that either daisy chain through each slave where if the message is sent to the 3rd slave, the first 2 slaves push the string down the chain until the requested slave gets the command. Another method could be to have each slave read the output command at the same time over a bus. I can think of some pluses and minuses for each method so wondered how other people solved this kind of problem and their results.
Time to get away from programming for an afternoon, the lake is calm so off for some shipwreck diving!
Of course each slave could just receive everything that is sent from the master but you will still need an address field either way.
I think the new forum software stirred it up a bit. I posted the original zip.
EDIT:I also emailed Parallax to add it to the OBEX under the Perry Parallax name.
That sounds interesting, do you know where I can review some code using this setup?
Depending on what 'large' means here, you may like to get a little ground-tolerance with motor power involved.
As well as RS485 mentioned above, CAN bus transceivers give similar ground tolerance, but have a simpler termination scheme as their threshold is offset.
Half duplex is likely fine for your messages, as you send a small packet, and get back an ACK packet.
A simple timeout can sense no-slave cases.
The master knows slaves only echo a reply in response to a query, so if the BUS is free, it is free to talk.
After a message is done, the master does have to receive the expected number of bytes, or wait a minimum time, to keep in phase with the packets ping-pong.
Multi-Master is trickier, and a transceiver like CAN can show contention.
The TX routine checks the RX pin, and if the pin is <> Expected, thensomething else is driving the BUS.
You can use FullDuplexSerial.spin for the Master and the Slaves. The mode parameter lets you set open-drain mode, so you can just connect all together on a single wire.
Another mode bit allows to ignore the self sent data, which makes it easier.
So the connection is:
3.3V | [R] 4k7 | --+-----------+-----------+---+-- | | | .--+--. .--+--. .--+--. | pin | | pin | | pin | | | | | | | '-----' '-----' '-----' Master Slave Slave The FulldupexSerial start: fds.start(pin, pin, %1100, 38400)This uses the same pin for rx and tx. 38.4 kBaud is just an example.Now you need to add a Slave Address to your little serial packets:
'$, slave addr, leg number, command, value'
All slaves will receive all packets and check the slave-address to know if the packet has to be processed or not.
To prevent several slave sending at the same time, the master can send a query, for example:
'!, slaveAddr'
Then only the addressed slave sends its status, and only if he got the query from the master.
-Andy
In your example the master initiates all communications by either sending the specific packets or requesting feedback from a specific location, the slaves do not independently initiate communication back to the master. Since I want the slaves to report back when error conditions are identified (such as a leg is not moving or encounters an obstacle) I could set up where the master continuously queries the slaves one at a time for a report whenever the master isn't sending out commands. Hmmmm, something to think about. Thank you for some insights!
Bob
If you want that Slaves can send without a query from the Master, here is another insight:
If you don't set the mode-bit 3 at FDS start, then a slave receives the packet back that just was sent. If two slaves send at the same time the serial packets get corrupted. Because the rx part gets the signal from the bus wire, the received back data is also corrupted. So you can compare the sent and received bytes. If they are identical there was no other slave sending at the same time.
If the data is corrupted, you have to send it again after a short delay. These delays must be different for the different slaves, otherwise they just try again and again at the same time.
The master must also recognize that the data is corrupted, for that you can add a checksum. Just add all bytes together and send the result as additional byte in the packet for example.
Now we are close to real fieldbus...
Andy