AppNote Content Input Request: Propeller to Propeller Communication

Ken Gracey · 2011-05-11 09:17

Parallax Semiconductor received several requests for creating an AppNote detailing various Propeller to Propeller communication examples. Since the subject is very broad and full of possibilities, it may be important for us to break it into smaller pieces which can be used alone or build upon a larger, robust approach. Some lower-level objects are likely already in the process of Gold Standard verification.

We would like your input on the content of this AppNote before we begin any planning.

Please provide any input on communication protocols (async, I2C, RS-232/485, etc.), using buffers, and what types of examples would be beneficial. We are also interested in the type of application - are the two Propellers on the same product, or is the use more of a product to product communication?

We would allow this thread to collect some comments before we develop the scope of the AppNote(s) around the subject.

Thanks,

Ken Gracey

Bill Henning · 2011-05-11 09:23

Suggestions:

- quad serial object
- half duplex RS485
- 100kbps/400kbps/1mbps I2C slave, master
- SPI slave/master
- Beau's 14Mbps throughput (20Mbps clock) high speed serial

Very nice to have:

- CAN bus support
- Modbus support
- ENCJ TCP/IP support
- WIZNET TCP/IP support
- XBee / ZigBee support

trodoss · 2011-05-11 13:51

WPAN (Bluetooth) support would also be nice to have as well.

Tubular · 2011-05-11 22:02

Ken

I don't think product-to-product communication is difficult - generally there is distance involved, so something like ModBus over RS485 might be applied.

Most of the time a second prop is being added due to running out of cogs, or running out of ram. These causes may be best handled by two different application notes.

A common cause of running out of ram is due to a big video bitmap consuming 20-24kb of the available 32kb. I would like to see an application note where a master prop loads a slave prop to be a slave video generator. The slave would not have an EEPROM but be loaded via its P31, P30 and Reset pins from the master prop. Once up and running the slave would receive display commands from the master. Structuring it this way would also allow the 'slave prop' to be controlled by any other master, such as a PC or other micro.

At the moment the information required to achieve something like this exists, but is very scattered - some is in the obex (eg Chips Prop Loader), some in various forum threads, and I saw at least one document someone had produced about loading props. It would be good to draw it all together into a single app note.

prof_braino · 2011-05-12 14:37

The propforth is not yet in the obex, as the author considers the package as a whole to be still under development; I don't know if this is something you want to consider. Just in case:

The propforth solution to prop to prop communication is stable and the examples are in the release archive from Google Code. It uses a synchronous serial channel running at clock speed.

In propforth, one cog handles communication between the user and the cog running an application, usually the forth interpreter by default. To the user it appears that communication is between the user terminal and cogs 0-6, while in fact cog 7 manages communication between the user terminal and whichever cog 0-6 is connected to the channel.

In a multi-prop configuration, cogs still handles communication the same way. Another cog, perhaps cog 6 handle communication to the secondary prop. The user can connect to the cogs on the secondary prop using the same interfaces as the first, so the transition to the second prop is transparent (after establishing the channels).

A single prop appears to have seven free cogs, 0 to 6. Adding a second prop costs a additional cog on the primary prop for the communications channel, leaving cogs 0-5 on the master and cogs 0-6 on the slave, for a net gain of 6 cogs, making 13 total.

I was able to get the example to run the forth prompt on the secondary props cogs, to the user it looks like there are a bunch more cogs and a boat load of extra pins. But I have not made any demo applications yet. If any of this material is suitable for your purpose, we can talk to Sal Sanci and work something up.

Cluso99 · 2011-05-14 19:32

Prop to Prop comms should be simple. There is no requirement for it to be I2C or SPI or any of the more complicated protocols. That just slows things down because you can expect that some apps will require high speed.

The simple FullDuplexSerial ("FDX") is quite OK for speeds to 115,200 baud. However, FDX needs the mods to enable larger buffers (see the Obex for my FDX_rr00x version which fixes this).
FDX can be used with RS232 or RS485 drivers for remote props, whereas directly linked for local props (local does not have to be in the same box).

For higher speeds, Beau's code would be better and I like the 32bit transfers. I had in mind to write a 12bit transfer, so it might be an advantage if the bit trasfer size could be modified (set initially?).

I think there is a need for a multi-port serial driver such as the 4 port one in the obex. This could also be used for prop-prop comms.

Lastly, there may be a need for a multi-dropped serial driver where we have many props connected.

Downloading also needs to in the app note (or a different app note) because in professional use, it is likely for multiple props that only 1 eeprom would exist.

John Abshier · 2011-05-14 20:00

The Camelion (spelling) uses a Prop as a slave for graphics and other I/O. It could be updated for Prop to Prop.

John Abshier

jazzed · 2011-05-15 07:25

Choosing a method depends on the requirements. Here's a little matrix to consider as a general starting point. Rows are communication types, columns are attributes, and cells are fitness of the type to the task.

Type Comm/Attribute/Fit     Economy Speed   IO      Nodes   Multi-Master

1.   2 Way Serial Ring      High    Low     High    High    High
2.   N Way Serial Mesh      Med.    High    Med.    Low     High
3.   I2C                    High    Low     High    High    Low
4.   SPI (WIFI, etc...)     Low     Med.    High    High    Med.
5.   10 Pin Parallel Bus    Med.    High    Med.    Med.    Low

Economy is cost rating, Speed is "IPC" Inter-Propeller-Communications, IO is amount of IO left after IPC connections, Nodes is number of propellers, Multi-Master means ease of having more than one IPC "initiator" such as a client/server network or a primary/secondary interface.

Humanoido · 2011-05-23 06:37

Prop to Prop communications should encompass multiple props and cogs, inclusive of unlimited large numbers of Propeller chips. Apple is already using Intel Quad cores and now has a new OSX incorporating full use of multiple core technology for example. Propeller AppNotes should address a multi-prop configuration just as the BASIC Stamp is addressed in a multi-stamp configuration for serial communications.

BigFoot · 2011-05-25 12:21

We have been fooling around with an 8 bit parallel prop to prop interface. A rough schematic is included.z

jazzed · 2011-06-03 10:12

BigFoot wrote: »

We have been fooling around with an 8 bit parallel prop to prop interface. A rough schematic is included.

Just curious. What drives your pin selections in your schematic?

BigFoot · 2011-06-04 20:02

jazzed,

The pin selections were made so we wouldn't have to change allot of existing code.

idbruce · 2011-07-09 17:22

Ken

It is nice to see that you seriously considered writing an app note for this subject. I truly believe it is in Parallax's best interest.

As you know, I am not a microcontroller guru like some of these guys, so the protocol issue is way over my head. However you did ask:

We are also interested in the type of application - are the two Propellers on the same product, or is the use more of a product to product communication?

I am personally interested in both. Thanks for your interest and attention pertaining to this matter. I am sure that many people will find it very useful.

Bruce

zoopydogsit · 2011-07-11 08:20

It would depend on how volumous you want the apnote but it sounds like there is the opportunity to split this content into more than one appnote. I like jazzed's table of options with resource and speed costs. That would help the developer to understand some of the main examples, how the could be applied and at what cost (cogs, pins, memory, speed, error handling, and electrical interface considerations). Using this table with coding examples should do the main Appnote.

Other appnotes would be master/slave props, loading one (or more) props from another. There should also be a section on clocks (independent (each with there own xtal), common clock (separate clock source), and master prop feeding slaves with there clock). The clocking could be it's own appnote. Another appnote could be the concept of a prop as a separate video generator, referencing these other appnotes to avoid complexity. A final appnote or reference note may be the electrical circuit examples, verified speeds, noise an error handling conderations, etc). The error handling (or not) would be important for the resiliency of the system, and whatever final solution it's part off.

JonnyMac · 2011-07-11 09:52

Don't forget 4-wire full-duplex 485 -- and that the transmitter needs to be enabled (about 10us) before transmitting and needs to be released after the last stop bit. I'm working on my own beast, yet would love to see what bigger brains offer.

bsnut · 2011-09-03 23:29

I agree with Jon on this on needing 4-wire full-duplex 485

$WMc% · 2011-09-05 10:59

If your gonna go RS485, Why not step it up a notch to DH+.
'
Let the AppleApp do the heavy lifting.
'
The need for speed.......

Sariel · 2012-07-12 05:59

What ever happened to this? Is it a completely dead idea now? I went to ParallaxSemi's site, and there is no App note for it. There are a lot of uses for this kind of thing, and I know I am not the only one out there working with this concept. I know there are a couple good objects/methods out there, but I think there should be 2 of them outlined to start off with. The high-speed version from Beau, and the FullDuplexSerial version. I think those would be good starting points for anyone out there that wants a quick answer.

doggiedoc · 2013-01-22 09:39

Any work being done on this? I sure could use a complete guide to Propeller to Propeller Comms. Perhaps I'll start a new thread.

Paul

richaj45 · 2013-01-22 11:43

Hello:

My thoughts are for a chip - to - chip interface were the electrical interface is added depending on the distance between devices.

I would choose an async one wire serial interface with a start bit, 32 data bits, parity bit and stop bit.
The concept is one wire is used and the designated master always starts the communication with one slave, point - to - point.
If the option is to use driving buffers than an optional pin would be used to turn the direction of the buffer.

I would think that this could be run at 1/2 or a bit less than the prop instuction time.

Regards,
Richard

Zoot · 2013-01-22 12:01

- 100kbps/400kbps/1mbps I2C slave, master

Ditto ditto ditto. Multiple masters, self-enumeration (auto-addressing) of slaves, bus collision detection/recovery a bonus.

Prophead100 · 2013-01-22 22:07

In thinking about the original question, a simple program that transmits a basic set of data via several protocols would be very useful. I looked at several on a project then decided on simple serial (see attached). It would have been great in developing something to be able to compare i2c, 485, etc.. at the same time in one place. In this case, I shared data between props re-generated the video to save bandwidth...

softcon · 2013-01-23 05:16

Most of the time, when folks are starting this process, it's to get multiple props lloaded with the same code, so a master/slave setup would probably be the most beneficial for a first appnote, then expand from there. You know, load a second, third, fourth, and so on prop with the same code that was loaded in the first one upon bootup.
Of course, simple communications such as passing sensor readings from one prop to another would be useful as well for beginners. Such code exists (as already pointed out in this thread) but folks new to the props won't know where to pick it up, so having an appnote on doing this can only help.
These are of course the simplest prop-prop communications examples, and would give a relative new user a lot to work on until they were advanced enough to do other things.
By then, it's hoped they'd be more aware of other resources, and could find the more complicated things on their own, but perhaps just pointers to such things in the appnotes would be of assistance.

cavelamb · 2013-01-23 06:56

My question is - Prop to Prop - are such protocalls necessary, or even desirable?

There is an awful lot of processing required for some of these and that would have
a large effect on speed, memory, cost of development, etc.

As noted earlier, a second Propeller chip is usually considered because of running out
of resources (memory, pins, cogs). So it seems that a very simple system, defined specifically
for P2P might be more to the point.

Set Pin X high/low/toggle/pulse?
Send/receive buffer
All using already existing communications objects.

And move on with the application...

prof_braino · 2013-01-23 08:17

The original request was a bit broad. If one tries to eat the elephant in one bite, one tends to choke; which may be why this has not moved forward to any result. One has to to define the requirements, and break them down into doable items.

If you are talking prop to prop, there are several options: synchronous, asynchronous; buffered or not; protocol or not; etc.

If you are including I2C, RS-232/485, and/or other external hardware, then those are a separate issue.

One could start at the top with one wire no external hardware, add protocol , and work through to various external hardware.

This is how we did as mentioned in post 5. All the code, demos, and documentation is there. But somebody that knows about writing app notes would have to do that work. And somebody that knows about spin, PASM, and C would have to do those parts.

About protocol: If you don't include protocol, you might not have anything you can actually use. For example, the synchronous serial example in propforth, its kind of complex and hard to use on its own, but once the protocol is added, its"drop in and go", we start it up and it just works.

cavelamb · 2013-01-23 19:48

Yes sir. It was.

So?
Start with a simple Prop to Prop protocol.
How to get two props talking to each other on a proto board?

That has been suggested so often to fix Prop solve resource problems
that I'd kind of like to see how that works.

The rest will come along naturally as and when needed.

To that end, I guess it's time for some new boards!

Dual Propeller Boards
step 1
This is a normal Prop chip schematic - with a Prop as a peripheral.
Boss uses slave as a VGA display, Key, Mouse, SD,

And an expanded board adding all the rest - RAM, ADC, et al ?
Instrument Interfaces - protocols out the yin-yang.
All the above and my favs - GPIB, NEMA, and 357 Chevy...

distributed parallel processing

Beau Schwabe · 2013-01-23 22:12

The initial concept of the High Speed Prop to Prop communication was simply to 'share' a section of RAM between two or MORE Propellers in a round robin fashion to facilitate much of what is being discussed here. The data was simply to be treated as if you were passing it to another cog. In that sense 'adding' more Propellers into the round-robin-loop would be like expanding the number of available cogs. ALL Propellers have read and write access to the round-robin-loop, the only reason you need a Master is to initiate the round-robin and set it in motion, other than that ALL Propellers are treated equal. ... For instance, suppose you have a sensor on Propeller "A" writing to a memory location on the round robin. Then any of the other Propellers "B" "C" ... or "Z" could read the memory location for the value of that sensor. Likewise Propellers "B", "C", or "Z" could interact and write to the memory just as well passing it back to "A" if that was necessary.

DEMO High Speed Multi Prop-to-Prop Communication

softcon · 2013-01-24 14:05

Exactly the kind of thing I was referring to when I said prop to prop communications. You've hit the nail on the head. This is precisely what the beginner multi-prop user would want to know, along with loading the same code into multiple props at boot-up. These two things tied into an appnote would cover better than 50% of the initial multiprop questions raised by beginners in this area.

cavelamb · 2013-01-24 21:10

Interesting...

Can master also "provide" the shared memory?

Could the concept be implemented that way?

Beau Schwabe · 2013-01-24 21:43

"Can master also "provide" the shared memory?" - Sure... the only need for a Master is to initiate the round robin, otherwise there is no difference between the Master and the Slave(s) as far as read/write control over the shared memory block.

StephenMoore · 2013-01-24 21:49

Attached is a set of programs that demonstrate these three things:

1) High Speed comm between multiple props that uses one cog only (I condensed the Beau Schwabe objects to one object only where the user defines read only zones in buffer)

2) A LabView program that selects the appropriate prop loader configuration file ( a spin file) and then uses the Propellent.DLL to load the customized spin program along with the Chip Gracey PropLoader program. The result is it kind of looks like a conditional compiler to load the right prop with the desired program from one user interface. I think the Propeller Tool could be easily modified to do this function too.

3) A rudimentary command-control-communication structure that operates like a rudimentary state machine. (Set command in command buffer -> wait for prop state to change to command complete).

I also wrote a pass through debugger that opens a serial port to a desired prop and passes its data through to the PC but it is not included in this upload.

All of this means only one USB port is required to program and debug multiple props.

I also think this set of programs would make a great app note in itself for multiple prop comm/programming/debugging.

Regards,

sm

AppNote Content Input Request: Propeller to Propeller Communication

Comments