Serial port multiplexing and transceiving implementation method, device, equipment and program product
By creating multiple virtual tty devices for a single physical serial port in the serial port driver layer and using work queue scheduling functions, the problems of low efficiency and resource waste in traditional serial port drivers are solved, and efficient multi-channel serial communication is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- KYLIN CORP
- Filing Date
- 2026-01-06
- Publication Date
- 2026-04-17
AI Technical Summary
Traditional serial port drivers can only achieve one-to-one mapping. When multiple applications share the same serial port, the efficiency is low and conflicts are prone to occur. Furthermore, system calls in the data transfer layer increase resource waste and latency.
Multiple virtual tty devices are created for a single physical serial port in the serial port driver layer, and direct data transmission is achieved through the work queue scheduling function, eliminating the data relay layer and reducing system calls.
It enables efficient communication for multiple applications to access a single physical serial port simultaneously, reducing system calls and latency, and improving resource utilization.
Smart Images

Figure CN121478699B_ABST
Abstract
Description
Technical Field
[0001] This invention pertains to communication technology, specifically relating to methods, apparatus, devices, and software products for implementing serial port multiplexer. Background Technology
[0002] Traditional serial port drivers can only achieve a one-to-one mapping, that is, one physical port corresponds to one software port. Multiple applications can only share the same serial port by using polling or serial port multiplexers, which is inefficient and prone to conflicts.
[0003] Virtual serial ports simulate all the characteristics of a real UART (baud rate, data bits, parity, flow control) by creating a tty device at the operating system kernel level, enabling systems without actual hardware to run legacy software that relies on serial ports.
[0004] In environments such as industrial automation, PLC remote debugging, and testing platforms, it is often necessary for multiple independent upper-level programs (such as debugging tools, monitoring software, and log collectors) to simultaneously read data from the same serial port.
[0005] To avoid hardware expansion and complex serial port multiplexing circuits, the industry has adopted a "one-to-many" virtual serial port mapping scheme: splitting a real serial port into several virtual serial ports, with each virtual port directly mapped to the real serial port, so that all programs can obtain the same data stream in real time.
[0006] Figure 1 and Figure 2 This is a data flow diagram for traditional serial port multiplexed read and multiplexed write in existing technologies. In existing technologies, serial port multiplexed transmit and receive technologies achieve multiplexing through application relay.
[0007] like Figure 1 As shown, in existing serial port multiplexing technology, the data receiving process is as follows:
[0008] The serial port driver reads data from the physical serial port;
[0009] The tty device receives data from the serial port driver;
[0010] The data relay layer reads serial port data from the tty device;
[0011] The data relay layer sequentially writes the serial port data it reads into the virtual tty device;
[0012] Multiple applications read serial port data from different virtual tty devices.
[0013] like Figure 2 As shown, in existing serial port multiplexing technology, the data transmission process is as follows:
[0014] Multiple applications write data to different virtual tty devices;
[0015] The data transfer layer reads the written data sequentially and processes it according to time.
[0016] The data transfer layer writes the sorted data sequentially to the tty device;
[0017] The tty device sends the written data to the serial port driver, and the serial port driver sends the data to the physical serial port.
[0018] In summary, the existence of the data transfer layer requires additional system calls, which not only wastes resources but also increases latency. Furthermore, the number of system calls increases linearly with the number of applications, such as... Figure 1 Two applications read, and the system calls for read and write operations total 5 times. The general formula is a. n =2n+1. Summary of the Invention
[0019] To address the shortcomings of existing technologies, this invention provides a serial port multiplexing implementation method, comprising the following steps:
[0020] Step S1: Add the parm parameter virt_num to the serial port driver to specify the number of virtual tty devices when the serial port driver is loaded;
[0021] Step S2: Add struct uart_port virt_ports and virtual tty device phy_port to the uart_amba_port structure;
[0022] Step S3: Create virt_num virtual tty devices during serial port initialization;
[0023] Step S4: Save the list of virtual devices corresponding to the created virt_num virtual tty devices into the struct uart_port virt_ports added in step S2, so that the serial port driver can access all virtual tty devices for receiving data;
[0024] Step S5: Save the serial port driver to the virtual tty device phy_port added in step S2, so that the virtual tty device can access the serial port driver for sending data.
[0025] In step S3, virt_num virtual tty devices are created through the uart_add_one_port interface.
[0026] This also includes step S6: creating a send work queue scheduling function and a receive work queue scheduling function in the serial port driver to send and receive data in sequence.
[0027] In step S6, a send work queue scheduling function and a receive work queue scheduling function are created using INIT_WORK.
[0028] The method for receiving data using a virtual tty device includes the following steps:
[0029] Step Sa: Modify the serial port driver's receive processing function to put the data read from the physical serial port into the receive work queue;
[0030] Step Sb: The receive work queue scheduling function schedules the receive work queue, iterates through all virtual tty devices according to virt_num, and transmits the data read from the physical serial port to the virtual tty devices in sequence;
[0031] Step Sc: When receiving an interrupt report, check the LSR register and synchronize the error information to the proc file system in all virtual tty devices;
[0032] Step Sd: Release the received data from the receive work queue.
[0033] In step Sb, the receiving work queue transmits the data read from the physical serial port to the virtual tty device sequentially through the uart_insert_char interface.
[0034] The method for sending data using a virtual tty device includes the following steps:
[0035] Step S1: When the virtual tty device sends data, the data is placed into the sending work queue.
[0036] Step Sm: The send work queue scheduling function schedules and executes the send work queue, retrieves data from the send work queue in sequence, and calls the serial port driver send interface to send the data to the physical serial port;
[0037] Step Sn: When sending an interrupt report, check the LSR register and synchronize the error information to uart_icount.
[0038] The present invention further provides a serial port multiplexing device for implementing any of the above-described serial port multiplexing methods.
[0039] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.
[0040] The present invention further provides a computer program product, comprising a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps of the method described in any of the above-mentioned embodiments.
[0041] This invention creates multiple transmit and receive channels for a single physical serial port in the serial port driver layer, enabling multiple applications to access the transmit and receive data of a single physical serial port simultaneously, thereby realizing the function of "one-to-many" serial communication. Attached Figure Description
[0042] Figure 1 This is a data flow diagram for traditional serial port multi-channel reads using existing technologies.
[0043] Figure 2 A data flow diagram for traditional serial port multiplexing of existing technologies.
[0044] Figure 3 This is a flowchart illustrating the data reception implementation of the virtual tty device of the present invention.
[0045] Figure 4 This is a flowchart illustrating the data transmission implementation of the virtual tty device of the present invention. Detailed Implementation
[0046] To gain a better understanding of the technical solution and beneficial effects of the present invention, the technical solution of the present invention and its beneficial effects are described in detail below with reference to the accompanying drawings.
[0047] In this invention, the terminology used and its interpretation are as follows:
[0048] LSR: Line Status Register Bit Definitions, which contains the sending and receiving status, as well as data overflow errors, parity errors, frame errors, etc.
[0049] uart_icount: struct uart_icount is an important data structure in the UART subsystem of the Linux kernel, used to count the number of events and errors that occur during the operation of the UART port.
[0050] Traditional serial port multiplexing generates additional system calls, leading to resource waste and increased latency. Therefore, the solution of this invention is to eliminate the data relay layer; when the physical serial port driver receives data, it directly writes the data sequentially to the virtual tty serial port. For example... Figure 3 and Figure 4 As shown, the number of system calls is n.
[0051] This invention modifies the original serial port driver framework to achieve the above-mentioned effect. The modification steps are as follows:
[0052] Step 1: Add the parm parameter virt_num to the serial port driver. This parameter specifies the number of virtual tty devices when the serial port driver is loaded. When virt_num is 0, no virtual tty devices are created.
[0053] Step 2: Add struct uart_port virt_ports[MAX_VIRT_NUM] and virtual tty device phy_port to the serial port uart_amba_port structure (taking Phytium pl010 driver as an example).
[0054] Step 3: During serial port initialization, the uart_add_one_port interface is used to create virt_num virtual tty devices for access by upper-layer applications.
[0055] Step 4: Save the list of virtual tty devices to struct uart_port virt_ports, so that the serial port driver can access all virtual tty devices for receiving data.
[0056] Step 5: Save the serial port driver to the virtual tty device phy_port so that the virtual tty device can access the serial port driver for sending data.
[0057] Step 6: Use INIT_WORK to create send and receive work queue scheduling functions in the serial port driver for sending and receiving.
[0058] Please combine Figure 3 As shown, in this invention, the virtual tty device receives data in the following way:
[0059] Step 7: Modify the serial port driver's receive processing function to put the data read from the physical serial port into the receive work queue.
[0060] Step 8: The receive work queue scheduling function schedules the receive work queue, iterates through all virtual tty devices according to virt_num, and transmits the data to the virtual tty devices sequentially through the uart_insert_char interface for different applications to read.
[0061] Step 9: When receiving an interrupt report, check the LSR register and synchronize the error information to the proc file system in all virtual tty devices, for example: cat / proc / tty / driver / virt_1_ttyAMA.
[0062] Step 10: Release the received data from the receive queue.
[0063] Please combine Figure 4As shown, in this invention, the virtual tty device sends data in the following way:
[0064] Step 11: When the virtual tty device sends data, it will put the data read from different applications into the serial port transmission queue.
[0065] Step 12: The send work queue scheduling function schedules and executes the send work queue, retrieves data from the send work queue in sequence, and calls the serial port driver send interface to send the data to the physical serial port.
[0066] Step 13: When sending an interrupt report, check the LSR register and synchronize the error information to uart_icount.
[0067] Step 14: Release the data that has been sent from the send queue.
[0068] This invention can reduce system calls and latency. This invention is independent of CPU architecture, and the overall implementation is the same across different Linux kernel versions.
[0069] Although the present invention has been described using the above preferred embodiments, it is not intended to limit the scope of protection of the present invention. Any changes and modifications made by those skilled in the art to the above embodiments without departing from the spirit and scope of the present invention shall still fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be defined by the claims.
Claims
1. A method for implementing serial multi-transceiving, characterized in that, Includes the following steps: Step S1: Add the parm parameter virt_num to the serial port driver to specify the number of virtual tty devices when the serial port driver is loaded; Step S2: Add struct uart_port virt_ports and virtual tty device phy_port to the uart_amba_port structure; Step S3: Create virt_num virtual tty devices during serial port initialization; Step S4: Save the list of virtual devices corresponding to the created virt_num virtual tty devices into the struct uart_port virt_ports added in step S2, so that the serial port driver can access all virtual tty devices for receiving data; Step S5: Save the serial port driver to the virtual tty device phy_port added in step S2, so that the virtual tty device can access the serial port driver for sending data.
2. The serial port multiplexing method as described in claim 1, characterized in that: In step S3, virt_num virtual tty devices are created through the uart_add_one_port interface.
3. The serial port multiplexing implementation method as described in claim 1, characterized in that, It also includes step S6: creating a send work queue scheduling function and a receive work queue scheduling function in the serial port driver for sending and receiving data in sequence.
4. The serial port multiplexing method as described in claim 3, characterized in that: In step S6, the send work queue scheduling function and the receive work queue scheduling function are created using INIT_WORK.
5. The serial port multiplexing implementation method as described in claim 3, characterized in that, The process of receiving data using a virtual tty device includes the following steps: Step Sa: Modify the serial port driver's receive processing function to put the data read from the physical serial port into the receive work queue; Step Sb: The receive work queue scheduling function schedules the receive work queue, iterates through all virtual tty devices according to virt_num, and transmits the data read from the physical serial port to the virtual tty devices in sequence; Step Sc: When receiving an interrupt report, check the LSR register and synchronize the error information to the proc file system in all virtual tty devices; Step Sd: Release the received data from the receive work queue.
6. The serial port multiplexing method as described in claim 5, characterized in that: In step Sb, the receiving work queue transmits the data read from the physical serial port to the virtual tty device sequentially through the uart_insert_char interface.
7. The serial port multiplexing method as described in claim 3, characterized in that, The process of sending data using a virtual tty device includes the following steps: Step S1: When the virtual tty device sends data, the data is placed into the sending work queue. Step Sm: The send work queue scheduling function schedules and executes the send work queue, retrieves data from the send work queue in sequence, and calls the serial port driver send interface to send the data to the physical serial port; Step Sn: When sending an interrupt report, check the LSR register and synchronize the error information to uart_icount.
8. A serial port multi-channel transceiver device, characterized in that: Used to implement the serial port multiplexing and receiving method as described in any one of claims 1-7.
9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1-7.
10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1-7.
Citation Information
Patent Citations
Method for conducting multiplexing on debugging serial port in Linux system
CN104008008A
Method for realizing serial port virtualization based on linux ty subsystem
CN112416521A