Parallel processing using multiple Propeller chips?

RichardF

My sensor hungry Prop_Bot is eating up all of the available cogs on one chip. I am exploring the possibility of running a second Prop·plug ·in "parallel" (sorta). Here·are my first·thoughts on this:

I want to use parallel comms between chips to maintain system speed.

Call M_Prop the master (M) chip and S_Prop the slave (S) chip. M_Cog 0 is master control (main program).

M_Cog·0 and S_Cog·0 are connected for 8 to 16-bit (depends on how many pins can be spared) parallel comms.

M_cogs 1..7 are updating sensor output global variables to be read by M_Cog0, and S-Cogs 1..7 are reading sensor inputs and updating their sensor output global variables to be read by S_Cog 0.

·M_Cog 0 signals S_Cog 0 it is ready to read a S_Prop variable or variables in byte or word lengths (simple duplex parallel comms) using an input output 8/16-bit register. This would not be true 14 cog parallel processing because of the time it takes for M and S to transfer information, but it would certainly be close to it.

The two chips would have to be separately programmed. No problem.

I would appreciate hearing any thoughts on this, especially if I am going off in the wrong direction. The Propeller chips and EEPROM are so inexpensive, it just seems the right way to approach multi (more than 7) sensor parallel reading.

In case your interested, I am building a light reading sensor based on multiple TSL-230 light to frequency converters. I need a minimum of 8 cogs to read a circular array of 8 sensors simultaneously. If I can gang Prop chips inexpensively, I want to build a flat panel array of 64 sensors in an 8 X 8 configuration which could track any object traveling across the panel. I think you get the picture. This TSL-230 is an incredible device for the price, just like the Propeller.

Thanks,
Richard

Mike Green

I suspect that, if you recoded your sensor reading routines in assembly, that you could handle more than one sensor per cog. You would eventually run out of I/O pins, so you'd need several Propeller chips anyway. You're talking about a lot of data at the moment ... 1 to 2 bytes per sensor per reading times 64 sensors. You don't want to store that for long with less than 32K available total

Since you probably want to read all 64 sensors at the same time, I suggest a Read Sensor line that the various cogs use to synchronize their read of the sensor ... whenever they notice a transition from zero to one they do a read. I suggest you use a chip select from the master to each slave (separate lines) and a clock line and 8 data lines that can be shared. The master selects a slave, then after a fixed delay, the master puts out a clock pulse. Some time after the start of the clock pulse, the slave will have put an 8-bit data value on the data lines and the master can read it. With each clock pulse, the slave can send another byte value. When the master has read the proper number of bytes, it can drop the chip select. The slave will always reset its communication routine when it's selected, so, if the master has a problem, the slaves are still in a known state. If you want a "solid" handshake, you can add some other shared lines for the slave to indicate its status or always transfer an initial byte with status information.

rokicki

Yeah, I agree. A lot depends on how you are reading the sensors and how many you have, but certainly reading a bunch of sensors in one cog
is probably a simpler overall approach. My current boebot has a single cog that reads a pair of QTI (modified) sensors and drives two servos.
It only reads the sensors 50 times a second (each) and drives the servos at the same rate. Since I can't drive the servos faster than 50 times
a second, at least in my application, it makes little sense to read the sensors more frequently than this.

I am having some power difficulties, however; my alkaline AA batteries don't last very long (and cause propeller resets when I reverse the
servos). This happens even if I reverse the servos slowly (ramping them into the other direction). I am going to try to figure out how to get
five batteries instead of four onto the bot.

The TSL-230 is a pretty incredible device, but I suspect you should be able to read all eight of them in one cog without much difficulty. The
highest frequency that chip generates is pretty low (1MHz) so just detecting 0->1 transitions and bumping counts based on that should be
relatively simple.

RichardF

Mike and Rokicki,
Thanks for all of the very good suggestions and information. They make a lot of sense. Essentially what both of you are saying is I need to first determine the minimum sensor read rate and then see how many cogs it takes to achieve that. Mike you gave me good info on how to communicate between chips.

For Rockicki,
With my Prop_Bot I am a Cog Hog! I use one Cog each for the wheel servos, the whiskers, the IR sensors, the light sensors, the Ping, and the noise detection system. It makes programming soooo much easier. But, I am running out of cogs fast. With the 8 sensor, radial, light measuring array, I want the bot to detect a camera flash or a muzzle flash and go after it (I wnat to chase poperazis!). I haven't calculated how much time is available to detect a camera flash, but I will. This will tell me how often I need to read the sensors.

My Prop_Bot power setup has a 6 volt (1200 ma) NiMh pack directly feeding the two servos and a 5 volt regulator, which feeds the Lcd screen and the 3.3 volt regulator. The power surge from the servos reversing is so bad it drops my Lcd off line and it can't recover because it needs a startup routine (the chip stays on line okay). I don't use a ramp up/down routine because it makes accurate distance moves and turns very difficult to compute. My 5 volt regulator is a 1 amp unit and I believe it will take 9 volts in. I am going to try a bigger NiCd pack and see what happens.
Richard

Lawson

RichardF going to a 6-cell pack would help a lot. With the 5-cell pack you are using right now the 5v regulator has very little voltage head room. (like between 1v and -0.5v depending on charge and most 'LDO' regulators need ~200mV)

Rokicki, yea Alkaline batteries suck at delivering high currents. (standard servos pull surges of >1 amp regularly) Have you tried using 4 NiCd cells? Or some of the Alkaline batteries designed for digital devices?

my 010 bits,
Marty

rokicki

Just a minor point, the "LDO" used on the protoboard is not very "L". It requires between 0.8V and 1.5V depending on the
current drawn (at room temperature). I personally am still experimenting with different power layouts. I'll probably use
a five-cell pack, and see which works better in practice for my specific bot, alkalines or NiMH.