question about MultiQuickstart board
fixmax
Posts: 91
HI folks,
I'm looking to design a daughterboard for the Quickstart Board. To keep from having to worry about running out of cogs, memory, etc, I'm thinking about even 2 or 3 Quickstart boards plugged into a single daughter board. What would be the best communication method between the three quickstarts? I'm thinking along the lines of 1 master QS board, and 2 slave boards. I would dedicate a TX/RX pair between each slave and the master, and have the master contain the main loop code, and the slave processors running I/O code. One slave would be an "input" board, and the other slave would be an "output" board. The input board would just stream a raw message of various data as fast as it could with each message delimited by a start and stop character, and the output board would be receiving a streaming output raw message from the master board. I am thinking of adding a sub comms channel as well, in case I need to send and receive info outside of the raw data streams. Does this seem like a viable method, or a waste of resources. I want to keep things as simple as possible, no fancy stuff so I'm not worrying about timing, etc. Would this allow me to run an architecture this way?
I will have a bunch of sensors being read, scaled, interfaced to from the Input board, the input board will take all of the feedback, blast it into the master board as fast as he can, and the master board will be blasting a control message into the output board as fast as he can. The output board will handle output scaling, interfacing to his output hardware.
Do I need a common clock between all three to possibly help with synchronization if needed?
Any thoughts or comments on this? I really like the simplicity of the Quickstart. I noted the Stepper board the other day for it, and have seen some stuff from GG on a proto board and their player board. I think Parallax has on their hands the equivalent of the Rabbit core modules. I can see more boards with this since it's inexpensive and available through Radio Shack.
I'm looking to design a daughterboard for the Quickstart Board. To keep from having to worry about running out of cogs, memory, etc, I'm thinking about even 2 or 3 Quickstart boards plugged into a single daughter board. What would be the best communication method between the three quickstarts? I'm thinking along the lines of 1 master QS board, and 2 slave boards. I would dedicate a TX/RX pair between each slave and the master, and have the master contain the main loop code, and the slave processors running I/O code. One slave would be an "input" board, and the other slave would be an "output" board. The input board would just stream a raw message of various data as fast as it could with each message delimited by a start and stop character, and the output board would be receiving a streaming output raw message from the master board. I am thinking of adding a sub comms channel as well, in case I need to send and receive info outside of the raw data streams. Does this seem like a viable method, or a waste of resources. I want to keep things as simple as possible, no fancy stuff so I'm not worrying about timing, etc. Would this allow me to run an architecture this way?
I will have a bunch of sensors being read, scaled, interfaced to from the Input board, the input board will take all of the feedback, blast it into the master board as fast as he can, and the master board will be blasting a control message into the output board as fast as he can. The output board will handle output scaling, interfacing to his output hardware.
Do I need a common clock between all three to possibly help with synchronization if needed?
Any thoughts or comments on this? I really like the simplicity of the Quickstart. I noted the Stepper board the other day for it, and have seen some stuff from GG on a proto board and their player board. I think Parallax has on their hands the equivalent of the Rabbit core modules. I can see more boards with this since it's inexpensive and available through Radio Shack.
Comments
I personally have a lot of multi Prop projects. So much of the answer to "what's the best communication method" depends on what you're communicating with and how fast you need to deal with the data gathered/sent.
For pure speed, a parallel bus will give better results than a single communication line. I think Beau has a four bit bus communication object.
I believe Jazzed has used an eight bit bus for communication, I've also toyed with an eight bit bus.
If you can get by with 57,600 bps you could use one of the four port serial objects to save on cogs.
When I first started to use the Propeller, I used multiple Props to solve problems I feel confident I could now handle with just one Prop. There are tricks such as reusing hub RAM after PASM code has been loaded into a cog that can help reclaim memory. If you're not running all the various parts of your program at the same time, you could use something like KyeDOS to load different code depending on what you need to do.
I also really like the QuickStart board. I'm pretty sure I have over six of them but I generally don't use them in my multi-Propeller projects. If I need just two Props, I'll either use half of a TetraProp board or I'll stack two Propeller Proto boards on top of one another. If I need four Props then I use a TetraProp board.
So much will depend on the specifics of the project.
If you can use forth language, check propforth. It does pretty much everything you are looking for, as far as I can tell.
The MCS (Multi channel synchronous serial) allows commenting multiple props together and communication is at clock speed.
The master can emulated clock and eeprom for the slaves, so you can hang bare prop chips of of a single protoboard, quickstaRT, ETC.
Since the communications are synchronous and the clocks are provided by the master, everybody is always in sync.
The method was design so we can add additional cogs and pins transparently.
Give it a shot. Some folks pick it up in a snap, but some folks report a learning curve for using the http://en.wikipedia.org/wiki/Reverse_Polish_notation
Its worth the effort.
Ok, so theoretically I should be able to take a tetra prop and prop forth could basically be used as a giant 32 core prop... Is there an app note or something that documents how to wire up multiple props?