Parallel Processing

John Board

G'day,

After gaining 1st place (yay!) at regional RCJA competition, I'm now moving my focus toward the state championships. With the number of sensors/prehipherals I'm adding, the more memory/cores/pins are being used.. So, I think it's time for me to add a second prop. I've never really done any parallel processing of 2 props before and I'm wondering what's the best way to go. There are two obious communication approaches:

Serial Communication
Parallel Communication

The advantages of serial is that it only uses one or two of my precious IOs, although it can sometimes be a bit slow (although not so slow now that I've discovered that FullDuplexSerial can operate at 1_000_000 baud....), and parallel is possibly quite a bit faster (I think...) but it uses up several IO pins. This is all a learning experience for me, and I'm trying to figure out which way to go. I'm wanting to have an object that allows multi-prop-control to be dead easy, for example:

OBJ

  Prop_S: "PropSlave"

PUB Main | x

  Prop_S.Start(rx, tx)
  x := 250


  'This code will be to blink an LED on the slave on and off every x ms

  repeat
    Prop_S.OUTA(1, true)
    Prop_S.pause(x/2)
    Prop_S.OUTA(1, false)
    Prop_s.pause(x/2)

This is alright when the code is only operating at very slow speeds, but how would this cope, if i were, for example, to convert the Ping driver to this, so I'm taking ultrasonic readings from a seperate chip to the one it's connected to. Would serial be too slow for this?

Alternatly, I could have the same low-level support, as well as higher support for the ping sensors, so, I send a request for the cm/mm of the sensor, and it returns it.

So, which do you think is better? Parallel, or Serial? And if I was going to use serial, would it be too slow, even if I had the baud set to 1_000_000 (or very crazily fast).

Thanks,

John

P.S. I have taken a look at this thread, and am brainstorming off it: http://forums.parallax.com/showthread.php?95270-Parallel-processing-using-multiple-Propeller-chips

Clock Loop

My experience with multi prop configurations and speed has been that the more props you use, the slower the system goes due to communications overhead.
If you have serial communications more than 4 props or so will start to pull the serial bus into noisy situations which can be dealt with program wise.
I did a multiple prop experiment with 55 props.

http://forums.parallax.com/showthread.php?127983-55-Parallax-Propeller-s-Parallells-Processing-of-Permanent-Perturbations.

I don't think you want 55 props, but my method of a master, slave and sub slaves works pretty well, and might point you in the right direction.
Good luck.

Mike Green

You might want to look at using PropForth which has some built-in provisions for inter-Prop communications

pjv

John;

Have you exhausted the ability for each core doing multiple tasks/sensors?

Cheers,

Peter (pjv)

Duane Degn

Spin can only move bytes around so fast. I believe bauds of greater than 115,200 (or a little higher) don't do you much good. So unless the PASM portion of your com driver has direct access to the data your want to transfer, parallel communication wont do you any good.

jmg

John Board wrote: »

This is alright when the code is only operating at very slow speeds, but how would this cope, if i were, for example, to convert the Ping driver to this, so I'm taking ultrasonic readings from a seperate chip to the one it's connected to. Would serial be too slow for this?

The secret is to make the peripherals latency tolerant.

So for this example, whilst you could craft a design that timed pulses directly from a serial data, why do that ?

Better to send a Pulse Duration, and Pulse repetition rate to something like a Ping-handler, and then listen or poll for the delay-replies.

Unless you have wires to burn, parallel is usually only used for highest data bandwidth problems.

Also, in a crystal based Prop-Prop system, there is nothing that says you have to Serial-pump bytes.

You could get less overhead and more throughput with a 32 bit sized packet, and include address/data in a single send.

John Board

@Clock Loop: Wow, I noticed your thread earlier, and was impressed - Still, what do you do with all that processing power?

@Mike Green: Will do, although I have previously explored PropForth and there are some aspects I do not like - But I think I ought to look into it again

@pjv: I still *MIGHT* be able to squeeze in more processing, although the cogs are pretty jam packed, and the coding is quite cozy as is. Also I'm almost out of pins

@Duane Degn: Thanks for the advice, I'll keep that in mind.

@jmg: Also thanks for the advice, I'll consider it!

Thanks all for the resposes, as for myself, I don't care too much for the electronics of my robots, however, I really enjoy the programming issues, programming is one of my passions.

-John