Multi prop communication/loading

hinv

I was wondering if anyone has done this in a standard sort of way.
It appears that there are just not enough pins to control everything for some projects that I have in mind like running parallel LCD's, attaching memory chips, etc.
I know most people have used serial LCD's, but if you look at the price diference, I think it would be cheaper to use another prop chip, and then loading the slave prop from the master prop, and then maybe using the same 2 i2c lines for communication.
I just didn't want to reinvent the wheel here if somebody has done it.

Mike Green

Look in the Propeller Object Exchange. There's a driver for 8255 Parallel I/O expanders. There are I2C routines which can be used with Philips and Microchip I2C Parallel I/O expanders. You can also use cheap 74HC595 serial to parallel shift registers. I don't think anyone has done a "canned" driver for those because they're so simple. Sid (newzed) has been working on a multi-Prop setup and may have some ideas.

bassmaster

there are a few people who sell a serial lcd chip that can control a cheap lcd for like 5 bucks for the kit with resistors, check ebay for lcd kit. I just bought a few $3.95 serial lcds on ebay that have 2 - 20 x2 lcd's on one board that is serial, the seller has 300 still for sale on ebay. It took me a while to figgure out the baud rate and hex control codes to flip between the displays. But it runs at 4800 8 odd 1 and is very nice for < 4 bucks apeice.

Bill Henning

I soldered up a nice little expander prototype about two weeks ago using 74HC595's... works great, but I have not had a chance to write a spin object for it yet - I'm currently using it on an SX28... which is slated to be slaved to a prop :-)

Mike Green said...
Look in the Propeller Object Exchange. There's a driver for 8255 Parallel I/O expanders. There are I2C routines which can be used with Philips and Microchip I2C Parallel I/O expanders. You can also use cheap 74HC595 serial to parallel shift registers. I don't think anyone has done a "canned" driver for those because they're so simple. Sid (newzed) has been working on a multi-Prop setup and may have some ideas.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

KenBash

I had a similar need for more I/0 so·I designed a board that has three Props on it.·( I put a photo of it·somewhere here on the forum ) ·I'm pretty sure I could have done the I/O with a port expansion chip but It seemed like a good excuse to play with multiple props.· (and the idea of a small controller with 24 32 bit processors on it was a·kick. ·I call my board the "Trimotor" )

I tied three port pins between each of the Props, not really knowing how I was going to use them to communicate, but I figgured it would be enough to make something work.· Once I actually started writing a·function·to communicate between all three Propellers, I found that two pins were enough.·

I'll post my code if anyone REALLY wants it, but it's such a·hack that I'm pretty sure anyone could easily improve on it.

My inter-prop communication function works like this:··
·
·· The two com·signals are Clock and Data
··· The data pin is pulled low with a resistor.·· This lets any of the three props put data out on this line.

·· one of the Props ( will call it Prop-A ) generates the clock signal. It starts with a syncronization pulse that
···is low for a count of ten.· ( it can be shorter or longer, there just needs to be enough time for the other
·· two propellers to realize that it's been low for a while )

·· As soon as the clock line goes high, this begins the transmission of a frame of data.

·· the frame consists of three blocks that belong to each propeller in turn.· I'm using 32 bits for each propeller, ( any·block size should·work)··on the first·32·clock pulses , Propeller A puts it's 32 bits worth of data out on·the data pin. When the clock count gets to 33, that is the start of Propeller B's 32 bit data frame, and so on until 96 clocks·have·passed.· This lets each propeller have it's turn to talk and·each can read the data coming from the other two propellers as well.

I'm not doing anything fancy with this format, I'm just using it as flags to indicate an I/O condition or start or stop·a function on one of the other processors, but it should be·fairly easy to do more complex communication if necessary.

As for·plain old vanilla·I/O, ·the port expansion chips using· I2C communication look like a great solution. Go to Digikey an type in "expansion"· you'll get a list of chips that let you add between 8 and 40 I/O lines that only tie up 2 of the Propellers pins.· I haven't·actually used them yet, but I'm laying out a new board right now that I'll be using a couple of them on. It seems pretty simple.


I'd also love to know if someone has a better way to let multiple propellers talk with each other.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
" Anything worth doing... is worth overdoing. "

··············································· ( R.A.H. )
····································

Mike Green

There are some other schemes that only need one pin and work somewhat like the Ethernet. It requires a single pullup to +3.3V, probably in the range of 3.3K to 10K. All the Propellers leave the pin as input and set up the output so it will go low if the direction is changed to output. The Propellers listen to the pin. If it's high for at least a few character times (at whatever speed you want), a Prop can pull the line low for a few character times, then send a control packet with the number of the Prop sending (you'd number each Prop), the Prop receiving, and a packet number (initially zero) for the transaction (using standard serial asynchronous I/O). Any Props not sending would watch the line for this sequence and, if it's seen, receive the bytes and ignore the contents if it's not addressed to it. The trick is for the transmitting Prop to look at the line during high bits (including any stop bit). If the line goes high as expected (due to the pullup), all is well. If the line stays low, someone else is trying to transmit and the Prop detecting this should stop sending and wait for several character times of high before attempting again. You should probably have some kind of CRC or checksum as part of a packet and the receiving Prop should acknowledge correct reception with some kind of return packet. You should probably add a random fudge factor to the amount of time to wait for (for a clear line) so two Props can't get in sync both waiting for the line. Using a slightly modified FullDuplexSerial driver, you could easily communicate at 115KBaud.