Linux-based virtual serial port communication method, device, system and medium
By creating a virtual serial port driver in the Linux system kernel and establishing a mapping with the tty driver layer, the problem of multiple processes sharing a physical serial port under the Linux system was solved, enabling software packet capture and simulated data transmission, thus improving the efficiency of problem localization and troubleshooting.
Patent Information
- Application Number
- CN202210875459.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-07-25
- Publication Date
- 2026-01-02
- Estimated Expiration
- 2042-07-25
AI Technical Summary
In Linux systems, when multiple processes read serial port data simultaneously, only one process can receive the data. Packet capture and simulated data transmission cannot be achieved through software, and existing technologies require hardware solutions.
A virtual serial port driver is created in the Linux system kernel. The mapping relationship between the virtual serial port and the physical serial port is established through the virtual serial port driver and the tty driver layer, so that multiple processes can share the physical serial port. Packet capture and simulated data transmission are performed in software.
It enables multiple processes to share a physical serial port under the Linux system, and can capture packets and simulate data transmission through software to help locate and troubleshoot serial communication problems.
Smart Images

Figure CN115248798B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of Linux system technology, and in particular relates to Linux-based virtual serial communication methods, devices, systems and media. Background Technology
[0002] Because the serial port driver mechanism in Linux is single-process, only one process can receive data from the serial port at a time. When multiple processes simultaneously read data from the same serial port, only one process can receive the data. Therefore, when a serial communication system malfunctions, if packet capture (i.e., capturing serial communication messages) is needed to troubleshoot the problem, current technology only allows for hardware-based packet capture via external wiring to the serial port and using other devices. It is not possible to implement packet capture functionality in software within the existing Linux system. Summary of the Invention
[0003] In view of this, embodiments of this application provide a Linux-based virtual serial port communication method, device, system, and medium to solve the problem in the prior art that packet capture cannot be achieved through software under the Linux system.
[0004] The first aspect of this application provides a Linux-based virtual serial port communication method, including:
[0005] Create a virtual serial port driver in the Linux system kernel;
[0006] Determine the data transmission type of at least one virtual serial port;
[0007] Based on the virtual serial port driver and the tty driver layer of the Linux system kernel, establish at least one mapping relationship between a virtual serial port and a physical serial port;
[0008] Based on the data transmission type and the mapping relationship, at least one of the virtual serial ports performs data transmission and reception operations on the physical serial port.
[0009] This application embodiment creates a virtual serial port driver in the Linux system kernel. After determining the data transmission type of the virtual serial port, it maps and associates the virtual serial port with the physical serial port through the virtual serial port driver and the tty driver layer of the Linux system kernel, enabling at least one virtual serial port to send and receive data to and from the physical serial port. Under the single-process serial port driver mechanism of the Linux system, this application embodiment can not only enable multiple processes to share a single physical serial port and handle different services by different processes, but also use software to solve the problem of packet capture and simulate sending data to the internal serial port, which is beneficial for locating and troubleshooting problems in the Linux system.
[0010] In conjunction with the first aspect, in a first possible implementation of the first aspect, establishing at least one mapping relationship between a virtual serial port and a physical serial port based on the virtual serial port driver and the tty driver layer of the Linux system kernel includes:
[0011] Obtain the node of at least one virtual serial port provided by the virtual serial port driver, and the node of the physical serial port provided by the tty driver layer of the Linux system kernel;
[0012] Associate at least one node of the virtual serial port with a node of the physical serial port to establish at least one mapping relationship between the virtual serial port and the physical serial port.
[0013] The virtual serial port driver provides nodes for the virtual serial port, and the virtual serial port application can operate the virtual serial port through the nodes. The Linux system kernel's tty driver layer provides nodes for the physical serial port, and the serial port application can operate the physical serial port through the nodes. In this embodiment, the virtual serial port node provided by the virtual serial port driver is associated with the physical serial port node provided by the tty driver layer to establish a mapping relationship between the virtual serial port and the physical serial port. This enables the communication connection between the virtual serial port and the physical serial port, and realizes the data transmission and reception operation of the virtual serial port to the physical serial port.
[0014] In conjunction with the first aspect, in a second possible implementation of the first aspect, the step of performing at least one data transmission and reception operation between the virtual serial port and the physical serial port includes:
[0015] Associate the virtual serial port driver with the UART driver layer of the Linux system kernel;
[0016] Based on the associated virtual serial port driver and the UART driver layer of the Linux system kernel, at least one of the virtual serial ports receives or sends data to the physical serial port via the UART driver layer of the Linux system kernel.
[0017] The Linux system kernel includes a serial port driver framework, which comprises an upper-level tty driver layer and a lower-level uart driver layer. The tty driver layer provides nodes for serial port applications to access the physical serial port, while the uart driver layer interacts with the hardware device to enable the transmission of data from the physical serial port. This embodiment associates a virtual serial port driver with the Linux system kernel's uart driver layer, enabling the virtual serial port to send and receive data from the physical serial port. In other words, data received by the physical serial port can be forwarded to the virtual serial port through the uart driver layer, and data sent by the virtual serial port can be forwarded to the physical serial port or the serial port application through the uart driver layer.
[0018] In conjunction with the first aspect, in a third possible implementation of the first aspect, determining the data transmission type of at least one virtual serial port includes:
[0019] When at least one of the virtual serial ports receives data from the physical serial port, the data transmission type is determined to include the data transmission type of the physical serial port in the sending direction and / or receiving direction.
[0020] When at least one of the virtual serial ports sends data to the physical serial port, the data transmission type is determined to include the data transmission type of the sending direction and the receiving direction of the physical serial port.
[0021] The data transmission types of a virtual serial port include sending data or receiving data. When the data transmission type is sending data, the data transmission type can be either the sending direction of the physical serial port, or the receiving direction of the physical serial port, or a combination of both. When the data transmission type is receiving data, the data transmission type can be either the sending direction of the physical serial port or a combination of both.
[0022] A second aspect of this application provides a Linux-based virtual serial communication device, comprising:
[0023] Create a module to create a virtual serial port driver in the Linux system kernel;
[0024] The determination module is used to determine the data transmission type of at least one virtual serial port;
[0025] The mapping module is used to establish at least one mapping relationship between a virtual serial port and a physical serial port based on the virtual serial port driver and the tty driver layer of the Linux system kernel.
[0026] The transceiver module is used to perform at least one data transmission and reception operation between the virtual serial port and the physical serial port according to the data transmission type and the mapping relationship.
[0027] This application embodiment creates a virtual serial port driver in the Linux system kernel through a creation module, determines the data transmission type of the virtual serial port through a determination module, and uses the virtual serial port driver and the Linux system kernel's tty driver layer to map and associate the virtual serial port with the physical serial port. Through a transceiver module, at least one virtual serial port can send and receive data to and from the physical serial port. Under the single-process serial port driver mechanism of the Linux system, this application embodiment can not only enable multiple processes to share a single physical serial port, but also use software to solve the problem of packet capture and simulate sending data to the internal serial port, which is beneficial for locating and troubleshooting problems in the Linux system.
[0028] In conjunction with the second aspect, in a first possible implementation of the second aspect, the mapping module includes:
[0029] The acquisition unit is used to acquire at least one virtual serial port node provided by the virtual serial port driver, and the physical serial port node provided by the tty driver layer of the Linux system kernel.
[0030] An association unit is used to associate at least one node of the virtual serial port with a node of the physical serial port, and to establish a mapping relationship between at least one virtual serial port and the physical serial port.
[0031] In conjunction with the second aspect, in a second possible implementation of the second aspect, the step of performing at least one data transmission and reception operation between the virtual serial port and the physical serial port includes:
[0032] Associate the virtual serial port driver with the UART driver layer of the Linux system kernel;
[0033] Based on the associated virtual serial port driver and the UART driver layer of the Linux system kernel, at least one of the virtual serial ports receives or sends data to the physical serial port via the UART driver layer of the Linux system kernel.
[0034] In conjunction with the second aspect, in a third possible implementation of the second aspect, determining the data transmission type of at least one virtual serial port includes:
[0035] When at least one of the virtual serial ports receives data from the physical serial port, the data transmission type is determined to include the data transmission type of the physical serial port in the sending direction and / or receiving direction.
[0036] When at least one of the virtual serial ports sends data to the physical serial port, the data transmission type is determined to include the data transmission type of the sending direction and the receiving direction of the physical serial port.
[0037] A third aspect of this application provides a communication system including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any of the first aspects.
[0038] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method as described in any of the first aspects.
[0039] The beneficial effects of this application embodiment compared with the prior art are as follows: This application embodiment creates a virtual serial port driver in the Linux system kernel, and maps and associates the virtual serial port and the physical serial port through the virtual serial port driver and the tty driver layer of the Linux system kernel, so as to realize the data transmission and reception of at least one virtual serial port to the physical serial port. Under the existing single-process serial port driver mechanism of the Linux system, this application embodiment can not only realize the use of multiple processes to share a physical serial port through the virtual serial port, but also solve the problem of packet capture and simulate sending data to the internal serial port in the Linux system in a software manner, which is beneficial to the location and troubleshooting of problems when the Linux system occurs. Attached Figure Description
[0040] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0041] Figure 1 This is a schematic diagram illustrating the implementation process of a Linux-based virtual serial port communication method provided in an embodiment of this application;
[0042] Figure 2 This is a schematic diagram of the Linux system architecture provided in the embodiments of this application;
[0043] Figure 3 This is a schematic diagram of virtual serial port packet capture provided in an embodiment of this application;
[0044] Figure 4 This is a schematic diagram of virtual serial port packet sending provided in an embodiment of this application;
[0045] Figure 5 This is a schematic diagram of a Linux-based virtual serial communication device provided in an embodiment of this application;
[0046] Figure 6 This is a schematic diagram of a communication system provided in an embodiment of this application. Detailed Implementation
[0047] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0048] To illustrate the technical solution described in this application, specific embodiments are provided below.
[0049] It is understood that those skilled in the art are familiar with the technical terms mentioned in the embodiments of this application. To better understand the embodiments of this application, a simple explanation of the technical terms mentioned in the embodiments of this application is provided here. Among them, Linux system is a clone system of the UNIX operating system. It is a multi-user, multi-tasking operating system based on POSIX and UNIX, supporting multi-threading and multi-CPU. It can run major UNIX utilities, applications, and network protocols. A serial port, also known as a serial communication interface, transmits data bit by bit. It is low-cost and can achieve long-distance transmission. The serial port refers to the physical serial port mentioned in the embodiments of this application; it is a real serial port that can connect to external devices. A virtual serial port is a virtual serial port simulated by running third-party software. For serial port applications, the virtual serial port can be operated as if it were a real physical serial port. tty (teletypes) is an abbreviation for various types of terminal devices. A tty is a terminal device used for user interaction, inputting data to and receiving data from the computer system. For the Linux system, all serial port devices are tty devices, and tty devices have other specific forms besides serial port devices.
[0050] Because the serial port driver mechanism in Linux systems operates on a single-process basis, when a serial port application interacts with a hardware device through the serial port driver framework, if multiple processes simultaneously read data from a single serial port, only one process can receive the data; the others cannot. Furthermore, due to this single-process limitation, packet capture cannot be implemented in software within the existing Linux system when the serial communication system malfunctions. Current technology necessitates connecting external wires to the serial port and using other devices for packet capture; sending data directly to the serial port via software is impossible.
[0051] To address the problems existing in the prior art, this application proposes a Linux-based virtual serial port communication method, device, system, and medium. By injecting a virtual serial port driver into the Linux system kernel, a virtual serial port driver is created. The virtual serial port and the physical serial port are mapped and associated through the virtual serial port driver and the tty driver layer of the Linux system kernel, enabling at least one virtual serial port to send and receive data to and from the physical serial port. This not only allows multiple processes to share a single physical serial port through the virtual serial port, but also enables the use of software within the Linux system to solve packet capture issues and simulate sending data to the internal serial port. This is beneficial for locating and troubleshooting problems when the Linux system malfunctions.
[0052] like Figure 1 As shown, the first aspect of this application provides a virtual serial port communication method based on Linux, including the following steps:
[0053] S101. Create a virtual serial port driver in the Linux system kernel;
[0054] In this embodiment, the Linux system kernel includes a serial port driver framework, which can be divided into three layers: a character device layer, a tty driver layer, and a UART driver layer. The character device layer directly interacts with the serial port application, with the tty driver layer acting as an abstraction layer, decoupling the underlying implementation. Finally, the underlying UART driver layer is responsible for the interaction between data and hardware devices, as well as a series of management operations. Specifically, the UART driver layer communicates with the physical serial port, sending and receiving data from the hardware device. It is understood that the specific content of the Linux system kernel's serial port driver framework is well-known to those skilled in the art. This embodiment does not elaborate on the entire serial port driver framework but only describes it in conjunction with the technical solutions of this embodiment.
[0055] In step S101, a virtual serial port driver is created in the Linux system kernel. The virtual serial port driver provides a virtual serial port node for the virtual serial port. The virtual serial port application manages and operates the virtual serial port through the virtual serial port node. In the serial port driver framework of the Linux system kernel, the tty driver layer provides a physical serial port node for the physical serial port. The serial port application manages and operates the physical serial port through the physical serial port node. Process operation with hardware devices is realized through the serial port driver framework.
[0056] S102. Determine the data transmission type of at least one virtual serial port;
[0057] As a preferred embodiment of this application, step S102 specifically includes the following steps:
[0058] When at least one of the virtual serial ports receives data from the physical serial port, the data transmission type is determined to include the data transmission type of the physical serial port in the sending direction and / or receiving direction.
[0059] When at least one of the virtual serial ports sends data to the physical serial port, the data transmission type is determined to include the data transmission type of the sending direction and the receiving direction of the physical serial port.
[0060] In step S102, the data transmission type of the virtual serial port includes receiving data or sending data, that is, receiving data or sending data at the physical serial port. In the process of the serial port application interacting with the physical serial port, the virtual serial port specifically receives data in the sending direction TX, or the receiving direction RX, or simultaneously in the sending direction TX and the receiving direction RX of the physical serial port; it simulates the physical serial port sending data to the serial port application in the sending direction TX of the physical serial port, or it simulates the serial port application sending data to the physical serial port in the receiving direction RX of the physical serial port.
[0061] S103. Based on the virtual serial port driver and the tty driver layer of the Linux system kernel, establish at least one mapping relationship between a virtual serial port and a physical serial port.
[0062] As a preferred embodiment of this application, step S103 specifically includes the following steps:
[0063] S1031. Obtain at least one virtual serial port node provided by the virtual serial port driver, and the physical serial port node provided by the tty driver layer of the Linux system kernel.
[0064] S1032. Associate at least one node of the virtual serial port with the node of the physical serial port to establish at least one mapping relationship between the virtual serial port and the physical serial port.
[0065] In step S103, as Figure 2 As shown, the virtual serial port driver created in step S101 is associated with the tty driver layer in the Linux system kernel serial port driver framework. Specifically, the virtual serial port node provided by the virtual serial port driver is associated with the physical serial port node provided by the tty driver layer, establishing a mapping relationship between the virtual serial port and the physical serial port. This allows the virtual serial port to send and receive data at the physical serial port through the mapping relationship. Furthermore, associating the virtual serial port driver with the tty driver layer not only establishes a mapping relationship between the virtual serial port and the physical serial port, but also enables the virtual serial port to have the functions of a regular physical serial port with the help of the tty driver layer.
[0066] S104. Based on the data transmission type and the mapping relationship, perform at least one data transmission and reception operation between the virtual serial port and the physical serial port.
[0067] As a preferred embodiment of this application, step S104 specifically includes the following steps:
[0068] S1041. Associate the virtual serial port driver with the UART driver layer of the Linux system kernel;
[0069] S1042. Based on the associated virtual serial port driver and the UART driver layer of the Linux system kernel, execute at least one of the virtual serial ports to receive or send data to the physical serial port via the UART driver layer of the Linux system kernel.
[0070] In step S104, besides the data transmission type of the virtual serial port determined in step S102 and the mapping relationship between the virtual serial port and the physical serial port established in step S103, such as... Figure 2 As shown, the virtual serial port driver is also associated with the UART driver layer in the Linux system kernel serial port driver framework. The UART driver layer, as the underlying layer, communicates with the physical serial port, receiving and sending data from the physical serial port. By associating with the UART driver layer, the virtual serial port driver establishes a data flow channel between the virtual serial port and the physical serial port, enabling the virtual serial port to send and receive data to the physical serial port.
[0071] Through the above-described Linux-based virtual serial port communication method, the embodiments of this application can overcome the single-process operation defects of the Linux system by associating the virtual serial port driver with the serial port driver framework under the existing Linux system kernel serial port driver framework. This enables multiple processes to share a physical serial port, allowing different services to be handled by different processes. It also enables serial port packet capture and simulated data transmission when the serial port communication system malfunctions, which is beneficial for locating and troubleshooting problems.
[0072] In this regard, the embodiments of this application combine the process of serial port packet capture and simulated data transmission to illustrate the above-mentioned Linux-based virtual serial port communication method.
[0073] First, the specific process by which a serial port application interacts with a physical serial port in a Linux system involves the serial port application sending and receiving data to and from the physical serial port through the tty driver layer and the UART driver layer, respectively, when the physical serial port node is open. It can be understood that the data from the physical serial port originates from the terminal hardware device. The entire process of packet capture from the virtual serial port to the physical serial port in a Linux system is as follows:
[0074] like Figure 3As shown, the virtual serial port application opens the virtual serial port node provided by the virtual serial port driver. To capture packets from the virtual serial port to the physical serial port, the data transmission type of the virtual serial port is determined to be receiving data. The virtual serial port needs to capture data sent from the serial port application to the physical serial port and data sent from the physical serial port to the serial port application. Therefore, the transmission directions of the virtual serial port are the receiving direction (RX) and the sending direction (TX) of the physical serial port. Then, the virtual serial port driver is associated with the tty driver layer to establish a mapping relationship between the virtual serial port and the physical serial port, and the virtual serial port driver is associated with the UART driver layer. Finally, based on the established mapping relationship, the virtual serial port, through the UART driver layer, captures communication packets sent from the serial port application to the physical serial port in the receiving direction (RX) and from the physical serial port to the serial port application in the sending direction (TX), and displays the captured data. By analyzing the communication packets, the problems of the serial communication system can be identified.
[0075] In a Linux system, the entire process of a virtual serial port simulating packet transmission to a physical serial port is as follows:
[0076] like Figure 4 As shown, the virtual serial port application opens the virtual serial port node provided by the virtual serial port driver. To enable the virtual serial port to simulate the application sending data to the physical serial port, or to simulate the physical serial port sending data to the application, the data transmission type of the virtual serial port is determined to be "transmit data," and the transmission direction of the virtual serial port is either the receiving direction (RX) or the sending direction (TX) of the physical serial port. Then, the virtual serial port driver is associated with the tty driver layer to establish a mapping relationship between the virtual and physical serial ports, and the virtual serial port driver is also associated with the UART driver layer. Finally, based on the established mapping relationship, the virtual serial port, through the UART driver layer, simulates the application sending data to the physical serial port via the receiving direction (RX) or the physical serial port sending data to the application via the sending direction (TX).
[0077] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0078] like Figure 5 As shown, a second aspect of this application also provides a Linux-based virtual serial communication device, comprising:
[0079] Create module 501 to create a virtual serial port driver in the Linux system kernel;
[0080] The determination module 502 is used to determine the data transmission type of at least one virtual serial port;
[0081] In a preferred embodiment of this application, the determining module 502 specifically includes:
[0082] When at least one of the virtual serial ports receives data from the physical serial port, the data transmission type is determined to include the data transmission type of the physical serial port in the sending direction and / or receiving direction.
[0083] When at least one of the virtual serial ports sends data to the physical serial port, the data transmission type is determined to include the data transmission type of the sending direction and the receiving direction of the physical serial port.
[0084] The mapping module 503 is used to establish at least one mapping relationship between a virtual serial port and a physical serial port based on the virtual serial port driver and the tty driver layer of the Linux system kernel.
[0085] In a preferred embodiment of this application, the mapping module 503 specifically includes:
[0086] The acquisition unit is used to acquire at least one virtual serial port node provided by the virtual serial port driver, and the physical serial port node provided by the tty driver layer of the Linux system kernel.
[0087] An association unit is used to associate at least one node of the virtual serial port with a node of the physical serial port, and to establish a mapping relationship between at least one virtual serial port and the physical serial port.
[0088] The transceiver module 504 is used to perform at least one data transmission and reception operation between the virtual serial port and the physical serial port according to the data transmission type and the mapping relationship.
[0089] In a preferred embodiment of this application, the transceiver module 504 specifically includes:
[0090] Associate the virtual serial port driver with the UART driver layer of the Linux system kernel;
[0091] Based on the associated virtual serial port driver and the UART driver layer of the Linux system kernel, at least one of the virtual serial ports receives or sends data to the physical serial port via the UART driver layer of the Linux system kernel.
[0092] This application provides a Linux-based virtual serial communication device, which is a modular device corresponding to the Linux-based virtual serial communication method described in the above embodiments. Its principle and implementation process are the same as those in the above embodiments. For details, please refer to the description of the method, which will not be elaborated here.
[0093] like Figure 6 As shown, a third aspect of this application also provides a communication system, including a memory 61, a processor 60, and a computer program 62 stored in the memory 61 and executable on the processor 60. When the processor 60 executes the computer program 62, it implements the steps of the method as described in any of the first aspects. Alternatively, when the processor 60 executes the computer program 62, it implements the functions of each module / unit in the above-described device embodiments.
[0094] A fourth aspect of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method as described in any of the first aspects.
[0095] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0096] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0097] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0098] In the embodiments provided in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0099] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0100] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0101] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by hardware related to computer program instructions. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.
[0102] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A Linux-based virtual serial port communication method, characterized in that, The method comprises the following steps: creating a virtual serial port driver in a Linux system kernel; determining a data transmission type of at least one virtual serial port; establishing a mapping relationship between the at least one virtual serial port and a physical serial port according to the virtual serial port driver and a tty driver layer of the Linux system kernel; performing data transmission and reception operations of the at least one virtual serial port on the physical serial port according to the data transmission type and the mapping relationship; the step of establishing the mapping relationship between the at least one virtual serial port and the physical serial port according to the virtual serial port driver and the tty driver layer of the Linux system kernel comprises the following steps: obtaining nodes of the at least one virtual serial port provided by the virtual serial port driver and nodes of the physical serial port provided by the tty driver layer of the Linux system kernel; associating the nodes of the at least one virtual serial port with the nodes of the physical serial port to establish the mapping relationship between the at least one virtual serial port and the physical serial port.
2. The Linux-based virtual serial port communication method of claim 1, wherein, the step of performing the data transmission and reception operations of the at least one virtual serial port on the physical serial port comprises the following steps: associating the virtual serial port driver with a uart driver layer of the Linux system kernel; performing data reception or transmission of the at least one virtual serial port on the physical serial port through the uart driver layer of the Linux system kernel according to the associated virtual serial port driver and the uart driver layer of the Linux system kernel.
3. The Linux-based virtual serial port communication method of claim 1, wherein, the step of determining the data transmission type of the at least one virtual serial port comprises the following steps: when performing data reception of the at least one virtual serial port on the physical serial port, determining the data transmission type to include a data transmission type of a transmission direction and / or a reception direction of the physical serial port; when performing data transmission of the at least one virtual serial port on the physical serial port, determining the data transmission type to include a data transmission type of a transmission direction and a reception direction of the physical serial port.
4. A Linux-based virtual serial port communication device, comprising: The method comprises the following steps: creating a virtual serial port driver in a Linux system kernel; determining a data transmission type of at least one virtual serial port; establishing a mapping relationship between the at least one virtual serial port and a physical serial port according to the virtual serial port driver and a tty driver layer of the Linux system kernel; performing data transmission and reception operations of the at least one virtual serial port on the physical serial port according to the data transmission type and the mapping relationship; the mapping module comprises: an obtaining unit, configured to obtain nodes of the at least one virtual serial port provided by the virtual serial port driver and nodes of the physical serial port provided by the tty driver layer of the Linux system kernel; an associating unit, configured to associate the nodes of the at least one virtual serial port with the nodes of the physical serial port to establish the mapping relationship between the at least one virtual serial port and the physical serial port.
5. The Linux-based virtual serial port communication device of claim 4, wherein, the step of performing the data transmission and reception operations of the at least one virtual serial port on the physical serial port comprises the following steps: associating the virtual serial port driver with a uart driver layer of the Linux system kernel; performing data reception or transmission of the at least one virtual serial port on the physical serial port through the uart driver layer of the Linux system kernel according to the associated virtual serial port driver and the uart driver layer of the Linux system kernel. According to the associated virtual serial port driver and the Linux system kernel's uart driver layer, at least one of the virtual serial ports receives or transmits data to the physical serial port through the Linux system kernel's uart driver layer.
6. The Linux-based virtual serial port communication device of claim 4, wherein, The determination of the data transmission type of at least one virtual serial port comprises: When at least one of the virtual serial ports receives data from the physical serial port, the determination of the data transmission type comprises the data transmission type of the transmitting direction and / or the receiving direction of the physical serial port; When at least one of the virtual serial ports transmits data to the physical serial port, the determination of the data transmission type comprises the data transmission type of the transmitting direction and the receiving direction of the physical serial port.
7. A communication system comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 3.
8. A computer-readable storage medium storing a computer program, the computer-readable storage medium comprising: The computer program is executed by the processor to implement the steps of the method according to any one of claims 1 to 3.
Citation Information
Patent Citations
Method for realizing serial port virtualization based on linux ty subsystem
CN112416521A