Design method of UART-based multi-serial-port parallel transmission ring bus
By using a UART multi-serial port parallel transmission ring bus design, the problems of high hardware cost, poor scalability, and poor reliability in multi-device communication are solved, achieving plug-and-play, dynamic reconfiguration, and efficient communication, thereby improving the system's reliability and adaptability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JINAN QIANSHI ELECTRONIC TECHNOLOGY CO LTD
- Filing Date
- 2026-03-04
- Publication Date
- 2026-06-05
AI Technical Summary
Existing serial communication buses suffer from high hardware costs, poor scalability, low communication efficiency, poor reliability, and complex deployment and maintenance in multi-device scenarios, especially in star topologies and RS-485 buses.
A UART-based multi-serial port parallel transmission ring bus design method is adopted. By constructing a closed-loop hardware topology and insertion detection IO, combined with an automatic initialization software process, plug-and-play and dynamic reconfiguration are achieved. The host and slave UART serial ports are connected in sequence to form a ring. The insertion detection IO works in coordination with adjacent nodes. The host automatically parses the slave information and configures the address. A high-speed parallel transmission is achieved by using an information relay mechanism.
It achieves low-cost, high-reliability, and efficient multi-device communication, supports hot-swapping and dynamic expansion, improves the system's adaptability and maintainability in dynamic networking scenarios, has single-point fault self-healing capability, and maintains the simplicity and low-cost advantages of UART.
Smart Images
Figure CN122160250A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of serial communication technology, specifically to a design method for a multi-serial-port parallel transmission ring bus based on UART. Background Technology
[0002] Serial communication technology, especially serial communication based on Universal Asynchronous Receiver / Transmitter (UART), is widely used in resource-constrained scenarios such as industrial control and the Internet of Things due to its simple interface and low cost.
[0003] However, existing traditional serial buses for multi-device communication are mostly star or master-slave structures, which have significant limitations: While the common star topology is simple in structure, it requires the master to provide an independent hardware channel for each slave, causing the system hardware cost to increase linearly with the number of slaves, resulting in poor scalability. Although the RS-485 bus uses a shared bus to reduce connection complexity, its linear topology requires interrupting bus operation when expanding devices, does not support convenient hot-swapping, and the failure of any node on the bus can easily paralyze the entire network, leading to poor reliability. Furthermore, its communication mechanism often relies on master polling, and communication latency increases significantly with the number of slaves, resulting in low efficiency. Slave addresses often need to be manually configured, making deployment and maintenance cumbersome and prone to errors. In addition, if performance improvements are required using technologies such as CAN bus, it relies on dedicated controllers, resulting in high hardware costs, while some ring buses (such as PROFIBUS-DP) pose a risk of a single point of failure causing a complete network outage.
[0004] Therefore, there is an urgent need in this field for a multi-device communication solution that can maintain the simplicity and low cost advantages of serial communication while also possessing good scalability, high communication efficiency, and high reliability. Summary of the Invention
[0005] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a UART-based multi-serial port parallel transmission ring bus design method. This method achieves plug-and-play and dynamic reconfiguration of the bus by constructing a closed-loop hardware topology and combining insertion detection I / O with automatic initialization software processes. At the hardware level, the UART serial ports of the host and each slave are sequentially connected to form a ring. Each slave only needs to communicate with its adjacent node. When adding a new slave, it can be inserted into any position in the ring. Its insertion detection I / O pin works in conjunction with the insertion indication I / O pin of the adjacent node, allowing the physical layer to sense state changes. At the software level, the host broadcasts specific instructions when initializing or detecting changes. The slaves on the ring use an information relay mechanism to append their own device information sequentially to the instruction frame, which is then summarized and sent to the host. The host automatically parses the number, type, and status of all online slaves, dynamically constructs and updates the slave information table, and completes automatic address allocation. This mechanism fundamentally solves the deployment problems of traditional bus expansion requiring network interruption and manual configuration of slave addresses, achieving hot-swapping and plug-and-play functionality, and improving the system's adaptability and maintainability in dynamic networking scenarios.
[0006] To solve the above-mentioned technical problems, this invention provides the following technical solution: a design method for a multi-serial port parallel transmission ring bus based on UART, the specific steps of which are as follows: S100. Connect at least one slave device to a master device sequentially via a UART serial port to form a closed-loop communication link. The transmitting end of the master device is connected to the receiving end of the first slave device, the transmitting end of subsequent slave devices is connected to the receiving end of the next slave device, and the transmitting end of the last slave device is connected back to the receiving end of the master device. S200. After the system is powered on and reset, the host broadcasts an initialization command through the sending end. Each slave device on the closed-loop communication link receives the initialization command in sequence, and forwards it to the next node after attaching its own device information to the initialization command frame. The device information of all slave devices is summarized to the host through the closed-loop communication link. The host constructs and stores a complete slave device information table based on the summarized information. S300. The host sends a command frame containing the target slave address to a designated slave. The command frame is forwarded level by level on the loop. Each slave that receives the command frame parses the target address in the command frame. When the target address does not match its own address, the command frame is forwarded directly to the next slave. When they match, the target slave executes the command frame and organizes the response data into a reply frame, which is then returned to the host along the loop. S400. The host periodically sends a broadcast trigger frame. After receiving the broadcast trigger frame, the slave device packages the data to be reported and its own address into a reporting frame and forwards it to the next slave device. The reporting frame is forwarded level by level in the loop. Each time it passes through a slave device, the slave device appends its own data to be reported and its address to the reporting frame and continues to forward it. The complete reporting frame carrying all the slave device data to be reported is returned to the host. S500: When the system transmits high-speed data, at least one slave device is configured with a multi-channel serial port for transmitting data in parallel through the multi-channel serial port. The master device can receive and process all the data transmitted in parallel through a single receiving serial port.
[0007] Furthermore, the host is configured with at least one main communication serial port and an insertion detection I / O pin; The main communication serial port includes a transmitting end TX and a receiving end RX, which are used for the main communication of the ring bus. The insertion detection IO pin is used to detect whether a new slave device is inserted or an existing slave device is removed on the ring bus.
[0008] Furthermore, the slave device is configured with at least one master communication serial port, an insertion detection I / O pin, and an insertion indication I / O pin; The main communication serial port includes a transmitter (TX) and a receiver (RX) for communicating with adjacent slave nodes. The insertion detection IO pin is used to detect whether it is correctly connected to the loop; The insertion indication IO pin is used to report its insertion status to the adjacent superior slave node.
[0009] Furthermore, in S200, the initialization command broadcast by the host is an idle channel evaluation command. The first slave to receive the initialization command appends its preset self-device information as data payload to the initialization command and forwards it to the next slave. Each subsequent slave appends its own device information to the end of the frame after receiving the initialization command frame forwarded by the preceding slave, until the initialization command frame returns to the host. The host parses the finally returned initialization command frame to obtain the number, device type and status information of all online slaves, and generates a slave information table to complete the automatic address allocation.
[0010] Furthermore, the slave device's own device information includes device type and firmware version, and the slave device information table generated by the host contains the logical address assigned to each slave device and its corresponding device information.
[0011] Furthermore, in S300, both the command frame and the response frame include a frame header, a destination address / source address, a command code / status code, a data length, a data payload, and a checksum field; When a slave device forwards a command frame whose target address does not match its own address, it only performs hardware forwarding or simple regeneration forwarding and does not modify the data within the command frame.
[0012] Furthermore, in S400, the reporting frame format includes a frame header, a source address chain, a data payload chain, and a frame trailer; The source address chain and the data payload chain are in a one-to-one correspondence, recording the address of each slave device that reports data along the way and its corresponding data. The host can directly locate the source of the data by resolving the address chain.
[0013] Furthermore, the working principle of the S500 for transmitting high-speed data is as follows: The slave device that supports parallel transmission maintains a data buffer. When the amount of data reaches a preset threshold or when it receives a parallel upload command from the host, the slave device activates its configured multi-channel serial port, divides the data in the buffer into blocks, and sends them in parallel through the multi-channel serial port. When data is transmitted on the loop, each signal is still serial on the physical link, but logically they form a parallel channel. The host only needs to receive the aggregated serial data stream through one receiver of the main communication serial port, and can distinguish and reassemble data from different parallel channels through specific frame header identifiers.
[0014] Furthermore, when the insertion detection IO pin detects a failure or removal of a slave device on the ring bus loop, its adjacent upstream and downstream slave devices automatically skip the failed or removed slave node through the state change of the insertion detection IO pin and the software communication protocol, thus maintaining normal communication for the remaining slave devices in the loop. When a new slave device is inserted, the host identifies the new device and updates the slave device information table through the insertion detection IO pin and step S200.
[0015] Compared with existing technologies, this UART-based multi-serial-port parallel transmission ring bus design method has the following advantages: I. This invention achieves plug-and-play and dynamic reconfiguration of the bus by constructing a closed-loop hardware topology and combining insertion detection I / O with automatic initialization software processes. At the hardware level, the UART serial ports of the host and each slave are sequentially connected to form a ring. Each slave only needs to communicate with its adjacent node. When adding a new slave, it can be inserted into any position in the ring. Its insertion detection I / O pin works in conjunction with the insertion indication I / O pin of the adjacent node, and the physical layer can sense the state change. At the software level, the host broadcasts specific instructions when initializing or detecting a change. The slaves on the ring use an information relay mechanism to attach their own device information to the instruction frame sequentially and finally summarize it to the host. The host automatically parses the number, type and status of all online slaves, dynamically builds and updates the slave information table, and completes the automatic address allocation. This mechanism fundamentally solves the deployment problems of traditional bus expansion requiring network interruption and manual configuration of slave addresses, realizes hot-swapping and plug-and-play, and improves the adaptability and maintainability of the system in dynamic networking scenarios.
[0016] II. This invention achieves a breakthrough in both communication efficiency and reliability at extremely low cost through an active reporting mechanism combining broadcast triggering and address appending forwarding, and a hierarchical forwarding mechanism based on address matching. In slave-initiated reporting mode, the host only needs to send a broadcast trigger frame once. All slaves on the loop that have data to report will append their data and their own addresses hierarchically to the same reporting frame and return it to the host. The host can complete the data acquisition of all slaves in one communication cycle by parsing the source address chain and data payload chain in the frame. In host unicast communication, the command frame is forwarded hierarchically on the loop. The unrelated slave devices only perform transparent forwarding without modifying the frame content, ensuring minimal transmission latency. After the target slave device executes the instruction, it organizes a reply frame to return along the loop. This mechanism, combined with insertion detection I / O, allows adjacent nodes to detect the status change and report it to the master when any slave device fails. After the master updates the slave information table, the communication frame skips the faulty node and continues transmission. This design not only improves communication efficiency through address matching and parallel reporting, but also gives the system self-healing capability under single-point failure. While maintaining the low-cost advantage of UART, it significantly improves the reliability of the bus in complex industrial environments.
[0017] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description
[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.
[0019] Figure 1 A flowchart illustrating the design steps of a UART-based multi-serial-port parallel transmission ring bus; Figure 2 This is a schematic diagram of the ring-shaped serial bus system structure in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the steps of high-speed parallel data transmission across multiple serial ports in an embodiment of the present invention. Detailed Implementation
[0020] To better understand the above technical solutions, a detailed description of the solutions will be provided below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.
[0021] To address the limitations of existing serial communication technologies in multi-device networking applications, such as high hardware costs, poor scalability, low communication efficiency, and complex deployment and maintenance, this invention provides a UART-based multi-serial port parallel transmission ring bus design method. This method aims to construct a closed-loop hardware topology and combine it with intelligent software protocols to achieve plug-and-play functionality, efficient data acquisition, reliable unicast communication, and high-speed parallel data transmission capabilities for devices, while maintaining the simplicity and low cost advantages of UART communication. This results in a multi-device communication solution that is scalable, highly efficient, and highly reliable.
[0022] This invention is mainly applied to scenarios such as industrial control, IoT sensor networks, and smart homes that require centralized monitoring and data acquisition of multiple slave devices. Traditional solutions, such as star topologies, require the host to equip each slave with an independent serial port, and the cost increases linearly with the number of nodes. Although the RS-485 bus reduces connection complexity, its reliance on host polling leads to low efficiency, and node failures can easily cause network-wide paralysis. Address configuration is also mostly manual, making deployment cumbersome. This invention achieves a low-cost, highly reliable, plug-and-play serial communication bus with parallel transmission capabilities through hardware serialization of a ring topology, physical layer sensing based on insertion detection IO, a software relay mechanism with automatic initialization, and a logical channel design for multi-path parallel transmission.
[0023] Specifically, such as Figure 1 As shown, a design method for a multi-serial-port parallel transmission ring bus based on UART is presented. The method includes the following steps: S100. Connect at least one slave device to a master device sequentially via a UART serial port to form a closed-loop communication link. The transmitting end of the master device is connected to the receiving end of the first slave device, the transmitting end of subsequent slave devices is connected to the receiving end of the next slave device, and the transmitting end of the last slave device is connected back to the receiving end of the master device. S200 After the system is powered on and reset, the host broadcasts an initialization command through the transmitter. Each slave device on the closed-loop communication link receives the initialization command in sequence, and forwards it to the next node after attaching its own device information to the initialization command frame. All device information of the slave devices is summarized to the host through the closed-loop communication link. The host builds and stores a complete slave information table based on the summarized information. S300: The host sends a command frame containing the target slave address to a designated slave. The command frame is forwarded level by level on the loop. Each slave that receives the command frame parses the target address in the command frame. When the target address does not match its own address, the command frame is forwarded directly to the next slave. When they match, the target slave executes the command frame and organizes the response data into a reply frame, which is then returned to the host along the loop. S400: The master sends a broadcast trigger frame at regular intervals. After receiving the broadcast trigger frame, the slave packs the data to be reported and its own address into a reporting frame and forwards it to the next slave. The reporting frame is forwarded level by level in the loop. Each time it passes through a slave, the slave appends its own data to be reported and its address to the reporting frame and continues to forward it. The complete reporting frame carrying all the slave data to be reported is returned to the master. S500: When the system transmits high-speed data, it configures multiple transmit serial ports for at least one slave device, and transmits data in parallel through multiple transmit serial ports. The master device can receive and process all the data transmitted in parallel through one receive serial port.
[0024] In the specific implementation process, the hardware is first deployed. This embodiment takes a typical industrial field data acquisition system as an example. The system includes an industrial control computer as the host and multiple intelligent sensor nodes as slaves. A closed-loop communication link is constructed according to the method described in S100.
[0025] like Figure 2As shown, the host is configured with at least one master communication serial port and one insertion detection I / O pin. The master communication serial port includes a transmitter (TX) and a receiver (RX) for master communication on the ring bus. The insertion detection I / O pin is used to detect whether a new slave device has been inserted on the ring bus and whether an existing slave device has been removed. Each slave device is configured with at least one master communication serial port, one insertion detection I / O pin, and one insertion indication I / O pin. The master communication serial port includes a transmitter (TX) and a receiver (RX) for communicating with adjacent slave nodes. The insertion detection I / O pin is used to detect whether it has correctly entered the loop. The insertion indication I / O pin is used to report its insertion status to adjacent superior slave nodes.
[0026] In terms of physical connection, the TX pin of the master is connected to the RX pin of the first slave (slave 1), the TX pin of slave 1 is connected to the RX pin of the second slave (slave 2), and so on, until the TX pin of the last slave (slave N) is connected back to the RX pin of the master, thus forming a closed physical loop. Simultaneously, the insertion detection IO pin of each slave is connected to the insertion indication IO pin of its adjacent lower-level slave. For example, in this embodiment, the insertion detection IO of slave 1 is connected to the insertion indication IO of slave 2, the insertion detection IO of slave 2 is connected to the insertion indication IO of slave 3, and so on. The master is connected to the insertion indication IO pin of slave 1 through its insertion detection IO pin. This connection method enables the system to detect the insertion or removal event of any node at the physical layer.
[0027] After the system is powered on or reset, it enters the automatic initialization and device discovery phase. The host first broadcasts an initialization command through its TX terminal. In this embodiment, the command is specifically an idle channel evaluation command. The command frame is sent from the host along the loop and first reaches the RX terminal of slave 1.
[0028] After receiving the initialization command, slave device 1 parses it into an initialization broadcast frame according to the protocol. At this point, slave device 1 appends its pre-set device information as the data payload to the initialization command. This device information includes, but is not limited to, device type, firmware version, and a pre-set identifier generated from a unique hardware ID. Then, slave device 1 forwards the new frame with its appended information to the next slave device, slave device 2, via its TX terminal.
[0029] Slave 2 performs the same operation: upon receiving a frame from slave 1, it appends its own device information to the end of the current frame and then forwards it to slave 3. Each slave appends its own information to the end of the frame until it passes through slave N and returns to the master's RX end. At this point, the frame carries the device information of all online and correctly responding slaves on the loop.
[0030] The host parses the final returned initialization command frame to obtain the number, device type, firmware version, and status information of all online slave devices. Based on the number, device type, firmware version, and status information of the slave devices, the host automatically assigns a temporary or permanent logical address to each slave device and generates a complete slave device information table, which is stored in local memory. This slave device information table contains the logical address of each slave device and its corresponding detailed device information, completing the automatic address allocation and registration of all slave devices. Simultaneously, the insertion detection I / O pin and insertion indication I / O pin of each slave device work together to ensure that each slave device can perceive its connection status in the loop. If a slave device fails to connect correctly, no information will be appended to the initialization frame, thus being identified by the host as an offline or faulty device.
[0031] After initialization, the system enters the normal operation phase, supporting two main communication modes: S300 unicast communication mode and S400 slave active reporting mode.
[0032] In the unicast communication mode of S300, in this embodiment, the host needs to send a configuration command to the pressure sensor with slave address 0x03. The host first constructs a command frame, which contains a standard field structure: frame header (for synchronization and identification), target address (0x03), command code (such as reading the current pressure value), data length, data payload, and checksum (such as CRC check). The host sends the command frame through its TX terminal.
[0033] The command frame is forwarded cascadingly along the loop. The first slave device to receive the frame, 1, checks the frame header for synchronization and then parses the destination address field. Since its own address is 0x01, which does not match 0x03, according to the protocol, slave device 1 only performs hardware forwarding or simple regeneration forwarding, without modifying the data within the frame, to ensure minimal transmission delay. It then sends the command frame to slave device 2 via its TX terminal. Slave device 2 performs the same operation, forwarding it to slave device 3.
[0034] After receiving the command frame, slave device 3 (address 0x03) parses the target address and finds it matches its own address. It stops forwarding the command frame and executes the operation indicated by the command code carried within the frame, namely, reading the current pressure value. After execution, slave device 3 needs to return the result to the master, organizing the response data into a reply frame. This reply frame also includes a frame header, source address (0x03), status code (indicating success or failure), data length, data payload (the read pressure value), and checksum. Slave device 3 sends this reply frame to the next slave device, slave device 4, via its TX terminal; otherwise, it sends it directly to the master. The reply frame continues to be forwarded along the loop, eventually reaching the master's RX terminal. The master parses the reply frame and obtains the required data. This mechanism ensures the accuracy and low latency of point-to-point communication.
[0035] In the slave active reporting mode of S400, the master efficiently collects the real-time status data of all slaves. The master periodically sends a broadcast trigger frame through its TX terminal. This broadcast trigger frame does not contain a specific target address, but is designed to be a special frame that all slaves can recognize and respond to.
[0036] The broadcast trigger frame arrives at slave 1 first. After receiving the frame, slave 1 checks whether it has any data to report. If it does, slave 1 packages its own address and the data to be reported into a reporting unit, appends it to the original broadcast trigger frame to form a new reporting frame, and forwards it to slave 2. If slave 1 has no data to report, it forwards the original broadcast trigger frame without adding any content.
[0037] After receiving a frame from slave 1, slave 2 executes the same logic, regardless of whether the frame is a raw broadcast frame or a report frame with data appended: check if it has data to report. If so, append its own address and data as a new report unit to the end of the current frame, and then continue to forward it to the next slave, and so on.
[0038] Finally, when the report frame returns to the host, it has become a complete reporting frame carrying information about all the slave devices that have data to be reported. This reporting frame is designed to include a frame header, a source address chain, a data payload chain, and a frame trailer. The elements in the source address chain and the data payload chain correspond one-to-one, recording the address of each slave device reporting data along the way and its corresponding data. By parsing this complete frame, the host can obtain all the reported data from the slave devices at once and directly locate the source of each data item through the address chains, improving the efficiency of multi-slave data acquisition.
[0039] For slave devices in the system that require high-speed data transmission, the S500 provides a parallel transmission solution, such as... Figure 3 As shown, the specific steps for high-speed parallel data transmission across multiple serial ports are as follows: (1) Slave preparation and trigger condition judgment The slave device that supports parallel transmission maintains an internal data buffer to temporarily store high-speed data to be sent.
[0040] The slave device continuously monitors the amount of data in the buffer or listens for commands issued by the master device.
[0041] The parallel transmission process is triggered when the amount of data in the buffer reaches a preset threshold, or when the slave device receives a parallel upload command from the master device.
[0042] (2) Data segmentation and channel allocation The slave device divides the data to be sent in the buffer into N data blocks of similar size according to the number of multi-channel serial ports configured for it.
[0043] A specific frame header identifier is added to each data block to identify the parallel channel number to which the data block belongs, so that the host can distinguish and reassemble it later.
[0044] (3) Parallel transmission activation The slave device simultaneously activates N serial ports to transmit data, sending out N data blocks with channel identifiers in parallel through their respective serial lines.
[0045] Each data stream is transmitted on its own physical link in standard UART serial format, but multiple streams are concurrent in time, forming a logical parallel channel.
[0046] (4) Loop forwarding step by step Multiple parallel data streams are transmitted independently on the ring bus. As each data stream passes through subsequent slave nodes along the ring, the intermediate slave nodes transparently forward the data according to the protocol.
[0047] Each data stream transmits independently without interfering with the others until it reaches the receiving end of the host.
[0048] (5) Host reception and data stream aggregation The host receives the aggregated data stream from the loop only through one receiver (RX) of its main communication serial port.
[0049] The host parses the received data stream and identifies which parallel channel each data block belongs to based on the frame header identifier attached to it.
[0050] (6) Data reconstruction and restoration The host will sort and splice N data blocks belonging to the same batch of parallel transmission according to the channel number to restore the original high-speed data blocks.
[0051] The reorganized data can be delivered to upper-layer applications for further processing.
[0052] (6) State update and cycle preparation After completing a parallel transmission, the slave device clears the data already sent from its buffer, continues to monitor the amount of data in the buffer, and waits for the next trigger condition.
[0053] The host updates relevant statistical information and can send feedback on the reception status to the slave.
[0054] In this embodiment, for example, the slave device 3 is a smart sensor that needs to upload high-frequency vibration data. In terms of hardware design, the slave device 3 is additionally configured with multiple transmitting serial ports, including three transmitting serial ports TX1, TX2 and TX3, while the master device still only retains one master receiving serial port RX, and the slave device 3 maintains a data buffer internally.
[0055] When the amount of data in the buffer of slave device 3 reaches the preset threshold, or when a parallel upload command is received from the host, the parallel transmission mode is activated. Slave device 3 divides the large data block in the buffer into three smaller data blocks and sends them out simultaneously through its three serial ports TX1, TX2, and TX3. These three data streams are still transmitted serially on the physical link, but because they are transmitted simultaneously on different physical lines, they constitute three parallel channels.
[0056] These three signals are transmitted along the loop. During transmission, they pass through other slave devices. These parallel channel signals are forwarded as independent data streams on the loop, eventually reaching the master. The master receives and processes these three serial data streams. After receiving the mixed data stream, the master distinguishes which channel the data belongs to based on these frame header identifiers, and reassembles the three data streams belonging to the same batch to restore the original high-speed data block. By adding a small number of transmit serial ports to some nodes, high-speed data transmission at key nodes is achieved without changing the master hardware or increasing the number of receive serial ports, breaking through the rate bottleneck of a single-channel UART.
[0057] During system operation, if slave 2 is removed due to a fault, its adjacent slaves 1 and 3 will detect the status change via their I / O pins. Specifically, the removal of slave 2 causes a change in the insertion detection I / O pin level of its parent node, slave 1, and simultaneously, the insertion indication I / O pin of its lower node, slave 3, will also detect an anomaly. After detecting the change, slaves 1 and 3 will communicate and confirm the fault at the software level according to a preset protocol. After confirming the fault, they will each adjust their forwarding logic to automatically bypass the faulty slave 2 node. At the same time, either slave 1 or slave 3 will encapsulate the fault information in the next reporting frame and send it to the master.
[0058] Upon receiving a fault report, the host updates its stored slave information table, marking slave 2 as offline. Subsequently, the host will operate based on the updated information table during unicast communication or broadcast triggering. When a new slave (e.g., slave 4) is inserted between slave 1 and slave 3, its insertion process is detected by the I / O pins of adjacent nodes. The host, through a periodic or event-driven initialization process, identifies the newly inserted slave 4, automatically assigns it an address, updates its slave information table, and simultaneously notifies slave 1 and slave 3 to restore normal sequential forwarding logic, bringing slave 4 into the loop. The entire process requires no system downtime, achieving plug-and-play functionality and dynamic self-healing.
[0059] In summary, this invention constructs a low-cost, highly reliable, highly efficient serial communication bus with dynamic reconfiguration capabilities through closed-loop hardware topology, collaborative sensing of IO pins, relay initialization, and intelligent communication protocols. It not only solves the problems of poor scalability of traditional star topologies and low efficiency and insufficient reliability of RS-485 buses, but also breaks through the UART rate bottleneck through an innovative parallel transmission mechanism. It provides a solution for industrial IoT and resource-constrained embedded multi-device communication scenarios, and can significantly improve the deployment convenience, communication efficiency, and system robustness of multi-device networking.
[0060] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.
Claims
1. A design method for a multi-serial-port parallel transmission ring bus based on UART, characterized in that, The steps of this method are as follows: S100. Connect at least one slave device to a master device sequentially via a UART serial port to form a closed-loop communication link. The transmitting end of the master device is connected to the receiving end of the first slave device, the transmitting end of subsequent slave devices is connected to the receiving end of the next slave device, and the transmitting end of the last slave device is connected back to the receiving end of the master device. S200. After the system is powered on and reset, the host broadcasts an initialization command through the sending end. Each slave device on the closed-loop communication link receives the initialization command in sequence, and forwards it to the next node after attaching its own device information to the initialization command frame. The device information of all slave devices is summarized to the host through the closed-loop communication link. The host constructs and stores a complete slave device information table based on the summarized information. S300. The host sends a command frame containing the target slave address to a designated slave. The command frame is forwarded level by level on the loop. Each slave that receives the command frame parses the target address in the command frame. When the target address does not match its own address, the command frame is forwarded directly to the next slave. When they match, the target slave executes the command frame and organizes the response data into a reply frame, which is then returned to the host along the loop. S400. The host periodically sends a broadcast trigger frame. After receiving the broadcast trigger frame, the slave device packages the data to be reported and its own address into a reporting frame and forwards it to the next slave device. The reporting frame is forwarded level by level in the loop. Each time it passes through a slave device, the slave device appends its own data to be reported and its address to the reporting frame and continues to forward it. The complete reporting frame carrying all the slave device data to be reported is returned to the host. S500: When the system transmits high-speed data, at least one slave device is configured with a multi-channel serial port for transmitting data in parallel through the multi-channel serial port. The master device can receive and process all the data transmitted in parallel through a single receiving serial port.
2. The design method for a multi-serial-port parallel transmission ring bus based on UART according to claim 1, characterized in that, The host is configured with at least one main communication serial port and one insertion detection I / O pin; The main communication serial port includes a transmitter (TX) and a receiver (RX) for main communication on the ring bus. The insertion detection IO pin is used to detect whether a new slave device is inserted or an existing slave device is removed on the ring bus.
3. The design method for a multi-serial-port parallel transmission ring bus based on UART according to claim 1, characterized in that, The slave device is configured with at least one master communication serial port, one insertion detection IO pin, and one insertion indication IO pin; The main communication serial port includes a transmitter (TX) and a receiver (RX) for communicating with adjacent slave nodes. The insertion detection IO pin is used to detect whether it is correctly connected to the loop; The insertion indication IO pin is used to report its insertion status to the adjacent superior slave node.
4. The design method for a multi-serial-port parallel transmission ring bus based on UART according to claim 1, characterized in that, In S200, the initialization command broadcast by the host is an idle channel evaluation command. The first slave to receive the initialization command appends its preset self-device information as data payload to the initialization command and forwards it to the next slave. Each subsequent slave appends its own device information to the end of the frame after receiving the initialization command frame forwarded by the preceding slave, until the initialization command frame returns to the host. The host parses the finally returned initialization command frame to obtain the number, device type and status information of all online slaves, and generates a slave information table to complete the automatic address allocation.
5. The design method for a multi-serial-port parallel transmission ring bus based on UART according to claim 4, characterized in that, The slave device's own device information includes device type and firmware version, and the slave device information table generated by the host contains the logical address assigned to each slave device and its corresponding device information.
6. The design method for a multi-serial-port parallel transmission ring bus based on UART according to claim 1, characterized in that, In S300, both the command frame and the response frame include a frame header, a destination address / source address, a command code / status code, a data length, a data payload, and a checksum field. When a slave device forwards a command frame whose target address does not match its own address, it only performs hardware forwarding or simple regeneration forwarding and does not modify the data within the command frame.
7. The design method for a multi-serial-port parallel transmission ring bus based on UART according to claim 1, characterized in that, In S400, the reporting frame format includes a frame header, a source address chain, a data payload chain, and a frame tail; The source address chain and the data payload chain are in a one-to-one correspondence, recording the address of each slave device that reports data along the way and its corresponding data. The host can directly locate the source of the data by resolving the address chain.
8. The design method for a multi-serial-port parallel transmission ring bus based on UART according to claim 1, characterized in that, The working principle of the S500 for transmitting high-speed data is as follows: The slave device that supports parallel transmission maintains a data buffer. When the amount of data reaches a preset threshold or when it receives a parallel upload command from the host, the slave device activates its configured multi-channel serial port, divides the data in the buffer into blocks, and sends them in parallel through the multi-channel serial port. When data is transmitted on the loop, each signal is still serial on the physical link, but logically they form a parallel channel. The host only needs to receive the aggregated serial data stream through one receiver of the main communication serial port, and can distinguish and reassemble data from different parallel channels through specific frame header identifiers.
9. The design method for a multi-serial-port parallel transmission ring bus based on UART according to claim 2, characterized in that, When the insertion detection IO pin detects a failure or removal of a slave device on the ring bus loop, its adjacent upstream and downstream slave devices automatically skip the failed or removed slave node through the state change of the insertion detection IO pin and the software communication protocol, thus maintaining normal communication for the remaining slave devices on the loop. When a new slave device is inserted, the host identifies the new device and updates the slave device information table through the insertion detection IO pin and step S200.