RS485 real-time communication method under Linux

Abstract

The invention discloses an RS485 real-time communication method under Linux, and the method comprises the following steps: S1, writing an RS485 drive program under Linux, the main task of the drive program being managing serial port equipment, including configuring serial port parameters, processing data transmission and the like, and S2, using tools such as a logic analyzer or an oscilloscope, combining with an RS485 communication protocol, fully understanding the timing sequence requirement of RS485, and performing real-time communication through the logic analyzer. A transmitted data frame may be seen, including a start bit, a data bit, and an end bit. Under the Linux operating system, good real-time communication can be achieved, the real-time performance can meet the requirement of the main device, the problem of packet loss in RS485 communication under the Linux environment is effectively solved, and the stability and reliability of real-time communication are greatly improved.

Description

Technical Field

[0001] The present invention relates to the technical field of serial communication, and particularly to a method for real-time RS485 communication under Linux. Background Technique

[0002] Linux is a free-to-use and freely distributable Unix-like operating system, which is a multi-user, multi-tasking operating system based on POSIX and UNIX, supporting multi-threading and multi-CPU. It can run major Unix tool software, application programs, and network protocols. It supports 32-bit and 64-bit hardware. Linux inherits the network-centric design concept of Unix and is a multi-user network operating system with stable performance. It has become the most widely used Unix-like operating system in the world today, and the number of users is still growing rapidly.

[0003] As a common device communication method in the industrial field, RS485 is usually used in combination with a single-chip microcomputer. However, with the continuous progress of technology, various processors have gradually replaced the position of the single-chip microcomputer. In this evolution process, the industrial application's demand for real-time performance still remains. However, due to the dominant position of the Linux operating system in the industrial field, and Linux is mainly a non-real-time operating system, its real-time performance cannot meet the requirements of the master device, and packet loss often occurs during real-time communication. Therefore, we are faced with the challenge of meeting the real-time performance requirements in this environment. For this reason, we propose a method for real-time RS485 communication under Linux. Summary of the Invention

[0004] The purpose of the present invention is to provide a method for real-time RS485 communication under Linux to solve the problems raised in the above background technique.

[0005] To achieve the above purpose, the present invention provides the following technical solution: A method for real-time RS485 communication under Linux, including the following steps:

[0006] S1. Write an RS485 driver program under Linux. The main task of the driver program is to manage the serial port device, including configuring serial port parameters, processing data transmission, etc.;

[0007] S2. Use tools such as a logic analyzer or an oscilloscope, combined with the RS485 communication protocol, to fully understand the timing requirements of RS485. Through the logic analyzer, the transmitted data frame can be seen, including the start bit, data bit, and end bit;

[0008] S3. Provide an additional read-write interface at the RS485 driver layer for the application layer to read and write and cache data. For RS485 communication, the driver layer provides a read-write interface to the application layer to facilitate data interaction between the application layer and the RS485 device. The read-write interface needs to handle data caching to ensure data integrity and correct transmission;

[0009] S4. Read and process the data received by RS485 in the RS485 driver, and send the cache data filled in by the application layer to achieve real-time communication. When reading and processing data, if the data is transmitted according to a certain protocol format, such as a frame format containing a start bit, data bit, check bit, and stop bit, it needs to be parsed. Depending on the protocol, it may contain check bits, such as parity check, CRC check, etc.

[0010] Furthermore, when debugging RS485 communication in S2, the signal waveform can be viewed through an oscilloscope, or a serial terminal tool can be used for data interaction. If communication abnormalities occur, check whether the line connection, baud rate setting, signal level conversion are correct, and whether the state control logic in the software is reasonable.

[0011] Furthermore, in S3, when writing cache data, the application layer can put the data into the cache first, and the driver layer sends the data in the cache in a timely manner according to the communication status of RS485 (such as whether it is busy). When reading, the data received by the driver layer is first put into the cache, and the application layer can read the data from the cache at an appropriate time.

[0012] Furthermore, in addition to the simple first-in first-out (FIFO) cache strategy, other strategies can be adopted according to application requirements when caching data in S3. For example, if some data has a higher priority, these data can be processed first. Dynamic adjustment of the cache size can also be considered to optimize the cache performance according to the actual communication load.

[0013] Furthermore, the driver in S1 needs to follow the device driver model of Linux, including defining the device number, registering the device, implementing device operation functions (such as open, read, write, close, etc.), and other operations. For example, in the open function of the driver, the device initialization operation can be performed, such as configuring the baud rate, data bit, stop bit, check bit and other parameters of the serial port; implementing the logic of reading data from the RS485 serial port in the read function; implementing the logic of writing data to the RS485 serial port in the write function; and releasing device resources in the close function.

[0014] Furthermore, the baud rate of the communication can be determined by the waveform in S2. For example, if the time to send 1 bit is 34.795÷4=8.69875us, then the baud rate is approximately 115,200bit / s.

[0015] Furthermore, taking CRC check as an example in S4, if the sender adds a CRC check code at the end of the data, the receiver needs to recalculate the CRC check code and compare it with the received check code.

[0016] Compared with the prior art, the present invention has the following beneficial effects:

[0017] The present invention can realize good real-time communication under the Linux operating system, and the real-time performance can meet the requirements of the main device, effectively solves the packet loss problem in RS485 communication under the Linux environment, and greatly improves the stability and reliability of real-time communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is a data processing flow chart of the driver layer under Linux of the present invention;

[0019] Figure 2 The data processing flow chart of the present invention at the application layer under Linux. DETAILED DESCRIPTION

[0020] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0021] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "lateral", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside" and the like indicate positions or positional relationships based on the positions or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first" and "second" are used only for descriptive purposes, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, unless otherwise specified, "multiple" means two or more.

[0022] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0023] See also Figure 1-2 , a RS485 real-time communication method under Linux, comprising the following steps:

[0024] S1. Write RS485 driver under Linux. The main task of the driver is to manage serial port devices, including configuring serial port parameters, processing data transmission, etc.

[0025] S2. Use tools such as logic analyzer or oscilloscope, combined with RS485 communication protocol, to fully understand the timing requirements of RS485. Through the logic analyzer, you can see the sent data frame, including the start bit, data bit and end bit.

[0026] S3. An additional read-write interface is provided at the RS485 driver layer for the application layer to read and write and cache data. For RS485 communication, the driver layer provides a read-write interface to the application layer to facilitate data interaction between the application layer and the RS485 device. The read-write interface needs to handle data caching to ensure data integrity and correct transmission.

[0027] S4. Read and process the data received by RS485 in the RS485 driver, and send the cache data filled in by the application layer to achieve real-time communication. When reading and processing data, if the data is transmitted according to a certain protocol format, such as a frame format containing a start bit, data bit, check bit, and stop bit, it needs to be parsed. Depending on the protocol, it may contain check bits, such as parity check, CRC check, etc.

[0028] Specifically, when debugging RS485 communication in S2, the signal waveform can be viewed through an oscilloscope, or a serial terminal tool can be used for data interaction. If communication abnormalities occur, check whether the line connection, baud rate setting, signal level conversion are correct, and whether the state control logic in the software is reasonable.

[0029] In the specific implementation, when writing cache data in S3, the application layer can put the data into the cache first, and the driver layer sends the data in the cache in a timely manner according to the communication status of RS485 (such as whether it is busy). When reading, the data received by the driver layer is first put into the cache, and the application layer can read the data from the cache at an appropriate time.

[0030] Specifically, in addition to the simple first-in first-out (FIFO) cache strategy, other strategies can be adopted according to application requirements when caching data in S3. For example, if some data has a higher priority, these data can be processed first. Dynamic adjustment of the cache size can also be considered to optimize the cache performance according to the actual communication load.

[0031] During the specific implementation, the driver in S1 needs to follow the Linux device driver model, including defining the device number, registering the device, and implementing device operation functions (such as open, read, write, close, etc.). For example, in the open function of the driver, the device initialization operation can be performed, such as configuring the baud rate, data bit, stop bit, check bit and other parameters of the serial port; the logic of reading data from the RS485 serial port is implemented in the read function; the logic of writing data to the RS485 serial port is implemented in the write function; and the device resources are released in the close function.

[0032] Specifically, the baud rate of communication can be determined by the waveform in S2. For example, if the time to send 1 bit is 34.795÷4=8.69875us, then the baud rate is approximately 115,200bit / s.

[0033] In the specific implementation, the CRC check is taken as an example in S4. If the sender adds a CRC check code at the end of the data, the receiver needs to recalculate the CRC check code and compare it with the received check code.

[0034] In practical application: Since RS485 is a half-duplex communication method, time-division multiplexing is a very common technology. This solution is based on time-division multiplexing. The real-time requirements of RS485 need to be determined in the design documents of the main equipment. Each industrial product has a different design; the common timing requirements range from 20us to 2ms.

[0035] Figure 1 This chapter describes the data processing flow in the RS485 driver, receiving RS485 data in the interrupt function, and responding to the data. It can be divided into the following three situations.

[0036] Scenario 1: In the RS485 interrupt function, determine whether there is data that needs to be replied in real time. If there is data, the state machine is used to determine whether the timing of data reply has arrived. If the timing of data reply has not arrived, the RS485 data is processed in a normal loop until the timing of data reply arrives. The data is sent directly by triggering the send interrupt.

[0037] Scenario 2: In the RS485 interrupt function, determine whether there is data that needs to be replied in real time. If there is no data, determine whether it is necessary to reply to the default data. If not, continue to process the RS485 data in a normal loop.

[0038] Scenario 3: In the RS485 interrupt function, determine whether there is data that needs to be replied in real time. If there is no data, determine whether it is necessary to reply to the default data. If it is necessary to reply to the default data, determine whether the timing of data reply has arrived through the state machine. If the timing of data reply has not arrived, continue to process RS485 data in a normal loop until the timing of data reply arrives. By triggering the send interrupt, the default data is sent directly.

[0039] Figure 2 This paper describes the data processing flow of Linux applications. For applications, to read RS485 data, they can continue to read through normal channels; to write RS485 data, they need to write data to the underlying RS485 send buffer through a new node, shared memory, or other methods.

[0040] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A RS485 real-time communication method under Linux, characterized in that: The following steps are involved: S1. Write RS485 driver under Linux. The main task of the driver is to manage serial port devices, including configuring serial port parameters, processing data transmission, etc. S2. Use tools such as logic analyzer or oscilloscope, combined with RS485 communication protocol, to fully understand the timing requirements of RS485. Through the logic analyzer, you can see the sent data frame, including the start bit, data bit and end bit; S3. Provide an additional read-write interface at the RS485 driver layer for the application layer to read and write and cache data. For RS485 communication, the driver layer provides a read-write interface to the application layer to facilitate data interaction between the application layer and the RS485 device. The read-write interface needs to handle data caching to ensure data integrity and correct transmission; S4. Read and process the data received by RS485 in the RS485 driver, and send the cache data filled in by the application layer to achieve real-time communication. When reading and processing data, if the data is transmitted according to a certain protocol format, such as a frame format containing a start bit, data bit, check bit, and stop bit, it needs to be parsed. Depending on the protocol, it may contain check bits, such as parity check, CRC check, etc.

2. A RS485 real-time communication method under Linux according to claim 1, characterized in that: When debugging RS485 communication in S2, the signal waveform can be viewed through an oscilloscope, or the serial terminal tool can be used for data interaction. If communication abnormalities occur, check whether the line connection, baud rate setting, signal level conversion are correct, and whether the state control logic in the software is reasonable.

3. A RS485 real-time communication method under Linux according to claim 1, characterized in that: When writing cache data in S3, the application layer can put the data into the cache first, and the driver layer sends the data in the cache in a timely manner according to the communication status of RS485 (such as whether it is busy). When reading, the data received by the driver layer is first put into the cache, and the application layer can read the data from the cache at an appropriate time.

4. A RS485 real-time communication method under Linux according to claim 1, characterized in that: In addition to the simple first-in first-out (FIFO) cache strategy, other strategies can be adopted according to application requirements when caching data in S3. For example, if some data has a higher priority, these data can be processed first. Dynamic adjustment of the cache size can also be considered to optimize the cache performance according to the actual communication load.

5. A RS485 real-time communication method under Linux according to claim 1, characterized in that: The driver in S1 needs to follow the Linux device driver model, including defining the device number, registering the device, and implementing device operation functions (such as open, read, write, close, etc.). For example, in the driver's open function, the device initialization operation can be performed, such as configuring the serial port's baud rate, data bits, stop bits, check bits and other parameters; in the read function, the logic of reading data from the RS485 serial port is implemented; in the write function, the logic of writing data to the RS485 serial port is implemented; in the close function, operations such as releasing device resources are performed.

6. A RS485 real-time communication method under Linux according to claim 1, characterized in that: In S2, the baud rate of communication can be determined by the waveform. For example, if the time to send 1 bit is 34.795÷4=8.69875us, then the baud rate is approximately 115,200bit / s.

7. A RS485 real-time communication method under Linux according to claim 1, characterized in that: In S4, CRC check is taken as an example. If the sender adds a CRC check code at the end of the data, the receiver needs to recalculate the CRC check code and compare it with the received check code.

Images