^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) RS485 Serial Communications
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) 1. Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) EIA-485, also known as TIA/EIA-485 or RS-485, is a standard defining the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) electrical characteristics of drivers and receivers for use in balanced
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) digital multipoint systems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) This standard is widely used for communications in industrial automation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) because it can be used effectively over long distances and in electrically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) noisy environments.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) 2. Hardware-related Considerations
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) ==================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) Some CPUs/UARTs (e.g., Atmel AT91 or 16C950 UART) contain a built-in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) half-duplex mode capable of automatically controlling line direction by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) toggling RTS or DTR signals. That can be used to control external
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) half-duplex hardware like an RS485 transceiver or any RS232-connected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) half-duplex devices like some modems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) For these microcontrollers, the Linux driver should be made capable of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) working in both modes, and proper ioctls (see later) should be made
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) available at user-level to allow switching from one mode to the other, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) vice versa.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) 3. Data Structures Already Available in the Kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) ==================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) The Linux kernel provides the serial_rs485 structure (see [1]) to handle
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) RS485 communications. This data structure is used to set and configure RS485
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) parameters in the platform data and in ioctls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) The device tree can also provide RS485 boot time parameters (see [2]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) for bindings). The driver is in charge of filling this data structure from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) the values given by the device tree.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) Any driver for devices capable of working both as RS232 and RS485 should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) implement the rs485_config callback in the uart_port structure. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) serial_core calls rs485_config to do the device specific part in response
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) to TIOCSRS485 and TIOCGRS485 ioctls (see below). The rs485_config callback
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) receives a pointer to struct serial_rs485.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) 4. Usage from user-level
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) From user-level, RS485 configuration can be get/set using the previous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) ioctls. For instance, to set RS485 you can use the following code::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) #include <linux/serial.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) /* Include definition for RS485 ioctls: TIOCGRS485 and TIOCSRS485 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) #include <sys/ioctl.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) /* Open your specific device (e.g., /dev/mydevice): */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) int fd = open ("/dev/mydevice", O_RDWR);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) if (fd < 0) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) /* Error handling. See errno. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) struct serial_rs485 rs485conf;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) /* Enable RS485 mode: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) rs485conf.flags |= SER_RS485_ENABLED;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) /* Set logical level for RTS pin equal to 1 when sending: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) rs485conf.flags |= SER_RS485_RTS_ON_SEND;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) /* or, set logical level for RTS pin equal to 0 when sending: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) rs485conf.flags &= ~(SER_RS485_RTS_ON_SEND);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) /* Set logical level for RTS pin equal to 1 after sending: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) /* or, set logical level for RTS pin equal to 0 after sending: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) /* Set rts delay before send, if needed: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) rs485conf.delay_rts_before_send = ...;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) /* Set rts delay after send, if needed: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) rs485conf.delay_rts_after_send = ...;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) /* Set this flag if you want to receive data even while sending data */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) rs485conf.flags |= SER_RS485_RX_DURING_TX;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) if (ioctl (fd, TIOCSRS485, &rs485conf) < 0) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) /* Error handling. See errno. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) /* Use read() and write() syscalls here... */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) /* Close the device when finished: */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) if (close (fd) < 0) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) /* Error handling. See errno. */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) 5. References
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) [1] include/uapi/linux/serial.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) [2] Documentation/devicetree/bindings/serial/rs485.txt