Communication Protocols (Which one to use)

[Gryd3]

I have an ongoing project sitting on the back burner, and before I commit, I like to iron out as many details as possible.
I have been looking into communication protocols like I2C, and the 1-wire protocol, but am unsure what will be suitable. There will be a single master control module, and multiple slaves. (Slave addressing is required, but does not need to be explicitly supported by the communication protocol.)

My project will involve wired communication that must be able to travel 20 feet. Data transmission rate is not as important, as there will be two operating modes:
Mode Select, - which will require a single byte of data to select the current operational mode.
Mode Program, - which will require ~18 bytes (enter program mode, program slot, <program 2 - 17>)

I need something reliable, and easy to implement, as I only have basic C skills, and would like to do this with a PIC rather than a bloated Arduino or Raspberry Pi.

Ideas, suggestions and all sorts of questions are welcome. I'd like to hear some insight before I pick on of many roads and realize at the end that there was a better path.

 

[KrisBlueNZ]

20 feet is a problem for I²C. One-wire is supposed to be able to cover that sort of distance (it's designed for use in HVAC monitoring, among other applications). Input capture is helpful for receiving, and output compare could be useful for transmitting. Whatever method you use, you should use some kind of error checking. One-wire devices use an 8-bit CRC but if you're sending 18 bytes you might want to use a 16-bit CRC. No doubt there are other options. How many wires? What type of wires? How many slaves? What bandwidth in each direction?

 

[Gryd3]

20 feet is a problem for I²C. One-wire is supposed to be able to cover that sort of distance (it's designed for use in HVAC monitoring, among other applications). Input capture is helpful for receiving, and output compare could be useful for transmitting. Whatever method you use, you should use some kind of error checking. One-wire devices use an 8-bit CRC but if you're sending 18 bytes you might want to use a 16-bit CRC. No doubt there are other options. How many wires? What type of wires? How many slaves? What bandwidth in each direction?

Bandwidth is minimal. The 'mode select' will simply tell the slave what program to run. If response occurred within 1-2 seconds I would be a happy man... So I have essentially removed bandwidth from the equation, as 50Hz would be way more than fast enough to switch the operation mode of 3 slaves within a second.
I planned for one way communication, as I don't need the slaves to send anything back. They will blindly do the last thing they were told to do. (This will allow me to address two slaves the same to have them react in unison)
Number of conductors is a non-issue as well, but for simplicity sake, less is more. I do not want to run Cat5 to each slave
Also, to help ensure my signal arrives in good condition, I will be stripping the outer jacket off a Cat5/6 cable and using the pairs for data transmission. (One pair for 1-wire comms... one for ground, other for data)
The number of unique slaves initially will be 3, but I would like to be able to add more to the same data line (simply by giving the slave a unique ID). Addressing multiple slaves at once with the same Slave ID is not a requirement... but a feature I was going to try to work in.

 

[shumifan50]

This sounds ideal for RS485 or CAN, both supported in hardware on PICs. RS485 is a differential protocol using 2 wires and used extensively in DCC model railroads. It is quite reliable over the sort of distance you are needing and it is simple to drive as you use a MAX485 (MAX3485 for 3.3V PICs) connected to the USART. It even supports addressing. There are no special wiring requirements except proper termination.
I have nor used CAN connections, but is is extensively used in automotive systems, so must be reliable to work in such a noisy environment.

I strongly recommend some protocol where the slaves at least acknowledge reception. This, again, requires no additional wiring for RS485.

 

[KrisBlueNZ]

I planned for one way communication, as I don't need the slaves to send anything back.

That's not a good idea. Don't you want to find out immediately if there's a failure? Perhaps if you describe the whole project we can be more specific.

Also what are the power requirements for the slaves? If they're independently powered, RS-485 or RS-422 is probably a good option, although it requires some hardware and firmware complexity (differential signal lines with transceivers, and transmit enable control for RS-485). If they have a low power consumption requirement, and no local power sources, one-wire might be able to power them as well as communicate with them.

They will blindly do the last thing they were told to do. (This will allow me to address two slaves the same to have them react in unison)

How "exact" do you want the unison to be? You could use delayed action to make them act at the same instant.

Number of conductors is a non-issue as well, but for simplicity sake, less is more. I do not want to run Cat5 to each slave

One-wire: two wires including power, if power requirements are minimal
RS-485: two wires, excluding power
RS-422: four wires, excluding power.

The number of unique slaves initially will be 3, but I would like to be able to add more to the same data line (simply by giving the slave a unique ID). Addressing multiple slaves at once with the same Slave ID is not a requirement... but a feature I was going to try to work in.

More info on your project would be helpful.

 

[Gryd3]

This project will control slave lighting modules.
This ties into a previous topic I had discussed regarding power supply to high power LEDs.

The Master Device will be the main controller that will control the connected slaves.
After installation, the Master will only send 'mode select' commands to the slaves to tell them to start to run one of the pre-programmed operational modes. (Added complexity will allow the master to, on special circumstances, reprogram the slaves. This will NOT reprogram the Microcontroller, but the values passed will be stored in the slave device for use during operation *This is not a confirmed feature)

Each slave will control 8 LED channels. The LEDs will either be on or off. There will be no fading or PWM. The light sequence is merely a collection of bytes that are stored in memory and read sequentially ( and looped ). A different collection of bytes is selected for a different light pattern.

Power requirements are too much for the 1-wire protocol to be used to provide power. The idea was to provide power to the devices independently. All devices will be powered from the same 12V source, but each device will have it's own voltage regulation for driving logic, and all devices will share the same ground. Data lines will then be run. Location is not set in stone yet, but ideally I would like to have a common signal wire(s) so that I am not obligated to daisy chain the devices together. Ideally a bus topology so that the slaves do not have to re-transmit or repeat the signal, this will allow greater flexibility on installation.

If there is a delay in starting two slave devices at the same time, that is acceptable. I am also accepting that without 2-way communication, that keeping all the slaves in synch will require either a heartbeat signal from the master, or I will allow them to drift if operated for prolonged periods.
Because of the simplicity of the slaves, I do not feel that 2-way operation is a requirement, but if the protocol implements 2-way communication I might as well take advantage of it. Otherwise if the communication protocol only does 1 way from master to slave. I am sure that will suite my needs. (If a slave does not receive a heartbeat, it should stop)

So far, I like the sounds of CAN, 1-Wire, and RS-485, but am also considering a custom 2-wire protocol.
(Wire 1 is the heartbeat and data, wire two will switch between the two)

 

[shumifan50]

To use 2 wire (signal+ground) might work in an environment that is not too electrically noisy, but thicker wires will be required to avoid too much of a voltage drop. I have used burglar alarm cable (6 core) over about 12 feet reliably to connect remote TSOP2438 IR sensors to a PIC but these were point to point connections. To handle multiple addressable slaves I would still go with RS485 or CAN and at least an ACK/NAK protocol.

 

[Gryd3]

Well.. I'll use this as a reference on CAN:
http://ww1.microchip.com/downloads/en/AppNotes/00930a.pdf

This is my first attempt at using any sort of communication protocol on a microcontroller. I've got a good feeling about CAN, it's been used in automotive for years. As an aside, as I learn this I'll pick up skills for tapping into the CAN bus on my car

 

[shumifan50]

J1939 seems to be a specific CAN implementation for ECU control, but I could be wrong as I did not read the entire document in detail, just glanced over it.

 

[Arouse1973]

I agree with Shumifan50 I was going to mention CAN or RS485.
Adam

 

[Steve Garratt]

I've never used CAN but I have used RS485 successfully in many applications. I'm sure that it would do the job here. Note that while RS485 is an addressable protocol there is nothing stopping you implementing an address which is accepted by some or all receivers. This would satisfy your requirement to have multiple slaves react to the same message.

 

[KrisBlueNZ]

Thanks for the description of the project.

Remember that there will be voltage drop in your power and ground rails, so one module's ground won't be the same as the next module's ground. The supply current can be minimised by using a high supply voltage and a switching converter on each module.

This probably rules out 1-wire and maybe CAN (I don't know much about CAN). Asynchronous serial data over RS-485 is still a good option as long as the ground differential doesn't exceed around 5V; if it does, isolated RS-485 transceivers are available.

As Steve says, it's possible to implement broadcast and multicast messages on RS-485, although they can't be acknowledged directly; a separate message to each slave can be used to confirm that the broadcast/multicast message got through.

 

[Arouse1973]

Hi Steve
I am guessing being only the physical layer you would have to give the controller a time stamp of when they could reply, otherwise they would all try to respond at the same time. Is that right?
Adam

 

[KrisBlueNZ]

I am guessing being only the physical layer you would have to give the controller a time stamp of when they could reply, otherwise they would all try to respond at the same time. Is that right?

Not normally; in RS-485 systems that I know of, slaves only respond immediately after being addressed. Broadcast and multicast messages aren't acknowledged; slaves are polled one at a time after the broadcast/multicast to confirm that they received it, if confirmation is needed.

 

[Gryd3]

I have read here than CAN can use differential 5V signals to communicate which would solve the drop in supply rails would it not? (There are a lot of CAN specifications... I've just scratched the surface so far of a couple)
Because of the project design, 12-14V will be supplied to each module. (Which is potentially noisy) Each module will be responsible for filtering and stepping down the voltage to an appropriate level for the logic within.
One of the main reasons I was leaning on the CAN side for this project was so that I could learn about it to use in alternative / future projects. I'm a little nervous at the amount of material and specifications available, and the fact that the closest I have come to dealing with communication protocols was with WireShark doing traces for SIP traffic.
I'm looking at both communications at the moment...
RS485 from what I have read so far seems to offer higher transfer speeds and longer distances (Which I interpret as a more reliable signal if I transmit under the max length / speed thresholds)
RS485 also looks easier to implement. CAN seems to be very involved. (And I think I will get better support on here with RS485)
For now, it's a bit of a waiting game for me while I do some digging. I will also need additional PICs or some other item to test communication with.

 

[Gryd3]

Hi Steve
I am guessing being only the physical layer you would have to give the controller a time stamp of when they could reply, otherwise they would all try to respond at the same time. Is that right?
Adam

My understanding so far is that I will need to address one slave at a time to avoid the responses from colliding. Or if I send a message to multiple slaves at the same time (like a sort of broadcast) I would need to suppress any responses from the slaves. CAN has collision detection and mediation... but wow, there seems to be a lot to soak in.
*[Please regard any responses regarding CAN or RS485 with respect that I don't know them in detail yet!... my way of admitting before hand that I may be wrong]

*Edit: I should refresh my window more often... Kris has better intel above

 

[Arouse1973]

Not normally; in RS-485 systems that I know of, slaves only respond immediately after being addressed. Broadcast and multicast messages aren't acknowledged; slaves are polled one at a time after the broadcast/multicast to confirm that they received it, if confirmation is needed.

Thanks Kris
I have only used the driver chips themselves as a way to transmit our own protocol. This multicast and slave thing you are on about, are they special modules/ICs?
Thanks
Adam

 

[shumifan50]

The easy route to implementing RS485 is to use the UART built into the PIC. It is made into RS485 by feeding the output of the USART into a MAX485 differential buffer/driver. This makes debugging really easy as you don't need any special kit to view what goes on on the comms lines. Connect through a level shifter like MAX232(MAX3232 for 3.3v) directly to the RS232 port on a PC. You can even make a Y connection to see both sides of the protocol. Standard RS485 to RS232 converters are available to easily connect to a PC. I have not seen similar devices for CAN, but then I have not been looking for them.


The main requirement of RS485 is proper termination of links.

Any protocol that has crash detection inherently becomes slower as traffic increases and therefore more collisions occur. So it is still advisable to implement a poll/select protocol, removing crashes.

@adam: It has been a while since I used RS485, but I seem to remember that there are special address settings to broadcast, but I do not remember seeing any way of doing selective multicast - it is everybody or one at a time.

As a final comment: I don;t think it is a good idea to go for CAN if this is your first attempt at a communications project. In this case I do believe RS485 is a better choice.

 

[Gryd3]

Thank you all for your insight.
From the sounds and looks of things, I should ditch CAN and practice first with some very simple serial comms before attempting RS485 (Breadboard + hello world type program).
I have found some free samples of the drivers, I'll think ill get my hands on them and play.

 

[(*steve*)]

Getting into this late, but depending on how you power the devices, you can superimpose a signal onto your power supply to signal devices.

The advantage is that as long as all devices are powered from the same source they automatically have communication. In the general case you inject the signal onto the mains.

You have to do everything yourself, and you generally either blindly transmit short packets or employ some sort of CSMA technique to try to avoid collisions.