Pseudo multi-drop TTL serial issues

I've read that multi-drop serial in RS232 form is only available (without adding complexity), with master to multiple slaves, but no response from slaves to master.

I've also read that for TTL serial (0-5V) this can be overcome by making each slave TX high-impedence except when it is transmitting.

Assuming very little traffic (one 2-byte message per hour might be a high average for 1 master and 8 slaves), and no concern about collisions if they did occur, would this work?

One picaxe-X2 master sending on a single wire to 8 14M2s with background serial receive (2-byte buffer), and the 8 sending on their TX only if they see that the TX line is not high (TRUE idle--someone else using it) and then immediately making that pin an input (high impedence). The picaxe-X2 master would hve RX on background serial receive into the scratchpad.

I don't want to look into wireless or RS485, and for distances, would be mindful of the recent thread by Jeremy Harris regarding termination: http://www.picaxeforum.co.uk/showthread.php?29589
Regarding Jeremy's thread, HIGH termination would obviate the test for HIGH to determine if another slave is transmitting.

What problems could be anticipated with this approach? Assume total distance of 15 meters.

Multi-drop from slaves to a master can be achieved by using diode OR'ing and an appropriate pull-up / pull-down at the master end.

It is possible to do it without diodes if it can be guaranteed only one slave will be transmitting at a time. If two or more output at the same time they may short their outputs and be damaged.

As to distance; that's a try it and see. You will probably have to experiment to see whether the diodes are best put at the slave or master end (*), whether having them facing in one direction performs better than the other.

(*) Re-read that and realised it may be confusing. A star, master to N-slaves on separate cables is still a multi-drop configuration even though it's not an out-stretched line they all drop off. It's the case when 'd' is reduced to zero ...

I've done something sort of similar and ended up with using RS485 drivers. The risk wasn't worth the reward. Even then I only felt better turning it loose with a polling system of the slaves in software.

Looking back at this thread, hmmm ... I know I wrote a response, but apparently managed not to submit it.

Thanks to you both. I've seen references to the diode-or method, but now, after reading elsewhere, I think I understand it.

I may end up going the RS485 route if it looks like that may be needed for reliability.

So for diode-ORing, would this be what we are talking about for TTL serial, 3V3 idle high?

You don't need diodes on the Master TX to Slave RX line, as RX doesn't put anything on the line, it just listens.

The diodes on the Slave TX to Master RX are needed so that when one Slave TX's a '0' it doesn't get swamped by all the other Slaves which are still pulling '1'.

Your diagram shows TX and RX mixed on the same wire, that's not right. All the Slave RX pins are connected to one line ( TX from Master ), and the diodes are between each Slave TX and the common line to Master RX.

Best to try it with some PICAXEs on a breadboard to get the hang of it before running lots of cables around the house

Cheers,

Buzby

"You don't need diodes on the Master TX to Slave RX line, as RX doesn't put anything on the line, it just listens."

Right, don't know what I was thinking.

"Your diagram shows TX and RX mixed on the same wire, that's not right."

Not sure I understand that. I didn't mark it, but the center was intended to be the master.

Yes, I'll test first at short distances.

lbenson said:

... Not sure I understand that. I didn't mark it, but the center was intended to be the master.

Click to expand...

Oops !. I missed that, thought they were all slaves.

Time for bed.

Cheers,

Buzby

To expand on what tex said in post #3 - using a polling system. A slave will only respond to a poll from the master, addressed to the individual slave. Ie "speak only when you're spoken to". This overcomes the problem of data collisions on the (response) bus. You may also need the master to have a hold-off period if it should receive a garbled reply to a poll.