Daisy Chaining HSER RX ports

[markscotford]

I need to communicate information to 5 boards running 18F2455 PIC's for a mains lighting controller system. I should have asked this question before designing the boards and having them made I guess (a bit too over excited). I do not need any communication back from the boards, just sending commands to them. Is it OK to connect all the hardware serial port RX inputs of the 5 boards together, and connect these to one master controller board's hardware serial TX line?

I was thinking on the lines of allocating each receiving board with a specific address, and the master controller wishing to send data to a specific board, sending out that boards address byte, followed by 8 data bytes. Each receiving board would ignore any activity on the serial line, unless their address had first been recognised, and then reading in the following 8 data bytes. Any other board ignoring the data.

As you can tell, I am a fairly new to this sort of Serial milarky.

Thanking you in anticipation.
Mark in Spain.

[mackrackit]

It is doable. If the boards are very far apart you will need to boost the signal to RS232 levels.

[amgen]

you could frame all sends such as [ id,data1, data2, etc], the "[" would trigger recievers to take data and the "]" would cause all recievers to parse with arrayread for their instructions then all wait again for next send.

Don
amgen

[Charles Linquis]

I have done this many times. It works as follows:

The Master has either a hardware TX or a software TX serial port connected to the HARDWARE RX serial ports of all the slaves.
The slaves have all their SOFTWARE TX serial ports connected together and to the (preferably) Hardware or software RX port of the master.
The line connecting the slave's TX ports to the Master's RX port is pulled up with a 2.2K resistor to Vcc.
The slaves have their address stored in EEPROM, which they read on every power up.


The Master sends address,length, data and checksum.

The Slaves run a RX interrupt on their HARDWARE serial port.
If they see their address they start receiving data until they get a timeout on the HSERIN command (this is all inside the ISR)
When they get a timeout, they check the command, length and checksum.
If all is OK, they send a response out of their SOFTWARE serial port in OPEN COLLECTOR mode. This response is sent inside the recieve ISR,
so it will happen quickly after the data is received.
The slave's response has the slave address,length, data and checksum

After the Master makes a request, it waits only 20 mSec for the slave's response. But the data will be there.

Using HSERIN in an interrupt-driven mode for receive on the slave means you will never miss a request.
The fact that the slaves are sending in an open-collector mode means you will never have bus contention.

You have to run the slave SEROUT2 command in INVERTED (and OPEN COLLECTOR) mode.


It all works perfectly.

Something you may have to watch out for - when you enable the USART on some chips, you automatically "steal" both PORTC.7 and PORTC.6 for
the HARDWARE serial port. So, if you are using a device in this "hybrid mode" (hardware for receive, software for send) and you are using
ports C.7 and C.6, you have to enable the USART, and as soon as you receive the data, you then must DISABLE the USART before you can
do a software send on PORTC.6. After you are done sending, then you simply re-enable the USART.

[Charles Linquis]

I guess I should add - the reason you receive in hardware and send in software is -
Hardware receive is the only way you can never miss a byte (and still have your program doing something).
Software send is the only way you can get an open-collector output without using an extra chip on your board.

[ardhuru]

Your scheme should work well. As macrackit says, I would use a transistor at the master's tx, with a pull-up to +12V. Then fan out the output to all the slaves.

Did something similar, but it was the other way. All slaves *sending* to a single pin of the master pic. In this case, I had to use a rudimentary scheme to cater for the collisions.

Regards,

Anand

[dhouston]

You might also consider using a DG408 or MAX398 multiplexer IC (with or without a RS232 transceiver) which doesn't require as much fancy footwork. You can find app notes using it for a pseudo-multidrop RS232 setup. However, it does require a few extra pins.

[markscotford]

Thanks everybody, thought I may have run before walking, but seem to have got away with it. Thank you Charles, your post was very helpfull. The boards are all daisy chained with 10 way ribbon cable, linking Power & HSER ports together (with some input protection). The boards are no more than 10cm away from each other. The hardware receiving, software sending idea, switching off modes between communications idea is also helpfull.

Let the heart aches and long nights begin.

[Charles Linquis]

Believe it or not, I used the technique described to communicate over 340' of Belden 24GA unshielded 4 conductor cable (power, ground, transmit, receive).
I was running 9600 baud and I had to reduce the pull-up resistors (1.5K ohms on each board), but it worked. No signal boosting - nothing but two 18F2221's on one end and an 18F8723 on the other.

[Charles Linquis]

Also, the 2221's were running on their internal oscillators, the 8723 was on a crystal.