Using a propeller as a intelligent communication hub

Mr. Bricole

Hello

I'm a newbie here, so I hope my question is not already answered somewhere inside the forum.

I'm thinking about using a Propeller chip in a multi-processor system for a robot. The Propeller would be linked serially with multiple slave PICs coprocessors.

From what i gatered so far, every time a USART objet is started in Spin, it uses a cog. So this would mean that I can only run 3 USART objects at once in my system;

3 USART comm cogs, 3 other cogs to process those feeds, 1 cogs for main control program, 1 "leftover" cog.

Would it be possible that 7 cogs run USART communication AND process information ? The remaining cog would run the main control program. This setup would be ideal i think. Also, I would be nice if the 7 cogs would not need to continually "swap" between separated comm USART program and proccessing program.

Gadgetman

Why do you need 3 COGs to process the information from the 3 COGs running the USARTs?

Even if you run the USART COGs at 19200bps, you will only receive about 500 32bit Lwords/second, and unless you have some very advanced processing to do on those streams, I can't see why you need 3 COGs to process the information.
Remember, the Propeller has 32KB RAM and you can use a lot of that for buffering data.

The Propeller can supposedly start up a COG with a new object in a few uS if it's running at 80MHz. This means that every time a slave is deemed not to need 'supervision' for even a few mS, the COG that was communicating with it can be reused for another task. (Like communicating with another PIC or processing data?)

I mentioned 19200.
That is what a Spin-based FULL-duplex USART does. Now, imagine what a Half-duplex assembly-based USART would be able to do...
(you don't need better than half-duplex in a master - slave setup)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Mike Green

Part of the beauty of the Propellor design is the relative simplicity that the parallel processors provide. Each COG can contain a single purpose small, straightforward program, yet a lot can be going on in parallel. It is possible to write a program in assembly language to provide more than one USART using a single COG. Clearly the Propellor has enough processing speed to do so. It would make the program quite complex to do this. One example is the multi-servo controller program already posted on this forum that provides simultaneous control of up to 32 servos with one COG. I suggest that you set up a small network with all the slave PICs connected via a single USART/COG. Many Stamp coprocessors already use a protocol for this that allows a coprocessor to be selected via an address and only the selected one responds to a command. If you use an "open-collector" circuit for the output of the coprocessors, you can connect all of their outputs together, have a pull-up resistor at the Propellor, and only one coprocessor would transmit at a time in response to polling from the Propellor.

If you do want to assign a COG for each coprocessor (although why offload the functions to a coprocessor if they can't work independently for a little while?) and the transmission rate is low, you could reload the USART when you need it and keep the processing of the feeds in the same COG. The "swap" doesn't take long (a couple of hundred microseconds). Conceptually it is simple to do that.

Gadgetman

Started thinking...
(Yeah, bad habit. I'm on a twelve step program to quit)

Why use the PICs at all?
Every COG is more powerful that the PIC it will be communicating with, and letting the COGs take over the task directly will remove the delays in data transfers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Mike Green

Playing devil's advocate ... One advantage of using PIC coprocessors is that the Propellor's memory, although pretty large by most microcontroller standards, is still small if you have complex control needs with different coprocessor programs in many coprocessors. If most of the coprocessors are doing the same thing, the Propellor shares the code, saving program space. I'm already thinking ahead to the 64 pin Propellor, possibly using a lot of pins for external memory. Some of the 8-bit multiplexed address/data bus memories might be a good fit for a high-speed external memory without too high a pin requirement. It would be nice for Parallax (once they get a little breathing room) to document how to do SPIN overlays. I don't know how they store the interpretive code, but it must be somewhat amenable to overlays.

Mr. Bricole

Using you good suggestions i have change the architecture of my project.

I will use multiple PICs on a same comm line. But i will not go for adressable USART since all PICs on the line would get an interrupt each time an adress is put on the comm line. I think i will go for a direct signal from the Propeller to each PIC to get their attention for communication exchange.

I have attached here a revised sketch of my project.

I you want to look at it, keep in mind the following;

-altought is a complex project, i want to keep things simple and manageable

-I want to build an homebrew robot controller based the ideas of subsumption architecture (invented by this Rodney Brooks guy). I have also been inspired by the robot project "Seeker" of Dave Shinsel.

-I want to use PICs for low-level control, and reserve the Propeller for high-level control

Mike Green

Several suggestions:
1) If you are going to have a line from the Propellor to each PIC, then I suggest that you use that line for the actual communication. You can certainly use a standard asynchronous serial signal for that purpose, possibly signaling the PIC by using a "break" signal (a long low ... several bit times long) and waiting for an acknowledgment.
2) The COGs really are equal in status and do not need the complexity of arbitration
3) Some of the PIC functions might best be done by the Propellor itself like servo control. depending on the number of digital lines, that might also be done well by the Propellor. I don't mean to discourage you from using coprocessors, but that does introduce another level of complexity and the possibility of error. If you don't really need it, you're better off doing the functions in the Propellor. You might consider using two Propellors if you really need the i/o lines and the simultaneous functions. I know PICs are cheap, but, once you get 6 to 8 of them, you're introducing complexity that may be easier to manage with the two Propellor chips. SPIN is a much more powerful language with debugging tools even now at an early stage than you can get with PICs, particularly since you can do TV output with only a few resistors. It can also do A-D and D-A conversions and servo control easily and cheaply.

pjv

Hi All;

Unless the robotic applications are extremely complex, or the I/O count exceeds the the chip's capability, my expectation is that a single Propeller with all of the COGs running assembler can likely handle all the work required.

Experience with a lot of assembler code for SXes, continues to amaze in the amount of work they can chew through with ease. In the Propeller we have eight comparably powerful machines, each slower, but with a wider and more competent instruction set, and with a great hub-communication system. The mind boggles at what can be achived with this chip by the upcoming crop of competent assembler programmers....... and an integrated single Propeller approach will surely simplify all the PIC communication layers anticipated.

That said, only Mr. Bricole knows the level of complexity contemplated; my suggestion is....... don't write the single Propeller approach off prematurely!

Cheers,

Peter (pjv)

Paul Baker

I see why Mr Bricole wants to use the pics, well defined algorithms for encoding, ADC and DAC, and given the proposed layout all cogs will be consumed. However reclaiming the two cogs used for PIC communication, combining the object avoidance and collision detection cogs (they are similiar and simple), and considering this is subsumption architecture, the navigation module can be incorporated in as well so you have an integrated subsumption machine on one cog taking the inputs of object avoidance and collision detection and generating navigation directions. Also the user interface cogs can be combined into a single cog, that leaves you with 5 cogs left over for encoding, servos, ADC and DAC. Use one to operate servos, and you can homogenize the other functions across the 4 left over cogs, using the counters (giving you 8 channels), you could likely also use software to implement the encoding in conjuction with the cog performing ADC/DAC in the counters. Also depending on how fast you want the ADC/DAC to be updated you can approriate the counters on other cogs for additional channels if they are not already used.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10