Propeller to Propeller communication...ease vs. speed

cbmeeks

I've got a little side project I'm working on that will link several propellers together in a master/slave scenario.

So there would be one overall master propeller that would send commands to each other propeller. Each propeller "sub-system" would have a cog running that would accept commands and then boot or shut down the remaining cogs depending on what it would be doing.

The communication would need to be bi-directional. So the slaves would need to acknowledge the command it received from the master, provide data back to the master, etc.

It appears that I2C would be good for this but I'm concerned with the speed. One propeller would be nothing but video and the other nothing but audio. So speed (especially on the video) would need to be fast.

I've seen several suggestions on the forums. But what do you suggest in such a circuit?

Maybe something "established" like I2C/SPI for the slower communications and something custom for the video?

Thanks for any suggestions.

gis667en11

Some guy named Beau came up with a propeller to propeller serial communication object that runs at like 14Mbaud.

Mickster

gis667en11 wrote: »

Some guy named Beau.

LOL, Beau Schwabe is a highly respected former Parallax Engineer.

DavidZemon

Had to dig this up from stone age. Long before I join
http://forums.parallax.com/discussion/99222/propeller-demo-14-5-meg-baud-high-speed-prop-to-prop-serial-communication

jmg

cbmeeks wrote: »

I've got a little side project I'm working on that will link several propellers together in a master/slave scenario.

Do they share a common Crystal or Clock Source ?
( a 1GU04 should buffer one Xtal to feed others)

With a common CLK source, you can use WAIT and a handshake line to sync things up, the you know the bit-phase for fast transfer, which does not need to be byte-sized.

JonnyMac

You could do something as simple as half-duplex serial over one pin (use open-collector setup to prevent buss shorts). I do this with Propeller-to-Propeller all the time.

If there's any sort of distance involved, you could use three pins an run an RS-485 network.

In either case, it's just serial. I have a half-duplex driver that switches the RS-485 chip into transmit mode as required. After all bytes are transmitted it returns to receive mode.

Your biggest task is creating a protocol for data exchange, and that's not a big one. I wrote a parser last year that I often use for handling string commands. The parser doesn't care where the strings come from. I put this to use in a simple network for a friend. The nice thing is that all the commands are text based so testing can be done through a simple. For fun we did very simple stuff like this:

CMD 1 HIGH 8<CR>

The first token, CMD, is the header from master to slaves. The next token is the slave ID for the command. After that comes command tokens and parameters. The command above would make P8 on unit one an output and high (I'm sure you deduced that). The master could request things, too. On the board he is using there are eight inputs, hence

CMD 1 INPUTS<CR>

...will ask unit 1 for its inputs. If all inputs are low, you'd see this:

RSP 1 INPUTS %00000000<CR>

...where RSP is for response, followed by the unit #, the command, and the value for it.

My parser understands decimal, binary, and hex formatting of numbers, and takes care of the conversion -- you just have to establish your own rules set.

These are just ideas. I have fun making little command processors like this. The Parallax badge code uses my parser to process text commands for a terminal or from the BadgeHacker software.

Peter Jakacki

Rather than open-collector just consider using a series resistor to limit the current in case of contention, a value of 220R is fine. If you use RS485 you only need 2 I/O, the common RX/TX you would use in a single wire network as just mentioned plus the other I/O controls the RE/TE line which should have a pulldown on it so that its default state is receive.

cbmeeks

Thanks for the suggestions everyone!

Rather than open-collector just consider using a series resistor to limit the current in case of contention

That's a good point. I was going to ask in a followup question...but what would happen if two (or more) props accidentally (through bad programming) decided to light up the same pins at the same time?

I can't imagine that would be OK. Is there a schematic somewhere for handling this that I could study?

Thanks!

kwinn

cbmeeks wrote: »

Thanks for the suggestions everyone!

Rather than open-collector just consider using a series resistor to limit the current in case of contention

That's a good point. I was going to ask in a followup question...but what would happen if two (or more) props accidentally (through bad programming) decided to light up the same pins at the same time?

I can't imagine that would be OK. Is there a schematic somewhere for handling this that I could study?

Thanks!

It may or may not damage the pin. Luck of the draw situation. That's why a series resistor is a good idea.

JonnyMac

I don't use the 220s in my own projects (living dangerously), but they certainly won't hurt anything. Assuming FullDuplexSerial is your driver of choice, you would start it in each device like this:

fds.start(SIO, SIO, %1100, BAUD)

...where SIO is the pin to use for serial (half-duplex, open-drain) and BAUD is the rate.

TurboMan

I went out and read through Beau's link http://forums.parallax.com/discussion/99222/propeller-demo-14-5-meg-baud-high-speed-prop-to-prop-serial-communication . I couldn't find the actual code and I also searched in the OBX. Could someone point me to the actual code that was used? This is of great interest.

Mickster

I have attached Beau's code.

@All
I don't seem to remember any mention of checksumming. Is this deemed unnecessary?

Cluso99

IIRC Beau did a huge test and there were zero errors. But the props were very close.

ie Don't use long wires!

Mickster

Cluso99 wrote: »

IIRC Beau did a huge test and there were zero errors. But the props were very close.

ie Don't use long wires!

Yeah, I remember that but I believe that he tried with a good length of wire with the same result.
My checksum question was regarding serial comms in general. I don't recall it ever being mentioned.

TurboMan

Thanks Mickster. I will do some testing. My board has 3 props within an inch of each other. The fully populated system will have a total of 5 and all connected through trace or pass-through connectors in a small enclosure. Communication net length shouldn't be a problem and the 3 main props are all on the same clock. Hopefully this will give me something to start with.