comunication betwen 10 sx and 1 prop

AHMET AKSU

· how can we make a comunication betwen one master propeller and ten slave sx

deSilva

There are many possibilities; you have to be more precise.
I should suggest:
- you first decide about the data you want to transfer (bandwidth, response time)
- second select a specific software protocol
- third implement the protocol and solder the wires

(ad 2) Simple serial communication is always fine, strict asynchronious birectional transfer needs 2 lines (=20), clocked transfer needs 3 (=30 = too many). So you have to decide for a multiplex solution (aka "bus"), e.g.
10 select lines
3 transfer lines (e.g. SPI)

When you are short of Prop I/O pins use a decoder chip for the select (4:10, 4:16), any will do.
Everything is straight forward

Post Edited (deSilva) : 8/24/2007 2:41:31 PM GMT

ericball

And whether the protocol needs to be bidirectional and which side is initiating the communications.

You probably also should look at what kind of I/O functions are built into or are easy on the SX since the Prop typically lends itself to greater flexibility. Of course, if you're not interested in coding the interface routines, then you're better off seeing what Prop objects have been created already and whether any of them will meet your needs.

AHMET AKSU

is the can- bus interface suitable for comunucation betwen propeller and sx

deSilva

Everything is suited, but why the hell are you thinking of THAT ???

And the answer to my "Question 1" is more important than minor electrical details...
- bandwidth ?
- resonse time ?

ok, there is an additional important question: "Geometry": What is the distance between your devices?

Post Edited (deSilva) : 8/25/2007 1:32:11 PM GMT

AHMET AKSU

1 kbit/second data rate is enaugh for me.the sx is on a linear array.there are 20 cm between two sx and there are 2m between first and last sx.and propelller is 5 m to sx array.I think every element 10 sx and propeller

speak on a bus and comunication must bidrectional betwen sx and propeller but I dont need to comunication of sx with another sx

Mike Green

It sounds like the simplest solution would be a "multi-drop" serial bus. This would be a simple Propeller-controlled serial bus using active-low drivers at each SX ... You could probably just use the I/O pin and switch from output-low to input. You'd need a pullup to 3.3V at the Propeller, maybe 330 ohms so you'd get some reasonable current in the bus (10ma is enough). From the Propeller to the SXs, you don't need anything special, maybe put a series resistor in the line at the Propeller (220 ohms) to protect against short circuits.

For software, you would just use asynchronous serial at 9600 Baud. At the Propeller, you'd use the FullDuplexSerial driver. At the SXs, you'd use the equivalent. The Propeller would poll each SX in turn by sending some kind of address command (like "!00" or "!01"). The SX would respond with the same address command. The Propeller and SX could then carry on whatever exchange you might need, then the Propeller would address the next SX and talk to it. The leading character(s) of the address command should be something that won't occur in any other message between the Propeller and the SX.

deSilva

I assume Achmed's 1kBit/s refers to each SX, that means 9600 per 10 is a little bit at the low side; but I see no problem to move it up to 110kBit at the distances involved.

Clean async in connection with an error correcting protocol has many advantages...
One could even try to do this on ONE line (half-duplex

AHMET AKSU

thanks Mike and deSilva.can you send a schme abaut conection of sx and prop

deSilva

It's simpler to describe - and Mike did most of it already:

Choose any 2 Pins from the Prop, say 0 and 1, call 0 XMT and 1 RCV

Connect XMT to the (or one of the) serial RCV pin(s) on all SXs
Connect RCV through 10 1kOhm resistors to the respective XMT pins of each SX

When you need comunication you send a specific address byte; the SXs should be fast enough to respond to the falling edge of the start bit to catch the async byte. If not send a general "attention" byte before the address.

In case of erronious addressing, the 10 resistors will avoid a shortcut between the SXs, also they will limit the current to the 3.3V Prop.

Edit: O.K. the line 1 has be in tri-state mode generally, and you need an Pull-Up (10k).
It should be ideal if the SX had an open collector for this line. Would save you 10 resistors... Have they?


BTW: You have not yet answered the question about "response time"!
You see, we are thinking about solutions, where such data is relevant. When you say you need a response time of 1 ms than this wil not work!!

Post Edited (deSilva) : 8/26/2007 12:26:56 AM GMT

AHMET AKSU

thanks deSilva . I cant understand the term xmt and rcv .can you explain that terms please

deSilva

They mean TRANSMIT and RECEIVE. X is used in the English language for
TRANS, CROSS, also for CHRIS (XMAS)

Fred Hawkins

As a furriner, deSilva misses that it is not English language but actually tech-speak with a strong flavor of MilSpec. (For instance, this MOS: HF XMTR Repair)

deSilva

MIL speak is terrible
But it started many hundred years ago with the market merchants
@ "at"
w/o "without"
w/ "with"
pc "piece"
pcs "pieces"
ASAP "as soon as possible"

and see:
R.S.V.P. though this is french
R.I.P. and this is Latin, strictly speaking (I mean: strictly spoken)

deSilva

Didn't want to go OT, sorry..

AHMET AKSU said...
is the can- bus interface suitable

Also excuse my harsh answer above: The CAN is an excellent BUS system, electrically well suited to your project, but most likely absolute overkill!

You see:
- CAN has been designed for extremely robust applications with lots of EMI and other stress elements around.
- The base protocol is generally implemented in silicon and a little bit complicated as the user has not much to care about it.

As Parallax does not provide a "CAN Driver" ("more important work to do" they would say most likely ) it will be not strictly easy to implement CAN in a COG. Maybe there is CAN in the SX !?

You can alternatively add a CAN controller e.g. MSP2515 (around $3)
When you want to profit from the benefits of the CAN bus robustness, you will need a CAN transceiver anyhow (e.g. MSP2551, maybe $1)

So I (we) think, it will not further your project, except some of your environmental needs will require that. This is a question you have to investigate in and decide about. That's what systems engineering is all about - in contrast to what we simple minded software engineers do

Post Edited (deSilva) : 8/26/2007 12:30:14 AM GMT