I am going to work on a project involving multiple devices on the same network(3 or more). One device will have user input and display(master). The other devices(slaves) will just collect sensory data and possibly process PID control loops. Data speeds are not a priority(< 1Mbps is okay).
The master will read data from the two slave devices, and it may have to change manipulate data on the slaves(PID gains are an example).
There may be times when device 2(slave) may need information or data from device 3(slave).
More devices may be added in the future.
My questions are:
1) Is RS485 a good physical layer for this type of project?
2) What would be the best communication protocol to use? I only know of MODBUS and PROFIBUS. Are there any others that would be a good fit given the very limited requirements listed above?
With short distances (tens of meters) and speeds The master will read data from the two slave devices, and it may have to
One way of implementing this is to let the master read from slave 2 and send it to slave 3 in a separate transaction.
In the RS-485 network (Modbus/Profibus DP) the master could also send out read requests sequentially to all slaves, the slave replies with all data it wants to share. The master ignores the response, but all slaves on the RS-485 bus will snoop the response messages from the other slaves and pick the information they need. Of course, this does not work with standard COTS (Commercial, of-the-shelf) slaves and when doing in-house design, a lot of coordination is required to get the network working.
In a CAN bus system, each station (master or slave) broadcasts all data each wants to share in up to 64 _bit_ (8 byte) net payloads without centralized bus arbitration. Each node will pick those messages they are interested in, based on the 11/29 bit message ID.
32 nodes is the limit for standard RS-485 transceivers, but this can be extended with repeaters or using 1/2, 1/4 etc. unit load transceiver.
OK.
It lot depends if you are designing your own nodes or use off the shelf nodes.
Modbus is simple that it does not contain much of the higher protocol layers, so you can implement them as needed on your own. Unfortunately, Modbus is very picky about message framing timing, especially on the slave side, so at 1 Mbit/s, you would in practice need UARTs with the "idle timeout" or hardware timers, with at least a few microsecond resolution.
If you want to operate with COTS Profibus-DP devices, you would have to implement much more of the protocol stack, including parameterization.
If no COTS devices are used, you can pick just the Profibus-DP framing structure (which is similar to e.g. the framing structure on IEC 60870 series protocols), which is not so picky about timing as Modbus is.
If there is a lot of slave to slave communication, in which the master is not interested in, the CAN bus should also be considered. Much of the protocol lower levels are implemented in hardware (usually integrated into some microcontrollers).
Apparently you are the student who doesn't have the slightest clue neither about the hardware nor about the software. The project is supposed to operate at the tabletop conditions. Is that right?
For that reason, the best approach for you would be stick to the evaluation boards that you are going to use, and implement whatever interfaces they have already. Most likely it is going to be RS-232, SPI or I2C. So, you can do the ring topology over RS-232, or star topology over I2C or SPI.
As for the protocol, most practical solution is to roll your own. There is no point for you in messing with MODBUS or PROFIBUS other then for the educational purpose.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
Since distance is only 4 feet, simplest way is to make a TTL level RS232 wire-or'd bus. Just requires adding an open collector TTL buffer to each transmit line, and resistor pullup.
The output of a UART is TTL. UART output is generally referred to as RS232, though RS232 is really +/-12V interface definition. Don't use the RS232 driver. Use a TTL open collector driver. Something like 74HCT06 or something like that. Maybe 1K pullup. Then all device or'd outputs can coexist on one wire without damaging each other.
Then you have 3 wire bus; gnd, tx, rx and don't have to buy expensive RS485 I/O chips.
You misspelled "generally" as "incorrectly." The signal polarity (mark-high versus mark-low) is also flipped and there are a number of other constraints that follow the designation.
Practitioners generally refer to a UART's external interface as asynchronous serial or async serial or just async, which itself can interoperate with a range of physical layers.
While wire-ORing some TTL open collector outputs would be sufficient to implement a bus _within_ a single PCB, there are hardly any PCBs more than 1 m long these days :-)
When interconnecting any PCBs with cables at least a few centimeters long, you are going to have ground potential problems, due to the resistance (and most importantly the inductance) of the ground connection.
When transferring data from one PCB to an other, I really would suggest using some kind of differential signaling such as RS-485 or CAN bus. The other alternative is to use for instance Biphase-M coding, which will pass through transformers and hence the PCBs can be galvanically isolated from each other.
It must be regional. I've been doing microprocessor stuff involving serial ports for 25 years, and I don't think I've ever heard it used that way.
But, that still doesn't make it RS232. :)
Even if it's not 100% specific, the term "async" is at least correct (and it's the term that comes to mind for me). Since RS232 interfaces can be synchronous, using the term "RS232" to specify an async interface that doesn't use RS232 levels is wrong in multiple ways...
I've run over 10 feet using plain TTL (not open collector) over 30 AWG cable at around 50 kbps without any problems. The DC resistance of the ground connection is typically not a problem if you match the number of signal and ground wires and if you're not powering your device over the same cable. The inductance and capacitance of the cable does need to be accounted for, but placing suitable series resistors on both ends of each signal line and limiting your data rate will reduce the effects. The series resistors can also offer a degree of protection and support for hot-plugging if your TTL ports include clamping diodes.
Now, the original requirements called for a protocol that can support all three types of transfers: master to slave, slave to master, and slave to slave. There was no mention of any timing or latency restrictions so something like MODBUS could be used and each slave to slave transfer would be substituted by a pair of master/slave transfers. However without knowing more details like maximum payload size, minimum latency, types of devices connected to the bus (FPGA, MCU, PC), buffering, media access, flow control, etc. it's hard to recommend a solution. Assuming low latency, small payload, MCU controlled devices, I would go for something that uses non-destructive arbitration like CAN. If you don't have/want a CAN controller then try something like SAE J1850, which uses a single data line and can easily be bit-banged from a small MCU.
I guess that you would have to run with Vcc at +3.5 V and Gnd at -3.5 V and there would still be questions, if even the required +/-3 V receiver voltage swing could be obtained. But clearly it is not within the required _transmitter_ voltage swing.
Also running 74HCT chips at 7 V is at the absolute maximum limit.
The original requirement was less than 1 Mbit/s, so speeds below 115 might be sufficient, or perhaps not.
Balanced connections may be an overkill, if devices are powered from the same power supply or they are separately battery powered or each powered through isolation transformers.
However, if the devices are powered by separate mains power supplies and the signal ground is connected to the chassis and PE connector, you may have quite a lot of problems, if the power cords are connected into different mains sockets when TN-C or TN-C-S mains wiring convention is used.
In such sockets, the potential difference between the PE connector of two mains sockets can be several volts and quite large currents will flow in your _signal_ ground connector from the PE terminal of one mains socket to the PE terminal of an other mains socket.
In the old days, even with proper RS-232 voltages, the ground potential differences caused a lot of problems when dumb terminals were connected to a computer from different rooms with different ground potential. TTL has mach lower noise margin than RS-232, so any extra current flowing in the signal ground would cause problems.
Differential connections such as RS-422/485 and CAN can tolerate several volts of common mode voltage, so this will solve most of the problems associated with TN-C and TN-C-S mains wiring.
I've also heard people say "RS232" when they mean a UART output, but it's generally from people with little technical experience.
There are many different ways to pass UART signals around (RS232, RS485 and RS422 are common, but you get transparent radio modems, line drivers, power line modems, fibre, simple transistor drivers, direct connection, etc.).
I think the only sensible way to refer to UART signalling is "UART". That's pretty clear to most people in most context. "async" or just "serial communication" are often used, and are fine if the context makes it clear what you are talking about.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.