EEVblog® Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: thedrummer2016 on April 06, 2018, 02:16:47 pm
-
Hello All,
I am working on a project which contains four PIC mcu's that need to communicate with each other. One is the master and will be talking to the other 3 slaves but the slaves will not need to talk to each other. The three slave mcu's are on removable hardware so they may come and go and I need the others to continue to communicate. They are all within 400mm of each other and it is a noisy industrial environment.
I am thinking full duplex RS-485 due to the transceivers built in ESD protection and industrial harness but that may be completely overkill. I could probably get away with an SPI or I2C bus but i'm concerned about noise and damage to my MCU's during connection and disconnection.
Can anyone offer advice or suggestions as to which method would work best for this application?
-
How about simple old RS232, should be robust enough but are you going to use a poll-select mechinism for the slaves to reply to the master ?
-
Here's an RS485 protocol for exactly the kind of thing discussed in the OP.
http://www.bdmicro.com/code/robin/ (http://www.bdmicro.com/code/robin/)
-
400 millimeters is not very far even in an industrial environment.
Is there a requirement for hot plugging or will power be removed when adding and removing the modules?
ESD protection is not difficult to add to logic level drivers and receivers.
RS-485 and CAN allow multiple parties on the same bus. Some PICs include CAN transceivers.
-
CAN would be a nice option if you can live with short messages. At least a lot of the low level protocol handling will be taken care off. Don't underestimate noise on cables. SPI and I2C are definitely not suitable for transport from one board to the other.
-
Thanks for the comments / suggestions. I considered using plain ole 232 but didnt want to deal with electronically selecting devices and I wasnt sure how robust the signal would be. I like having the differential pairs in 485 for noise cancellation but not sure if its necesary at this short distance.
There is a requirement for hot plugging as these units will be connected and disconnected several times a day without removing power.
CAN is a very solid network but im not very familiar with it from a low level implementation standpoint.
rstofer: I like the Robin idea, thanks for passing along.
-
Polling mode on RS232 is easy:
1) Master sends data to all slave (TX to several RX)
2) on the Master, all RX's are OR'ed on the logic level side (between RS232 receivers and µController)
3) Master polls slave by sending frame like [MARKER][Address][Datas], slave by slave
4) If the address match on the slave side, answer to master.
Theo
-
ESD protection is not difficult to add to logic level drivers and receivers.
Right. I agree that rs485 is unnecessary here. I would just use I2C with proper ESD protection. Make sure connectors are right. You would want to connect GND and VCC first, only then data I/O.
-
CAN would be a nice option if you can live with short messages. At least a lot of the low level protocol handling will be taken care off. Don't underestimate noise on cables. SPI and I2C are definitely not suitable for transport from one board to the other.
don't you need for at least two nodes to be present at all time? (the two having the bus terminations)
-
I just finished a project with the exact same scenario. 1 master and 3 slaves in my case. I used the device UART but interfaced them with RS485 differential full duplex transceivers. The master had transmitter and receiver always enabled. The slaves had their receivers enabled and transmitter under uC control.
The master would send out a packet consisting of device destination, number of bytes to follow, and the message. If the device destination matched one of the slave devices, it would enable its transmitter, respond, and then disable the transmitter. All slaves would receive the packet from the master and would ignore it if the device destination byte didn't match.