Multiple PICs on usart network

[Demon]

Thank you.

Your replies sent me on search for "rs232 multidrop" and that gave important note.

"One Master PIC can talk to multiple slaves, but only 1 slave can connect back to Master RX."

I had missed that fact if it was mentionned in the PBP manual, or anywhere else.

I've since switched to an alternate solution.

Thanks!

Robert

[Demon]

This post is for the next guy that tries to do this. A few things I learned:

- you can put a basic MAX232 on the TX and RX lines and "watch" what is being sent around your network.
- 4K7 pull-up resistors are good for master and slave RX pins (supposedly only necessary in case PIC is disconnected).
- a structured approach to communication helps, ie: a PIC address, a command, data and checksum.
- slaves then look at the PIC address and decide if it applies to them, a "calling all slaves" address is also useful.
- a local command can help support various processing.
- data can be as big as you need it.
- and checksum can be as simple as addition of every byte sent, a word variable has more room.
- RS232 is great for Master to multiple Slaves, as long as only 1 slave replies back UNLESS:

...
TXSTA.5 = 1                                 ' Enable USART TX function

HSEROUT (slave sends reply only when spoken to by master)

TXSTA.5 = 0                                 ' Disable USART TX function
...

There's more than one way to skin a cat, but this was by far the easiest to have more than 1 slave on the MASTER RX line. There may still be an issue with this solution, but I have 6 slaves sharing a master RX line right now and they're all purring nicely.

Thanks to all that helped me work through this (don't even want to count how many days it took to get this working).

Robert

[dhouston]

The MAX3322E & MAX3323E are designed for this, as well, if using an RS232 transceiver.
http://www.maximintegrated.com/datas...ce=supplyFrame

[JoseJimenez]

Hi,
I am assembling this circuit. 1 Week ago i am suffering of the same situation that you have.
I am conecting 5 PIC 16F690, 1 as master (Tx conected to 4 Rx) and 4 slaves (all tx in parallel with other slaves...)

If I only conected 2 pics (P2P) all works fine, but adding 1 more, the Tx from 1 slave to master is corrupted.

I have the solution, can you reply what did you do to solve?


/jose p

[JoseJimenez]

this is my mail:
[email protected]

[Demon]

Hi,
...can you reply what did you do to solve?

I have only 1 slave enable the TX line at one time:
http://www.picbasic.co.uk/forum/show...809#post116809

Robert

[sayzer]

1. Two Schottky diodes on TX lines could be one solution. This way, one TX line does not effect the other.

or if not using diodes,

2. After each Transmit, you may disable USART and make TX pin input pin. When you need to send again, make TX pin an output pin and enable USART, then transmit.
If one TX line is an input pin, it will not effect the network during the transmission of other TX line.

These two are only suggestions and are not tested.

[Demon]

Can't comment on the diodes, but disabling USART also turns off receive. That's why I disabled only transmit.

[Demon]

Nope, not my video. That's Jose's and he uses transistors. I preferred a software solution, no extra parts involved.

All Slaves keep their TX line disabled until they are spoken to by the Master and have to send back a reply.

This post is for the next guy that tries to do this. A few things I learned:

- you can put a basic MAX232 on the TX and RX lines and "watch" what is being sent around your network.
- 4K7 pull-up resistors are good for master and slave RX pins (supposedly only necessary in case PIC is disconnected).
- a structured approach to communication helps, ie: a PIC address, a command, data and checksum.
- slaves then look at the PIC address and decide if it applies to them, a "calling all slaves" address is also useful.
- a local command can help support various processing.
- data can be as big as you need it.
- and checksum can be as simple as addition of every byte sent, a word variable has more room.
- RS232 is great for Master to multiple Slaves, as long as only 1 slave replies back UNLESS:

...
TXSTA.5 = 1                                 ' Enable USART TX function

HSEROUT (slave sends reply only when spoken to by master)

TXSTA.5 = 0                                 ' Disable USART TX function
...

There's more than one way to skin a cat, but this was by far the easiest to have more than 1 slave on the MASTER RX line. There may still be an issue with this solution, but I have 6 slaves sharing a master RX line right now and they're all purring nicely.
...

The only addition I would add to my list is using a MAX232 on each PICs for stability when using very long cables. It's not known at this point how "long" a network has to be for USART to become "less reliable".

My project will communicate underground between the house, garage and shed (at least 100' end to end). I plan on using MAX232 chips; it's not like they are expensive.

Robert


EDIT: The existing "fried" commercial alarm system has a MAX232, so it's a known solution.

[tumbleweed]

You can't have multiple MAX232's sharing TX and RX lines... the TX signals will conflict.

Even one output to multiple inputs can easily exceed the device specs since each input has about 5K ohm input resistor.

[HenrikOlsson]

Hi,
This....

TXSTA.5 = 1                                 ' Enable USART TX function
HSEROUT (slave sends reply only when spoken to by master)
TXSTA.5 = 0                                 ' Disable USART TX function

...is also a bad idea.

The HSEROUT will load TXREG with the last byte to be sent, then the program continues. If the next line turns off the transmitter the last byte won't be sent properly.

Poll TXIF to determine when you can turn off the transmitter.

If this is for anything more than messing around, use RS485 or something designed for the purpose.

/Henrik.

[Demon]

...
The HSEROUT will load TXREG with the last byte to be sent, then the program continues. If the next line turns off the transmitter the last byte won't be sent properly.
...

Weird, nothing unusual came up when I was doing my tests back then; no bytes lost, no data loss. I'm going to have to test this with a higher volume of data transfer and add the polling of TXIF as you suggest.

I just read a RS485 app note and my head hurts.
http://www.analog.com/static/importe...tes/AN-960.pdf

Robert

[tumbleweed]

TXIF only means that you can load the TXREG.

You need to poll TRMT to know when the byte has been shifted out of the TSR (Transmit Shift Register) and you can disable the output. TRMT gets set halfway into the STOP bit.