Multiple PICs on usart network

[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.

[HenrikOlsson]

Robert,
I've done quite a bit of work with half duplex RS485 where you have a pin telling the tranceiver chip if it should operate in TX or RX mode.
If I do

TxRx = Tx   ' Switch tranceiver to TX mode
HSEROUT["Test",10,13]   ' Send data
TxRx = Rx  'Sitch tranceiver to RX mode

The last byte (13) will not go thru properly because the tranceiver chip is switched from Tx to Rx mode in the middle of it. I'm pretty sure you'll get the same thing when disabling the USART. It's possible though that a low oscillator frequency in combination with high baudrate "masks" the problem.

Tumbleweed,
TRMT is the correct bit, thanks for pointing that out!

/Henrik.

[richard]

they might get away with it because the last chr is 13 , so that means the last 4 bit and the stop bit all leave the tx line high anyway