Bus communication inspection method based on master-slave communication mode and related equipment

Abstract

The invention discloses a bus communication inspection method based on a master-slave communication mode and related equipment, and relates to the field of communication. The method comprises the following steps: determining a starting slave from a plurality of slaves; an inspection command frame is generated based on the address of the starting slave, and in the inspection command frame, the receiving address is the address of the starting slave, and the sending address is the address of the host; after the inspection command frame is sent to the bus, data transmitted on the bus is monitored, starting slave response data from the starting slave are obtained, and a slave target address in the starting slave response data is the address of the next to-be-inspected slave; after the starting slave response data are received, data transmitted on the bus are continuously monitored, current slave response data from the current slave are obtained, and a slave target address in the current slave response data is the address of a next to-be-inspected target slave after the current slave. According to the invention, more efficient and real-time bus communication inspection can be realized, and the problem of slow response of host inspection is relieved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a bus communication inspection method based on a master-slave communication mode and related equipment. Background Art

[0002] In the field of bus communication, many systems, limited by bus hardware characteristics, typically employ a master-slave half-duplex communication mode. In this mode, only one device on the bus acts as the master, while the remaining devices act as slaves. Each slave is assigned a unique communication address. To prevent data conflicts, only one device on the bus can be in the transmitting state at any given time, while the others are in the receiving state. Typically, if the master is transmitting, the slaves are receiving; if one slave is transmitting, the remaining slaves and the master are receiving.

[0003] Based on the system logic requirements and the specified communication protocol, the host performs a one-by-one polling of slaves. Specifically, the host sends a communication command to the target slave, then switches to the receiving state, awaiting feedback from the designated slave. All slaves on the bus receive the information sent by the host, but only when the address information sent by the host matches its own address is the slave identified as the one being polled. The polled slave then interprets the command sent by the host, switches to the sending state, and sends the relevant information or data to the bus, then switches back to the receiving state. After receiving and processing the data from the current slave, the host continues to poll the remaining slaves in the same cycle. This communication mode is characterized by "answering only when asked, and not answering when not asked."

[0004] However, when there are many slaves connected to the bus, the time required for the host to complete a round of polling of all slaves increases significantly. This results in the host not being able to obtain the status or data of the slaves in a timely manner, making the host appear "sluggish" during inspections, seriously affecting the real-time performance of the system. Summary of the Invention

[0005] In view of the above technical problems and defects, the purpose of the present invention is to provide a bus communication inspection method and related equipment based on the master-slave communication mode, which can perform bus communication inspection more efficiently and in real time, and alleviate the problem of slow host inspection response.

[0006] To achieve the above-mentioned objectives, in a first aspect, the present invention provides a bus communication inspection method based on a master-slave communication mode, which is applied to a host of a bus communication system, the bus communication system also including a bus and multiple slaves, the host and the slaves are all connected to the bus, and the method includes: determining a starting slave from multiple slaves; generating a inspection command frame based on the address of the starting slave, the inspection command frame including a receiving address, an issuing address and a command code, in which the receiving address is the address of the starting slave, and the issuing address is the address of the host; after sending the inspection command frame to the bus, monitoring the data transmitted on the bus to obtain starting slave response data from the starting slave, the receiving address of the starting slave response data is the address of the host, the issuing address is the address of the starting slave, and the slave target address is the address of the next slave to be inspected; after receiving the starting slave response data, continuously monitoring the data transmitted on the bus to obtain current slave response data from the current slave, the receiving address of the current slave response data is the address of the host, the issuing address is the address of the current slave, and the slave target address is the address of the next target slave to be inspected after the current slave.

[0007] The method of the present invention innovatively designs the inspection command frame and response data structure, and carries the address of the next slave to be inspected in advance in the response data of each slave, so that the host can know the inspection sequence in advance, and the slave to be inspected receives the response data sent by the previous slave, and automatically triggers a chain response, thereby significantly reducing the polling waiting time, avoiding the system response delay problem caused by one-by-one naming in the traditional master-slave communication mode, and realizing a more efficient and real-time bus communication inspection mechanism, effectively improving the communication performance and communication timeliness of the multi-slave system, especially in complex communication scenarios with a large number of slaves, can significantly shorten the inspection cycle and improve the real-time response capability of the system.

[0008] In a second aspect, the present invention also provides a bus communication inspection method based on a master-slave communication mode, which is applied to a slave in a bus communication system, wherein the bus communication system also includes a host and a bus, and the slave and the host are both connected to the bus. The method includes: when being designated as the current inspection slave, receiving an inspection command frame from the host or response data of the previous slave, the inspection command frame or the response data of the previous slave including the address of the current inspection slave; based on the inspection command frame or the response data of the previous slave, according to a preset inspection order, determining the address of the next slave to be inspected; generating new slave response data according to the address of the next slave to be inspected, the new slave response data including the address of the current inspection slave, the address of the host, and the address of the next slave to be inspected as the slave target address; and sending the new slave response data to the bus for receipt by the host and the next slave to be inspected.

[0009] The beneficial effects of the method provided in the second aspect of the present invention can be referred to the first aspect and will not be repeated here.

[0010] In a third aspect, an embodiment of the present invention provides a monitoring device, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the monitoring device to execute the method described in the first aspect and any possible implementation of the first aspect.

[0011] In a fourth aspect, the present invention provides a computer-readable storage medium comprising instructions, which, when executed on a monitoring device, enable the monitoring device to execute the method described in the first aspect and any possible implementation of the first aspect.

[0012] In a fifth aspect, the present invention provides a computer program product comprising instructions, which, when executed on a monitoring device, enables the monitoring device to execute the method described in the first aspect and any possible implementation of the first aspect.

[0013] It is understood that the electronic device provided in the third aspect, the storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect are all used to execute the method provided by the present invention. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 This is an architectural diagram of a bus communication system according to an embodiment of the present invention; Figure 2 This is a flow chart of a bus communication inspection method based on a master-slave communication mode according to an embodiment of the present invention; Figure 3 1 is a schematic diagram of communication logic between a host and a slave based on a shared bus in an embodiment of the present invention; Figure 4 This is a timing diagram of data interaction between the host and the slave in an embodiment of the present invention; Figure 5 This is a schematic diagram of host data storage in an embodiment of the present invention; Figure 6 This is a timing logic diagram of bus data reception and transmission in an embodiment of the present invention; Figure 7 Schematic diagram of communication process and state switching in an embodiment of the present invention; Figure 8 It is a structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0015] The embodiment of the present invention provides a bus communication system, such as Figure 1 As shown, it includes a host (for example, the address is 0x00), a bus and multiple slaves (for example, the addresses include 0x01, 0x02...0x0n), and the host and the slaves are all connected to the bus.

[0016] The host, serving as the core control unit of the bus communication system, is equipped with a high-performance microprocessor or dedicated controller and integrates advanced communication interface circuits, data processing modules, and registers. In this embodiment, the host is capable of parsing specific fields in the data, quickly identifying and extracting the "slave target address" contained in the slave's response. This allows the host to optimize its subsequent monitoring and data processing processes, thereby achieving uninterrupted chain inspections. This reduces the waiting time associated with traditional roll-call addressing, improving data processing efficiency and system response speed.

[0017] As a controlled terminal device in a bus communication system, a slave typically consists of an embedded microcontroller, a bus transceiver, and a data storage unit. In addition to receiving bus commands, executing corresponding operations, and transmitting its own data, its internal firmware or dedicated hardware logic is designed to automatically or according to preset rules embed the "address of the next slave to be inspected" as the "slave target address" in its response frame when generating response data. The slave has the ability to store or dynamically generate this address and encapsulate it along with its own data, providing "relay" information to the master, achieving automated and efficient continuous bus inspection.

[0018] The embodiment of the present invention also provides a bus communication inspection method based on the master-slave communication mode, which is applied to the host of the above bus communication system. Figure 2 As shown, the method includes the following steps: Step 201: Determine a starting slave from multiple slaves.

[0019] As the master controller of the entire system, the host computer must first determine the starting point of its inspection chain, the "starting slave," before executing an inspection task. This determination process is not a random selection for the host computer, but is based on a preset strategy or the system's initial configuration.

[0020] Specifically, the host may use the following methods to determine the starting slave: A common method is to specify the physical address or logical address order of the slaves at the beginning of the system design. For example, the slave with the smallest address (such as slave ID 0x01) is designated as the starting slave. In this case, the firmware or software logic within the host directly loads and uses this preset starting address.

[0021] Another more dynamic approach is that during system power-up or initialization, the master might perform a "slave discovery" or "address assignment" process. By broadcasting a query command, all online slaves reply with their addresses. The master collects these addresses and builds a slave list. The master can then select the first slave from this list as the starting slave based on some sorting criteria (such as address size, connection order, or specific function priority).

[0022] In addition, in some complex application scenarios, the starting slave can even be manually configured by the operator through the human-machine interface, or dynamically selected by the intelligent algorithm within the host based on the current system operating status and task requirements. For example, the slave with the closest distance, the highest priority, or the next slave at the time of the last patrol interruption is selected as the starting point.

[0023] Regardless of the identification method used, the core is that the host must logically determine the identity and unique bus address of the first slave with which it intends to communicate. This serves as the basis for subsequent generation of the inspection command frame and is the critical first step in initiating the entire chain inspection process. The host is responsible for maintaining the address information of this starting slave so that it can call it at the appropriate time.

[0024] Step 202: Generate a patrol command frame based on the address of the starting slave.

[0025] The inspection command frame includes a receiving address, an issuing address and a command code. In the inspection command frame, the receiving address is the address of the starting slave, and the issuing address is the address of the master.

[0026] The generation of the inspection command frame strictly follows the predefined communication protocol format to ensure that it can be correctly parsed by all devices on the bus and finally received and processed by the target slave.

[0027] Specifically, the host's internal communication protocol stack fills in the key fields of the command frame according to the following specifications: First, the "receive address" field, where the host writes the unique address of the starting slave it previously determined. This address serves as the "house number" of the command frame's ultimate recipient as it travels across the bus. Only slaves with a matching address receive and process the frame.

[0028] Next is the "Outgoing Address" field, where the host enters its unique address (i.e., the host's bus address). This allows the initiating slave receiving the command frame to clearly identify the source of the command. This is crucial for the slave to subsequently generate correct response data, as the slave needs to set the receiving address of the response to the outgoing address to ensure that the response is accurately transmitted back to the host.

[0029] Finally, the "Command Code" field is where the host writes a specific command code, indicating the purpose of the communication (i.e., "inspection" or "data request"). This command code triggers the initiating slave to execute its internal inspection response logic, including collecting its own status data, preparing a response, and, according to the design of this embodiment, including the address of the next slave to be inspected in the response.

[0030] The entire inspection command frame generation process involves data encapsulation, checksum calculation (such as CRC), and the addition of frame headers and footers to ensure the integrity and reliability of data transmission. Once the inspection command frame is completely and correctly constructed, it can be sent to the physical bus through the host's bus interface, officially initiating the entire chain bus inspection process.

[0031] Step 203: After sending the inspection command frame to the bus, monitor the data transmitted on the bus to obtain the starting slave response data from the starting slave.

[0032] The receiving address of the response data of the starting slave is the address of the host, the sending address is the address of the starting slave, and the slave target address is the address of the next slave to be inspected.

[0033] After the host successfully constructs a patrol command frame for the initiating slave, its next key action is to transmit it onto the physical bus and then enter the listening state. This transmission process involves the host's internal bus interface controller converting the digitized command frame data into electrical signals suitable for bus transmission and driving these signals onto the shared bus medium via the bus driver. Once the command frame is successfully transmitted, the host does not immediately send the next command. Instead, it places its bus interface in receive mode and begins "listening" to all data flowing on the bus.

[0034] This listening process is not passive waiting, but an active and efficient process: the protocol stack inside the host parses the header information of each incoming frame in real time, especially the "receiver address" field. When the host recognizes that the "receiver address" of an incoming frame matches its own address, it knows that the frame is sent to it and receives it completely into its internal buffer.

[0035] In this embodiment, the host expects to receive the "initial slave response data" from the initiating slave at this stage. When an incoming frame is recognized as a valid response frame sent to the host itself, the host will further verify whether its "origin address" matches the address of the "initial slave" that previously sent the command, thereby confirming the correct source of the response.

[0036] Once confirmed, the host further analyzes the valid data content of the response data. In this embodiment, the host not only obtains the status or data information of the initiating slave itself, but more importantly, it accurately extracts the "slave target address" field from the response data. This field contains the address information of the next slave to be inspected. The host temporarily stores this extracted "slave target address" as part of its internal state, preparing for the next "chain" inspection.

[0037] The entire process requires the master to promptly and accurately obtain critical "relay" information from the initial slave's response, laying the foundation for subsequent seamless inspections. If no response is received after the preset waiting time, the master typically triggers a timeout mechanism and may attempt to resend the command or report a communication failure.

[0038] On the other hand, on the slave side, when the starting slave receives the inspection command frame sent by the host, it will first parse the command frame to confirm whether the receiving address is its own address, and identify the command code to determine the operation to be performed. Subsequently, the starting slave will perform the corresponding task, such as reading its own sensor data or status information. When preparing the response data, a key action of the starting slave is to determine the address of the next slave to be inspected according to the preset inspection sequence or internal logic, and embed it as the slave target address into its own response frame. Finally, the starting slave will send a complete response frame containing its own data, the host address as the receiving address, its own address as the sending address, and the key "slave target address" to the bus so that the host and the next slave to be inspected can receive it.

[0039] Step 204 : After receiving the initial slave response data, continuously monitor the data transmitted on the bus to obtain the current slave response data from the current slave.

[0040] The receiving address of the current slave's response data is the address of the master, the sending address is the address of the current slave, and the slave target address is the address of the next target slave to be inspected after the current slave.

[0041] After the host successfully receives and parses the response data from the initiating slave and extracts the target slave address (i.e., the address of the next slave in the chain to be inspected), it does not immediately construct and send a new command frame to actively query this "next slave" as in traditional polling. Instead, the host maintains the "listening" state established in step 203, continuously listening for data transmitted on the bus. This means the host is no longer an active initiator, but instead becomes an efficient receiver and chain manager.

[0042] First, while the host is continuously listening, its communication module continuously scans the bus, waiting for the next expected data packet. This "next expected data packet" is precisely the response from the slave (the "current slave") whose "slave target address" was obtained from the initial slave's response in the previous step. When the host receives a data frame and confirms that its receiving address is the host itself and that the sending address matches the slave target address previously extracted from the initial slave's response, it recognizes it as the current slave response data from the current slave. This matching mechanism is key to implementing chained inspection: when a slave sends its response, it already includes the address of the next slave to be inspected, and expects this next slave to respond automatically upon receiving the response. By monitoring and matching this address, the host detects and confirms the "relay" behavior between slaves.

[0043] Once the current slave's response data has been successfully received and verified, the master performs another parsing operation. It extracts the new slave target address from the current slave's response data. This new address points to the address of the next target slave to be inspected after the current slave, that is, the next slave in the chain. The master updates this new address into its internal state, and it serves as the source of the next expected slave response.

[0044] This process forms an efficient cycle: the master sends an initial command once, then passively and continuously receives responses from different slaves by continuously listening for the "slave target address" carried in the slave's response, without having to actively send a query command each time. This mechanism greatly reduces the time the master spends between slave communications, significantly improving the efficiency of bus inspections and the real-time nature of communications.

[0045] The host will maintain this state of continuous listening and address updating until it receives a preset end mark (for example, the "slave target address" in a slave's response indicates the end of the chain, or all known slaves have been inspected), or an abnormal situation such as timeout occurs.

[0046] On the slave side, the current slave's actions and data processing differ from those of the initiating slave in step 203. The current slave does not directly respond to the host's command. Instead, it monitors the data stream on the bus and, upon recognizing that the "slave target address" contained in the response data sent by the previous slave is its own address, triggers its own response mechanism. This means that the current slave receives and parses the response frames from the other slaves, extracting the address information indicating that it has been selected as the next inspection target. Once confirmed, the current slave performs its own tasks (such as data acquisition and fault self-testing), then generates a response frame containing its own data, the host's address as the receiving address, its own address as the sending address, and the address of the next target slave to be inspected after the current slave. This frame is then sent to the bus, completing the chain inspection "relay" process.

[0047] This embodiment adopts the above method and steps, and significantly optimizes the polling mechanism in the traditional master-slave communication mode by innovatively including the "slave target address", that is, the address of the next slave to be inspected, in the slave response data.

[0048] In related technologies, when there are a large number of slaves on the bus, the host needs to call out the slaves one by one. After each call, it needs to wait for the slave to respond and calculate or determine the next slave to be polled. This sequential and independent call-out method leads to a significant extension of the bus polling cycle, making it difficult for the host to obtain the slave status or data information in a timely manner, thereby showing "sluggish response" and affecting the communication effect of the system.

[0049] This embodiment solves this pain point: once the host sends a command to the starting slave and receives its response, the response data clearly indicates the address of the next slave in the chain to be inspected. This means that the host does not need to waste time querying or calculating the address after each slave responds. Instead, it can rely on the "relay" information provided by the slave itself to continuously listen for and receive the response from the next slave, eliminating the need for the host to poll each slave individually.

[0050] This "chain" or "relay" inspection method greatly reduces the host's decision-making and waiting time between two slave communications, thereby significantly shortening the entire bus inspection cycle, improving the real-time nature of data acquisition and system response speed, effectively solving the problem of slow system response, and significantly improving the performance and communication timeliness of the multi-slave bus communication system.

[0051] The following combination Figure 3 The communication logic of the bus in this embodiment is introduced. It is assumed that under normal working conditions, one host communicates with four slaves based on a shared bus. Figure 3 In the figure, a solid downward arrow represents the sender of data, while a hollow upward arrow represents the receiver of data. Figure 3 The dotted line in the figure is key to understanding this communication mechanism. It represents the causal relationship within the communication: a data frame sent in the previous communication step directly leads to an automatic response from the corresponding slave in the subsequent step. Furthermore, a key communication rule is that on the same bus, only one device is in the transmitting state at any one time, while all others are in the receiving state. This ensures orderly communication and avoids data conflicts.

[0052] The entire communication process is divided into six steps. Communication step 1 is initiated by the host, which sends data to all slaves on the bus. After receiving the host's command, in communication step 2, slave 1, acting as the target receiving slave, automatically responds and sends its data. At this point, the host and all other slaves are in receive mode. This chain response mechanism continues: in communication step 3, slave 2 responds and sends data; in communication step 4, slave 3 responds and sends data; and in communication step 5, slave 4 responds and sends data. In each step, only one designated device transmits, while the remaining devices receive. Finally, in communication step 6, the host sends data again, marking the end of a complete round of polling. This eliminates the need for the host to frequently send polling commands, improving system communication efficiency.

[0053] The implementation process of the method of this embodiment can also refer to Figure 4 As shown, the details are as follows: 1) Determine the starting slave: The master (0x00) first identifies a starting slave from among the multiple slaves connected to the bus (e.g., 0x01, 0x02, 0x03, 0x04). The figure shows the starting slave as 0x01. This determination may be based on a preset configuration, a bus scan, or a specific protocol.

[0054] 2) Generate and send a patrol command frame: The host generates a patrol command frame based on the address of the determined starting slave (0x01). This command frame is the first patrol instruction sent by the host and contains: Receive address: The address of the starting slave 0x01.

[0055] Issued address: Address of host 0x00.

[0056] Command code: Indicates that this is a patrol command.

[0057] The host then sends this patrol command frame onto the bus.

[0058] 3) Listening and receiving the starting slave response data: After sending the inspection command frame, the host begins monitoring the bus. When the starting slave 0x01 receives the inspection command for its address, it generates and sends the "starting slave response data." This response data contains the following key information: Receiving address: the address of the host 0x00 (indicating that the data frame is sent to the host).

[0059] Sending address: The address of the starting slave 0x01 (indicating that the data frame is sent by the slave with address 0x01).

[0060] Slave target address: This is the key innovation of this solution. The response data will clearly indicate the address of the next slave to be inspected (for example, 0x02). Once the host successfully receives this response data, it will know which slave to inspect next.

[0061] 4) Continuously monitor and receive subsequent slave response data: After receiving the response data from the initial slave 0x01, the master continues to monitor the bus based on the "slave target address" (0x02) indicated in the response data. When slave 0x02 receives an implicit or explicit (if the master generates a new command based on the response information) patrol command (or when it is its turn to respond), it sends the "slave (0x02) response data." This response data also contains: Receiving address: address of host 0x00.

[0062] Issued address: the address of the current slave 0x02.

[0063] Slave target address: indicates the address of the next slave to be inspected (for example, 0x03).

[0064] This process will continue. The host will automatically and chain-guide its inspection to the next slave on the bus through the "slave target address" carried in the response data received from each slave until all slaves are inspected or the preset inspection termination condition is reached.

[0065] Through the above process, this embodiment realizes the chain inspection driven by the slave, which significantly improves the efficiency and flexibility of bus communication inspection, which is specifically reflected in: Simplified host inspection logic: In traditional inspections, the host needs to maintain a complete list of slave addresses and send commands sequentially. In this solution, the host only needs to know the first starting slave. The slaves then inform the host of the subsequent inspection order in their response data, significantly reducing the host's burden on managing slave addresses and inspection order.

[0066] Enhanced system scalability: When slaves are added or removed from the bus, the host does not need to modify its internal slave list or inspection algorithm. As long as the new slave can provide the address of the next slave in the response according to the protocol, the entire inspection chain can automatically adapt to the change. This makes the system more plug-and-play and easier to maintain when the number of slaves changes.

[0067] Improve inspection efficiency: Chain inspection avoids the host needing to recalculate or find the next slave address and name it for inspection before each inspection. The slave directly provides the next address, reducing the host processing time and shortening the entire inspection cycle.

[0068] Reduce bus bandwidth usage (potential): If the host no longer needs to send a separate addressed command frame for each slave, but is guided by the slave's response, the number of command frames on the bus can theoretically be reduced, thereby optimizing bandwidth utilization.

[0069] In summary, this embodiment cleverly utilizes the "slave target address" field in the slave response data to delegate the inspection sequence control part to the slave, making the bus inspection process more intelligent, automated and adaptive, and has important application value for building an efficient and scalable bus communication system.

[0070] In some implementations of this embodiment, both the patrol command frame and the slave response data follow a predefined format.

[0071] The inspection command frame may specifically include: frame header M, receiving address (first slave address, such as 0x01), sending address (host's own address, such as 0x00), command code (indicating the data type of the slave's response), spare information, check code and frame tail M.

[0072] The slave response data may specifically include: frame header S, receiving address (i.e., host address), sending address (its own address), slave target address, command code, data information, check code, and frame tail S.

[0073] In the header and trailer of a patrol command frame, M indicates the command frame sent by the master. In the header and trailer of a slave response, S indicates the response data sent by the slave. The header and trailer of the patrol command frame and the slave response data can be different (i.e., M and S represent different information), making it easier for the master and slave to quickly identify the source of the data.

[0074] refer to Figure 5 , showing the data processing and storage structure when the host communicates with the slave. The upper part shows the frame format of the "serial port receive buffer", which represents the standardized structure of the data packet received by the host through the serial port. A complete communication frame contains multiple fields, such as the frame header, receiving address, sending address, destination address, command code, variable-length data field (data 1 to data n), high and low bit checksums for data integrity verification, and a frame trailer. This structure ensures that the host can correctly interpret any communication data from the bus. Figure 5The lower middle section shows the "slave data storage area within the host," indicating that the host maintains a highly organized database for storing data related to different slaves. This data is categorized and indexed based on "command code" and "slave address."

[0075] For example, for command code 1, the host can store data blocks obtained from or sent to slaves 0x01, 0x02, 0x03, 0x04, etc., each of which also contains multiple data items. This means that the host can accurately access the corresponding data based on the specific command type and target slave. Figure 4 It clearly shows how the host can exchange data through standardized communication frames and effectively organize and manage data with multiple slaves, providing a basis for realizing complex bus communication and device management.

[0076] The host's data processing and interaction process embodies its highly intelligent role as the initiator and manager of bus inspections, combined with passive reception. First, at the start of an inspection, the host constructs a standard inspection command frame in a predefined format according to the preset inspection strategy (for example, starting with the first slave address 0x01 on the bus). Once constructed, the host transmits the command frame onto the physical bus via its bus interface. After transmission, the host immediately switches its bus interface to the receive state, entering efficient listening mode and awaiting response data from the target slave.

[0077] During the listening process, the host continuously monitors the data flow on the bus. When data appears on the bus, the host first identifies the frame header (S) and frame trailer (S) to determine whether it is a valid data frame from a slave. Next, the host performs an integrity check on the received data, including verifying the checksum. If this check passes, the host further checks whether the frame's receiving address is its own address (0x00) to confirm that the response is intended for it. The host also records the sending address of the response frame, which is the address of the current responding slave. Crucially, the host extracts the slave target address field from the slave response frame. This field indicates the address of the next slave to respond in the chained poll. The host stores this slave target address as part of its internal state, but does not immediately issue a new command based on this address. Instead, the host remains in the receive state and continues to listen to the bus.

[0078] During subsequent inspections, the master no longer actively sends inspection commands, relying entirely on chained responses between slaves using the slave target address field. The master continuously monitors the bus. When it receives a new slave response frame, it repeats the checksum and address matching process described above. If the received address is the master itself and the checksum is correct, the master parses the frame, extracting the data and the new slave target address. The master updates this new slave target address as the source of the next expected response. This cycle continues until the master receives a special slave target address in a slave response that indicates the end of the inspection (for example, an invalid address or a specific end flag), or until the master fails to receive a response within a preset timeout period. If a timeout occurs, the host can implement a pre-defined error handling strategy, such as reissuing the inspection command and attempting to skip the currently unresponsive slave, redirecting the received address to the next slave address to ensure the continuity of the inspection chain. This mechanism significantly reduces the frequency of the host actively sending commands, thereby improving bus utilization and overall inspection efficiency.

[0079] The data processing and interaction processes of slaves during bus inspection demonstrate their high degree of autonomy and chain relay capabilities. Under normal operating conditions, all slaves on the bus are in receive mode, continuously monitoring the bus data flow. When the master sends a inspection command frame to the bus, all slaves receive the command and store it in their respective receive buffers. Each slave then rigorously verifies the format and content of the received command frame. The slave first checks the header (M) and trailer (M) to confirm that it is a complete master command. Next, it performs a checksum verification to ensure data transmission integrity. If the verification passes, the slave checks the receiving address field in the command frame. Only if the receiving address exactly matches the slave's own unique address is it recognized as the target slave for the command and prepares to respond. Slaves whose receiving addresses do not match the command ignore the command and remain in the listening state.

[0080] After confirming that it is the receiver, the selected target slave determines the specific task to be performed based on the command code in the command frame, such as reading internal sensor data or status register information, and prepares the corresponding data information. When preparing a response data frame, a key action of the slave is to determine the slave target address. According to the chain inspection mechanism of the present invention, under normal circumstances, the slave increments its own address by 1 as the slave target address (for example, if its own address is 0x01, the slave target address is 0x02). This slave target address is key information for enabling relay between slaves. The slave encapsulates this information (frame header S, receiving address (host address 0x00), sending address (its own address), calculated slave target address, command code, prepared data information, checksum, and frame trailer S) into a complete slave response data frame. After a short delay, the slave switches its bus interface to the transmit state and transmits the constructed response frame to the bus. After transmission is complete, the slave immediately switches back to the receive state and resumes monitoring the bus.

[0081] In subsequent chained patrols, the response logic of the slave (the current slave) differs slightly. It no longer waits for active commands from the master but instead continuously monitors the bus. When it receives a response data frame from the previous slave (for example, the slave with address 0x01), it verifies the frame header (S), frame trailer (S), and checksum, just as it does for a master command. If verification passes, it checks the slave target address field in the response frame. If this slave target address matches the current slave's own address, the current slave knows it is the next responder in the chained patrol. It immediately performs its own data acquisition task and, as described above, constructs a response frame containing its own data and the next slave's target address, sending it to the bus after a short delay.

[0082] This mechanism enables slaves to automatically trigger responses based on the data flow on the bus, achieving efficient self-driven chain inspection and greatly reducing the burden on the host. If all slaves on the bus cannot meet the sending conditions (for example, the target slave is offline or damaged), no slave will respond and the host will handle it through the timeout mechanism.

[0083] In some embodiments, during step 204 of continuously monitoring data transmitted on the bus, the method further includes: S2041: If no response data is received from the target slave within a preset time period, the next slave to be inspected after the target slave is determined as a new target slave.

[0084] The core of this step lies in the introduction of a timeout detection mechanism and a strategy for skipping faulty slaves. In a normal chained inspection process, after sending the initial inspection command, the master enters a passive listening state, expecting the slave target address field between slaves to drive subsequent responses. However, if a slave fails (for example, due to device offline, internal program freeze, or communication module damage), it will not be able to receive the response frame sent by the previous slave, or even if it does receive it, it will be unable to correctly process and issue its own response. In this case, the chained inspection is interrupted, and no new slave response data will appear on the bus for a long time.

[0085] To prevent the system from stalling for extended periods, the host needs to be able to detect such interruptions. This embodiment achieves this by setting a preset duration (i.e., a timeout). After receiving a response from the previous slave, the host starts an internal timer. If, by the timer's expiration, the host has not received a response from the slave pointed to by the slave's target address, the host determines that the target slave has failed or is unresponsive. To restore the inspection chain, the host no longer waits for the failed slave. Instead, based on a list of known slave addresses or a preset inspection sequence, it logically skips the failed slave and identifies the next valid slave after it as the new target slave. This process ensures inspection continuity and prevents a single slave failure from paralyzing the entire system.

[0086] Assume that the slave addresses on the bus are, in order, 0x01, 0x02, 0x03, and 0x04. The master initially sends a command to 0x01, which responds and indicates that the next target is 0x02. After receiving 0x01's response, the master starts a timer, for example, of 500 milliseconds, waiting for a response from 0x02. However, if slave 0x02 fails to respond for some reason (such as a power failure), the master will not receive any response from 0x02 within the 500 millisecond timeout. When the timer expires, the master determines that 0x02 has failed to respond. Based on its internal slave address list (0x01, 0x02, 0x03, 0x04), the master discovers that the next slave after 0x02 is 0x03. The master then identifies 0x03 as the new target slave and prepares to proactively intervene to resume inspection.

[0087] S2042: Generate a new inspection command frame according to the address of the new target slave.

[0088] Once the host has identified a new target slave in S2041, to reactivate the inspection chain, it must proactively intervene and send a direct inspection command to the new target slave. This step involves constructing this proactive command frame. Similar to the initial inspection command frame, this new inspection command frame follows a standard command format, but the key lies in the receive address field. Instead of the next address automatically passed by the slave during the chained inspection, the receive address is explicitly set to the address of the new target slave identified in S2041. This means the host no longer relies on relaying between slaves and can directly address the new target slave. The command code, originating address (the host's own address), backup information, checksum, and header and trailer fields are generated in the same manner as the initial command frame. This allows the host to precisely send commands to the slave following the skipped slave, effectively bypassing the failure point and restarting the inspection sequence.

[0089] Continuing with the S2041 example, the host has identified 0x03 as the new target slave. Now, the host needs to generate a command frame to wake up 0x03. It constructs a command frame, which includes: Frame header M: fixed value; Receive address: 0x03 (the address of the new target slave); Issued address: 0x00 (host's own address); Command code: The same code as the initial inspection command, indicating the data type that needs to be responded to 0x03; Spare information, check code, frame tail M: generated according to the standard. This newly generated command frame will be used specifically to instruct slave 0x03 to respond.

[0090] S2043: Send the new inspection command frame to the bus so that the new target slave receives and responds.

[0091] This is the final step in the host's proactive recovery of the inspection chain. After constructing a new inspection command frame in S2042, the host sends it to the physical bus via the bus interface. Because the receive address field of this command frame explicitly points to the new target slave, all slaves on the bus will perform an address match upon receiving the frame. Only the new target slave will recognize the command as intended for it, triggering its internal response logic. Once the new target slave receives and processes the command, it follows the normal slave response process, generating a response frame containing its own data and the next target slave address (which can be its own address plus 1) and sending it to the bus. This restarts the inspection chain from the new target slave, and subsequent slaves will continue to respond in a chain-like relay manner. After sending this new command frame, the host switches back to the receive state, awaiting a response from the new target slave, thus resuming normal passive listening mode. This step completes the entire fault recovery mechanism, ensuring that even if some slaves fail, the system can maintain normal inspections with functioning devices.

[0092] Continuing with the example from S2042, the master has generated a command frame addressed to 0x03. Now, the master sends this command frame to the bus. Slaves 0x01, 0x02, 0x03, and 0x04 will all receive this command frame. However, only slave 0x03 will detect that the "receive address" in the command frame is its own address (0x03). Slave 0x03 then processes the command, reads its own data, and constructs a response frame containing: Frame header S; Receiving address: 0x00 (host); Issue address: 0x03 (self); Slave target address: 0x04 (next slave after 0x03); Slave 0x03 sends this response frame onto the bus, including the command code, data information, checksum, and frame tail S. After the host receives the response from 0x03, the inspection chain starts from 0x03 and continues to 0x04, successfully bypassing the faulty 0x02 and ensuring the continuity of the inspection.

[0093] In some embodiments, after step S2041, the method further includes: S2044, determining whether the address of the new target slave exceeds the set maximum slave address; Specifically, when a host detects that a slave fails to respond and times out, it attempts to skip the failed slave and search for the next slave to be inspected as the new target slave. However, if the currently unresponsive slave is already the slave with the highest address on the bus (or, in other words, the last slave in the preset inspection range), the host's calculated address for the next slave to be inspected will exceed the system's maximum slave address range (for example, if the maximum slave address is 0x0F, the calculated result might be 0x10). When this happens, the host can clearly determine that the current inspection round, starting from the starting slave, has exhausted all possible slave addresses. Even if a slave fails to respond, this means that the inspection round has exhausted all known slaves and cannot continue. Therefore, the host marks the inspection round as complete. This mechanism effectively avoids indefinite waiting or invalid address calculations after the last slave is inspected due to a failure, ensuring the integrity and logical closure of the inspection cycle.

[0094] For example, suppose the system is configured to have a slave address range of 0x01 to 0x05, with the maximum slave address being 0x05. During a patrol cycle, the host starts at 0x01 and patrols sequentially through 0x04. Now it's the turn of slave 0x05 to respond, but for some reason, slave 0x05 fails to respond, and the host doesn't receive a response within a preset timeout. According to the logic in S2041, the host attempts to find the "next slave to be patrolled after 0x05." If the host's internal slave address list or patrol sequence indicates that 0x05 is the last slave, the calculated "next" address (for example, logically 0x06) would exceed the maximum configured slave address of 0x05. At this point, the host immediately determines that the patrol cycle has reached its end and that all slaves (or at least those up to 0x05) have been tried. Therefore, the host determines that the current patrol cycle has concluded and no longer attempts to send commands to 0x06, waiting for the next patrol cycle.

[0095] S2045: If the address of the new target slave exceeds the set maximum slave address, it is determined that the current round of inspection is completed, and when the next round of inspection cycle arrives, a new round of inspection command frame is generated according to the address of the starting slave.

[0096] This step describes how to smoothly transition from the end of one inspection cycle to the beginning of the next, thus achieving periodic and automated operation of inspections.

[0097] Once the host determines that the current round of inspections has concluded (whether all slaves have responded or the maximum address has been reached), it does not immediately begin a new inspection. Instead, the system enters a wait state, awaiting a preset trigger condition for the arrival of the next inspection cycle. This trigger condition can be a fixed interval (for example, inspections every 5 minutes) or an external event. When this trigger condition is met, the host resets its internal inspection state, resetting the inspection starting point to the address of the "starting slave" (usually the first slave on the bus, such as 0x01).

[0098] The host will then regenerate a standard inspection command frame based on the address of the "starting slave", with its "receive address" field pointing to the starting slave. The host will then send this newly generated command frame to the bus, thus starting a new round of slave inspection process.

[0099] This mechanism ensures that the system can regularly and comprehensively perform health checks and data collection on all slaves on the bus. Even if a faulty slave is encountered in the previous round of inspections, it can be retried in the new cycle, improving the robustness and maintainability of the system.

[0100] For example, continuing with the previous example, the host has determined that the current round of inspections has concluded after attempting slave 0x05. At this point, the host enters a wait state. Assume the system is configured to perform a full inspection every 10 minutes. When the 10-minute interval expires, the host initiates a new inspection round. It constructs a new inspection command frame based on the preset "starting slave" address (for example, 0x01). The "receiving address" of this command frame will be 0x01, the sending address will be the host itself, and information such as the command code will be filled in according to the standard format. After constructing this frame, the host sends this command frame to the bus. Upon receiving this command, slave 0x01 responds as it did initially and instructs the next slave (0x02) to respond.

[0101] In this way, a new, complete inspection cycle restarts from 0x01, and the system will try to traverse all slaves again, including slaves that may have failed in the previous round, thereby achieving continuous device status monitoring.

[0102] If it is determined that the address of the new target slave does not exceed the set maximum slave address, the host will generate a new inspection command frame according to the address of the new target slave and send it to the bus for it to receive and respond, thereby restoring the inspection chain.

[0103] In some implementations, the method of this embodiment may further include: S301, verify the current slave response data to obtain a data verification result.

[0104] This step ensures that the data sent by the slave has not been erroneously transmitted or tampered with. When the master (or, in chained polling, the previous slave) receives a response frame from the "current slave," it does not immediately trust and process the information contained within. Instead, it first performs an integrity check on the entire frame. This check is typically implemented using a checksum (such as a cyclic redundancy check (CRC) or an XOR checksum).

[0105] On the data transmitting end, the slave device calculates a checksum based on the data it is sending and appends it to the end of the data frame. On the data receiving end, the master device (or the next slave device) uses the same algorithm to recalculate a checksum based on the received data. The receiving end then compares its calculated checksum with the checksum extracted from the data frame. If the two match, the data transmission was error-free and the checksum is considered "correct." If they differ, the data may be corrupted and the checksum is considered "incorrect."

[0106] This verification process is automatic and fast. It can effectively filter out erroneous data caused by noise, interference or other transmission problems, thereby preventing the system from making judgments or performing operations based on inaccurate information, greatly improving the robustness of communications.

[0107] Suppose slave 0x02 has completed data acquisition and is preparing to send its response data (for example, a temperature value of 25.5°C) to the master. Before sending, slave 0x02 calculates a CRC checksum based on its data frame contents (including the frame header, address, and data). For example, the calculated result is 0xABCD. It then appends 0xABCD to the end of the data frame and transmits it. Upon receiving this data frame, the master first parses the data portion and the checksum 0xABCD appended by the slave. The master then independently performs a CRC calculation on the received data portion (for example, the temperature value of 25.5°C). If the master's calculated CRC result is also 0xABCD, then S301's checksum result is "correct," and the master continues to process the response data. However, if, due to electromagnetic interference on the bus, the temperature value in the data frame received by the master changes to 25.8°C, or the CRC checksum changes to 0xABCE, the master's recalculated CRC value will not match the received 0xABCD (or 0xABCE). At this time, the verification result of S301 is "error", indicating that the response data is unreliable and requires exception processing.

[0108] S302: If the data verification result is an error, a new inspection command frame is generated and sent to the bus, and the slave target address of the new inspection command frame is the next slave to be inspected after the current slave.

[0109] Specifically, if the master discovers that a slave's response data has failed verification, this means that while the slave may have sent a response, its content is unreliable, particularly the "slave target address" information contained therein may be incorrect. In this case, if the master continues to wait for or attempt to obtain a valid response from the slave, the inspection chain may be interrupted or enter an infinite loop.

[0110] To avoid this, this embodiment employs an active skip strategy: the host no longer waits for or re-requests the slave whose response data has failed verification. Instead, it immediately determines that the slave is "abnormal" or "untrusted." To maintain patrol continuity, the host directly skips the abnormal slave and determines the address of the "next slave to be patrolled after the abnormal slave" based on its internal slave address list or the preset patrol sequence. The host then proactively generates a new patrol command frame and sends the address of this "next slave to be patrolled" as the "receive address" of the new command frame to the bus.

[0111] In this way, the problem slave caused by data verification errors can be effectively bypassed, the inspection chain can be reactivated, and the inspection process can be ensured to continue, thereby improving the system's fault tolerance and inspection efficiency.

[0112] For example, continuing with the previous example, suppose the response data frame sent by slave 0x02 fails validation when received by the master. The master determines this response to be erroneous and cannot extract reliable "slave target address" information from it. In this case, the master does not wait for 0x02 to retransmit or attempt to retrieve data from 0x02. Instead, the master immediately determines, based on its internal list of slave addresses (e.g., 0x01, 0x02, 0x03, 0x04, 0x05), that the next slave to be inspected after 0x02 is 0x03. The master then generates a new inspection command frame with the "Receive Address" field set to 0x03, the "Outgoing Address" field still being the master itself (0x00), and the command code and other information remaining unchanged. The master then transmits this newly generated command frame onto the bus. Upon receiving this command, slave 0x03 recognizes that the command is addressed to itself and initiates its own response process, sending a response frame containing its own data and the address of the next slave (0x04). In this way, even if there is a problem with the response data of 0x02, the inspection chain can continue smoothly from 0x03, avoiding the interruption of the entire inspection process.

[0113] If the data verification result is correct, the host processes and stores the current slave response data, and waits for or continues to inspect the next slave response data based on the slave target address carried in the slave response data.

[0114] In some implementations, the method of this embodiment may further include: (1) Whenever the response data from the target slave is not received within the preset time, or the data verification result is an error, an abnormal situation is determined to have occurred, and the fault count is increased by 1.

[0115] This step identifies and quantifies two main communication failures: First, "no response due to timeout," which occurs when the master (or a slave responding according to the protocol) sends a command to a target slave but fails to receive any response data from the target slave within the preset waiting time. This typically means the target slave is disconnected, busy, or the command was not received correctly. Second, "data checksum error," which occurs when a response data is received from the target slave, but verification (such as CRC) reveals that the data has been corrupted or tampered with, making it unreliable.

[0116] In either case, it indicates a communication problem with the target slave. To distinguish between occasional interference and persistent faults, the master maintains a separate "fault counter" for each slave. Whenever any of these abnormal conditions is detected, the slave's fault counter increments by 1. This mechanism accumulates and reflects the frequency and persistence of communication problems with a specific slave, providing a quantitative basis for subsequent fault diagnosis and early warning.

[0117] By maintaining an independent fault count for each slave, the system can accurately track which slave has a problem, as well as the frequency and persistence of the problem, providing a quantitative basis for subsequent fault diagnosis and early warning.

[0118] (2) When the fault count reaches the set threshold, a fault warning is issued.

[0119] This step aims to convert accumulated communication anomaly information into actual fault warnings. Simply recording the number of failures is insufficient to guide operations; the master needs a mechanism to determine when these anomalies have accumulated to a level that requires attention. To this end, this embodiment sets a "failure count threshold" for each slave. This threshold is a pre-set value that represents the maximum number of communication anomalies that the system can tolerate for a specific slave before triggering a warning.

[0120] When a slave's fault counter reaches or exceeds this threshold, the master determines that the slave is no longer experiencing an occasional communication problem, but has experienced a persistent or serious failure. At this point, the master immediately triggers a "fault warning" and issues a clear warning to the operator or upper-level system through various means, including audible and visual alarms, interface prompts, logs, SMS or email notifications, indicating that the slave needs to be inspected or maintained.

[0121] This threshold-based warning mechanism avoids "false alarms" caused by instantaneous communication fluctuations, ensuring that warnings are triggered only when problems truly affect system stability, thereby improving the accuracy of warnings and system reliability.

[0122] The present embodiment is described below with reference to a specific application example: The system consists of one host with address 0x00 and four slaves with addresses 0x01, 0x02, 0x03 and 0x04, all of which are operating normally.

[0123] The host sends a patrol command C0, the data format of which is as described in step S2041, wherein the receiving address is 0x01.

[0124] Slaves 0x01, 0x02, 0x03, and 0x04 all receive inspection command C0 at the same time and analyze the C0 frame data respectively. Slave 0x01 meets the data judgment requirements and sends the response data C1 frame data after a delay, then clears the internal receive buffer. Slaves 0x02, 0x03, and 0x04 do not meet the C0 data judgment requirements, so they do not respond to the bus and clear the internal receive buffer. They remain in the receiving state, waiting to receive new data on the bus.

[0125] Data frame C1, sent to the bus by address 0x01, is received simultaneously by the master and slaves 0x02, 0x03, and 0x04. The master transfers the C1 frame data to the storage area corresponding to the send address 0x01, then clears the receive buffer and continues to wait for new bus data.

[0126] Slaves 0x02, 0x03, and 0x04 simultaneously receive data frame C1 sent to the bus by address 0x01. They perform data judgment on each slave. Only slave 0x02 meets the judgment requirements. Slave 0x02 automatically responds to the bus after a delay and sends data frame C2 to the bus. The other slaves 0x03 and 0x04 clear their internal receive buffers and wait to receive new data on the bus.

[0127] Data frame C2, sent to the bus by address 0x02, is received simultaneously by the master and slaves 0x01, 0x03, and 0x04. The master transfers the C2 frame data to the storage area corresponding to the send address 0x02, then clears the receive buffer and continues to wait for new bus data.

[0128] Slaves 0x01, 0x03, and 0x04 simultaneously receive data frame C2, which is sent to the bus by address 0x02. Each slave performs a data check, and only slave 0x03 meets the check criteria. After a delay, slave 0x03 automatically responds to the bus and sends data frame C3. The other slaves 0x01 and 0x04 clear their internal receive buffers and wait to receive new data from the bus.

[0129] Data frame C3, sent to the bus by address 0x03, is received simultaneously by the master and slaves 0x01, 0x02, and 0x04. The master transfers the C3 frame data to the storage area corresponding to the send address 0x03, then clears the receive buffer and continues to wait for new bus data.

[0130] Slaves 0x01, 0x02, and 0x04 simultaneously receive data frame C3, which is sent to the bus by address 0x03. Each slave performs a data check, and only slave 0x04 meets the check criteria. After a delay, slave 0x04 automatically responds to the bus and sends data frame C4. The other slaves 0x01 and 0x02 clear their internal receive buffers and wait to receive new data from the bus.

[0131] Data frame C4, sent to the bus at address 0x04, is received simultaneously by the master and slaves 0x01, 0x02, and 0x03. The master transfers the C4 frame data to the storage area corresponding to the send address 0x04, then clears the receive buffer and continues to wait for new bus data.

[0132] Slaves 0x01, 0x02, and 0x03 simultaneously receive data frame C4 sent to the bus by address 0x04, and perform data judgment respectively. If none of them meet the judgment requirements, they clear the internal receive buffer and wait for new data on the bus. In other words, no slave responds to the bus.

[0133] The host times out and does not receive the bus response data. Its internal JCQ register is already 0x04. It continues to increase by one. Because it exceeds the total capacity of the current slave, it is assigned a value of 0x01. The host resends a new round of inspection commands and repeats the previous description process.

[0134] After this round of inspection, the host only sent the inspection command once, that is, it received the response data from the slaves 0x01, 0x02, 0x03, and 0x04 in sequence, saving inspection time.

[0135] Taking a fire alarm system as an example, if the bus communication rate is 2400 bps, one byte takes 4 ms. If the master transmits an 8-byte frame, the master transmits one frame in 32 ms. If the slave responds with a 12-byte frame, the slave responds one frame in 48 ms. The master / slave transmit delay is 10 ms.

[0136] Assuming there are n slaves in the system and the master-question-slave-answer communication method is used, the time required for one inspection is: (32+10+48+10)*n (in milliseconds); The time required for one inspection using this patented method is 32+(10+48)*n (in ms) For example, if n=20, the time for one inspection is 2000ms using the master-question-slave-answer mode, while it is 1192ms using this patented method, saving up to 40.4% of the time.

[0137] For example, if n=40, the time for one inspection is 4000ms using the master-question-slave-answer mode, while it is 2352ms using this patented method, saving up to 41.2% of the time.

[0138] For example, if n=80, the time required for one inspection is 8000ms using the master-question-slave-answer mode, while it is 4672ms using this patented method, saving up to 41.6%.

[0139] Obviously, when the number of slaves increases, the advantages of the method of this embodiment become more prominent, and the specific time saved is related to the communication protocol.

[0140] This embodiment's method is applicable to systems operating in half-duplex communication mode and employing a master-question-slave-answer mechanism. This method can be used in both wired and wireless communication systems. Wired fire alarm systems, RS485 communication systems in industrial control, and point-to-point polling wireless communication systems can all employ this method to improve communication efficiency.

[0141] This embodiment also provides a method for implementing a predetermined time: Each time the host MCU serial port receives data, it initially sets a timer counter, T. The initial value of T depends on the communication frame length. Controlled by the host MCU's internal timer, timer counter T counts down with high timing accuracy. When the count reaches zero, an interrupt is triggered, indicating the end of the delay and thus achieving scheduled time control.

[0142] Specific control process: When the serial port interrupt receives each data, the timer counter T is initialized, and the time length of counter T is at least 4 times the interval between two serial port interrupts. When the serial port is receiving data normally, the timer T is continuously initialized, and no interruption of decrementing to zero is generated. When the slave is offline, that is, there is no data on the bus, the input end of the host serial port is in a static state. Then, when the last serial data interrupt is received, the counter T is initialized, and the subsequent counter T is decremented one by one. When it decrements to zero, an interrupt is triggered, indicating that no serial port data has been received during the period, that is, the predetermined delay time has passed, after which the host executes the corresponding program action.

[0143] The scheduled time should be 2 to 4 serial port intervals longer than the slave's delay sending time.

[0144] In this embodiment, the slave is divided into three states: The first type is the slave that sends data to the bus. Since the slave is in the sending state and will not receive the data it sends, it does not make any response and does not need to be analyzed.

[0145] The current target receiving slave determines that the frame header S, frame tail S, and check code are correct, and the target slave address received by this bus is equal to the slave's own address. After a certain delay, the slave switches the machine to the sending state, responds to the data to the bus, and then clears all the contents of the data receiving buffer, waiting to receive new data information on the bus.

[0146] The data format of the slave machine's response bus is as follows: only the "outgoing address" is modified to the slave machine address of the current response bus, and the "target address slave" is modified to its own address + 1.

[0147] Other slaves determine that the received target slave address is incorrect, do not respond, and clear all contents in the data buffer, waiting for the next bus to receive data.

[0148] The second type is the target receiving slave, that is, the slave pointed to by the slave target address in the response data sent this time, that is, the next slave to automatically respond.

[0149] If the target slave of this communication fails or is offline, then no slave meets the above judgment conditions and will not automatically continue to respond to the host, and the bus response will be in a "stop" state.

[0150] After a predetermined delay time, the host will resend the inspection command of the next slave address to trigger a new inspection process to ensure the continuity of bus inspection.

[0151] The third type is all other slaves except the above two states: These slaves are always in the receive state and receive all communication data on the bus. They perform basic integrity checks on the received data, such as verifying the frame header, frame trailer, and checksum. However, since the target receiving address in the data frame is neither their own address nor the target designated by the previous slave as the next automatic response target, they do not switch to the transmit state or perform any specific response actions. They simply continue to monitor the bus, waiting to be directly addressed by the master or designated as the next response target by the previous slave, and then proceed accordingly.

[0152] Among them, the reasons for the delayed response of the local address are: This delay allows the host to process the previous slave's response data and ensures that only one device on the bus is in the sending state at the same time to ensure bus stability. This delay can be set to 10ms, or at least 4 times the communication baud rate to ensure that the host has enough time to process data.

[0153] In some embodiments, reference Figure 6 , in the form of a timeline, intuitively shows the data transmission and reception timing and logical relationship between the host and multiple slaves (slave 0x01 to 0x04) on the bus. The legend clearly defines the meaning of each graphic element: the solid-line box represents the data sender, and the blank box in the same vertical column represents the receiver, which emphasizes the corresponding relationship between sending and receiving in bus communication. The dotted line connects the sender and the receiver, indicating that there is a causal relationship between them, that is, the sending behavior of one device triggers the reception or response of another device. It is particularly noteworthy that Figure 6 The open boxes in the row represent the delay in communication. The red open boxes specifically indicate the delay caused by the slave itself. The slash in the white box in the row where the master is located is used to indicate that the master has received data sent by the slave.

[0154] from Figure 6 As can be seen in the diagram, the master first issues a patrol command. After receiving the master's command, the slave device begins sending its own data after a certain delay (open frame). For example, after the master sends a data frame, slave 0x01 receives and processes it, then incurs a delay (red open frame) caused by itself before sending data. The data sent by this slave device (white frame with a slash) is received by the master. The master then waits for the next slave device's response.

[0155] This pattern repeats itself during the communication between slaves 0x02, 0x03, and 0x04. The entire timing diagram reveals the serial, one-by-one nature of bus communication and the inevitable delays in data transmission. It emphasizes that the master, as the bus leader, polls or sequentially interacts with slaves, and that each slave's response includes its own inherent processing delay. This sequential logic is crucial for understanding and optimizing bus communication performance, especially in systems with high real-time requirements.

[0156] Through the method of this embodiment, the host only needs to start the current round of inspection once. All slaves receive the host inspection command, and the corresponding slave responds to the host. All other slaves monitor the data on the current bus that responds to the host and automatically determine which slave needs to automatically respond to the bus. This constitutes a continuous automatic response mechanism, forming an automatic and orderly response. This achieves that when other slaves respond, there is no need for the host to query each time, but it ensures that only one device on the bus is sending data, avoiding data collisions on the bus, ensuring the stability of bus communication, saving host query time, and improving inspection efficiency.

[0157] For the slave, generally, its control logic is relatively small. With the current rapid development of microprocessor performance, the MCU resources are sufficient to undertake the additional task of monitoring the data sent to the bus by other slaves, and its processing logic is clear and simple.

[0158] For the host, the MCU resources required, such as the bus receive buffer and slave data storage buffer, remain unchanged. The bus receive data judgment logic remains unchanged, but the number of inspection commands required for each slave is reduced, significantly shortening the inspection cycle. This allows the host to quickly obtain relevant slave status and data, resulting in a more responsive host and significantly improved system control.

[0159] In some embodiments, for systems where all slaves are in a normal state, the aforementioned method can significantly improve inspection efficiency. However, as the system operates, more slaves may experience abnormalities. Although the aforementioned method still ensures the system's automatic inspection process, each time a missing slave is encountered, the host must restart the inspection process, which increases the inspection time. However, this method is still more efficient than the background solution.

[0160] The following discusses the improvement of the algorithm to achieve intelligent learning to compensate for the problem of longer inspection time caused by the missing slave address.

[0161] Each time a slave automatically responds to the bus, after sending its own data, it continues to monitor the bus for the next data frame. If the next data frame is sent by the master, this indicates that the data the slave automatically responded to was not delivered to its "target slave address." This means that the "target slave address" has not completed the automatic response to the bus, prompting the master to resend the inspection command. At this point, the slave automatically responding to the bus starts the communication failure counter for the "target slave address." When this counter accumulates n times, it confirms that the corresponding target slave has failed and cannot complete the automatic response communication. The slave then increments its internal "target slave address" by 1 (note: the target address has already been incremented by 1, so it is incremented again here), skipping the "target slave address" that did not respond to it. When the slave responds to the bus again, it directly points to the new "target slave address."

[0162] After multiple rounds of looping, the system reduces the need for the master to repeatedly send inspection commands due to missing slave addresses. This also ensures that slaves automatically and continuously respond, further reducing the inspection cycle and improving inspection efficiency. In a complete polling cycle, assuming the number of slaves is n, and the time it takes the master to send a single inspection command is t (including bus inactivity time), this embodiment's method can save (n-1) × t time compared to the traditional master-question-slave-answer model. The larger n, the more significant the effect. The system's existing communication hardware does not need to be modified; only the communication protocol needs to be changed.

[0163] Figure 7 The communication process between the master and slave and their state switching mechanism are demonstrated. The core is a polling-based communication model. Figure 7 Arrows of different colors represent different processes, and arrows of the same color represent the same process.

[0164] Specifically, Figure 7 In the figure, the red arrows indicate the process of the host initiating communication and sending patrol commands. It starts with the host system initialization, guides the host to send patrol commands, and passes these commands to the target slave on the bus or other slaves other than the host target, marking the beginning of the host's active addressing and initiation of data exchange.

[0165] The cyan arrows represent the exception handling process when the target slave does not respond or does not exist at all. In this case, the host recognizes the communication failure and enters a predetermined delay state. After that, it regenerates and sends a new poll command to skip the unresponsive slave and continue polling on the bus.

[0166] The green arrows depict the process of a slave responding normally and passing data to the master. This indicates that after the addressed slave successfully receives a command from the master, it responds and sends data to the master. It also includes the path for other slaves to become the target slaves and respond after being addressed. This is the key link in the data flow from slave to master.

[0167] The purple arrow indicates the host receiving data and completing the current communication cycle. It directs data from the slave to the host's receiving module. After the host successfully receives the data, control is returned to the host, forcing it to enter a predetermined delay phase in preparation for the next inspection command. This represents the host's response to the reception.

[0168] The blue arrow specifically indicates the process by which a slave switches roles (or identities) during communication. It bidirectionally connects the two states of "target slave" and "slave other than the slave's target," indicating that a slave becomes the target slave when addressed and responds by the master, and switches to another slave when it completes its task or is no longer addressed. This demonstrates the dynamic transition of slave roles to accommodate the master's polling mechanism.

[0169] An embodiment of the present invention further provides a bus communication inspection method based on a master-slave communication mode, which is applied to a slave device of the above system and specifically includes the following steps: S301 , when designated as a current patrol slave, receiving a patrol command frame from the host or response data from a previous slave, wherein the patrol command frame or the response data from the previous slave includes the address of the current patrol slave.

[0170] This step describes how a slave is "woken up" or "activated" to participate in the patrol. When a slave is designated as the current patrol slave, it receives a specific data packet via the bus. This data packet has two main forms: The first is a "patrol command frame" from the master. This typically occurs at the start of a patrol. The master (for example, address 0x00) generates a patrol command frame whose "receive address" field explicitly specifies the first slave to be patrolled (for example, address 0x01). When this command frame is sent to the bus, all connected slaves listen and interpret the data stream. Only when a slave recognizes that the "receive address" in the command frame matches its own address does it consider itself the current patrol slave and begin processing the command.

[0171] The second scenario involves receiving the "response data" from the previous slave. This is the core of this embodiment's chained inspection scheme. After the previous slave (e.g., slave A) completes its response, it includes the address of the next slave to be inspected (e.g., slave B) in its response data as the "slave target address." When slave A's response data is broadcast on the bus, slave B listens and recognizes that the "slave target address" in the response data is its own address. At this point, slave B knows it has become the designated slave for inspection and is then required to respond. This cycle repeats.

[0172] Regardless of the method, the slave device needs to have the ability to monitor bus data, parse protocols, and identify addresses to ensure that it can capture its own inspection instructions or chain trigger signals in a timely and accurate manner.

[0173] S302 : Based on the inspection command frame or the response data of the previous slave, and according to a preset inspection sequence, determine the address of the next slave to be inspected.

[0174] Specifically, once a slave successfully receives its own inspection command frame or the response data from the previous slave, it needs to extract necessary information from it and determine the next slave to be inspected based on its own preset logic.

[0175] If the slave receives a patrol command frame from the master (usually the first patrol), it searches for the slave address that follows it based on its internally stored preset patrol order list (for example, a slave list sorted in ascending order by address, or a slave group list with a specific function). For example, if the current slave is 0x01 and the preset order is 0x01, 0x02, 0x03..., it will determine that 0x02 is the next target.

[0176] If a slave receives a response from a previous slave, even though the response already includes the "slave target address," the current slave may still need to verify the validity of this address or use more complex logic (for example, skipping faulty slaves, adjusting the order based on priority, etc.) to ultimately determine the "next slave address to be inspected" in its response. This "preset inspection order" can be fixed at the factory, configured by the host during system initialization, or dynamically updated at runtime. The slave needs to have a corresponding internal storage unit to store this order information and an algorithm to find and locate the next address.

[0177] This process ensures the continuity and logic of the inspection, allowing the slave to autonomously guide the inspection chain without the need for frequent intervention and control by the host.

[0178] S303 , generating new slave response data according to the address of the next slave to be inspected, wherein the new slave response data includes the address of the currently inspected slave, the address of the host, and the address of the next slave to be inspected as the slave target address.

[0179] Specifically, after determining the "address of the next slave to be inspected," the current slave will begin to generate its own "slave response data." The slave response data is constructed in accordance with the specified format of the bus communication protocol, and it contains at least the following core information: First, the "address of the current inspected slave," which indicates who is responding, allowing the host to clearly know which slave is currently being polled. Second, the "address of the host," which ensures that the response data can be correctly transmitted back to the host that initiated the inspection. The most critical field is the "address of the next slave to be inspected as the slave target address." This field is the essence of this solution's chain inspection implementation. It explicitly informs the host of the next inspection target determined by the current slave, and indirectly notifies all slaves on the bus (especially the next target slave).

[0180] In addition to these address information, the response data usually also contains business data such as the current operating status of the slave itself, collected data, fault information, etc., which are necessary for the host to perform device management and status monitoring.

[0181] The communication module inside the slave will be responsible for encapsulating this information into data frames according to a specific protocol, and performing necessary checks and encoding to ensure the integrity and reliability of data transmission. This generation process is fast and automatic. Once the slave completes data collection and determines the next address, the response data will be immediately assembled and ready for the next step of transmission. S304: Send the new slave response data to the bus for reception by the host and the next slave to be inspected.

[0182] Specifically, the current slave sends this new slave response data onto the bus through its bus interface. This transmission process must adhere to the timing and rules of the bus protocol to ensure that data can be transmitted without conflicts. When the response data is sent to the bus, all devices on the bus, including the master and all other slaves, will listen and receive this data.

[0183] For the host, receiving this response data means that it has successfully completed the inspection of the current slave and learned the next slave to be inspected from the "slave target address" field in the response data. The host will then prepare for the next monitoring or command transmission (if necessary) based on this information.

[0184] For the next slave to be inspected (for example, slave B), when it monitors the bus, it will recognize that the "slave target address" in the response data is its own address. This is like receiving an implicit "it's your turn to respond" signal for slave B, triggering it to enter its own inspection response process (that is, returning to the first step of this method).

[0185] In this way, the current slave not only reports its status to the master, but more importantly, it acts as a "messenger," passing the inspection baton to the next slave. This chain transmission mechanism greatly simplifies the master's control logic, making the entire bus inspection process smoother, more efficient, and more adaptive.

[0186] The embodiments of the present invention employ the aforementioned method steps, describing a bus communication inspection method for the slave side, delegating some of the decision-making power and information transmission responsibilities within the inspection process to the slave. Upon receiving a command from the host or a response from the previous slave, the slave can autonomously determine and notify the address of the next slave to be inspected based on preset logic, and generate response data containing this information and send it to the bus. This design greatly simplifies the host's inspection management logic. The host no longer needs to maintain a complex slave list or a precise inspection sequence; it only needs to receive a slave response to learn the next inspection target, thereby reducing the host's computational and storage burdens.

[0187] This embodiment also enhances the scalability and adaptability of the bus communication system. When the number of slaves on the bus changes (for example, by adding or removing a slave), the entire inspection chain automatically adapts as long as the inspection sequence within the slaves is adjusted accordingly. This eliminates the need for large-scale modifications to the host software, achieving a "plug-and-play" experience.

[0188] Furthermore, chained information transmission between slaves reduces the need for the master to frequently send individual addressing commands, optimizes bus bandwidth utilization, and improves overall inspection efficiency. This slave-driven intelligent inspection model makes the system more flexible and robust, effectively enhancing the automation level and operational convenience of the bus communication system. The method provided in the above embodiment can be executed by a host or a slave, and both the host and the slave are composed of electronic devices. The following describes the electronic device in the embodiment of the present invention from the perspective of hardware processing. Figure 8 , which is a structural diagram of an electronic device in an embodiment of the present invention.

[0189] It should be noted that Figure 8 The structure of the electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present invention.

[0190] In this embodiment, the electronic device includes a processor and a memory; the memory is used to store computer program code, the computer program code includes computer instructions, and the processor calls the computer instructions to enable the electronic device to execute the method provided in the above embodiment.

[0191] Specifically, the processor can be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods and steps disclosed in the embodiments of this application by running computer instructions. A general-purpose processor can be a microprocessor or any conventional processor, etc. In conjunction with the steps of the methods disclosed in the embodiments of this application, the steps of these methods can be directly embodied as the hardware in the processor executing the steps of these methods, or the steps of these methods can be completed by a combination of hardware and software modules in the processor.

[0192] The memory may be a non-volatile memory, such as a hard disk (HD) or a solid-state drive (SSD), or a volatile memory, such as a random-access memory (RAM). The memory is a device that can be used to carry or store computer program code in the form of computer instructions or data structures. The memory in the embodiments of the present application may also be a circuit or any other device that can implement a storage function, for storing programs, instructions and / or data.

[0193] An embodiment of the present invention further provides a computer-readable storage medium on which computer instructions are stored. When the computer instructions are executed on an electronic device, the electronic device executes the method provided in the above embodiment.

[0194] The storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, a hard disk drive (HDD), and a solid state drive (SSD). The electronic device can call the computer instructions stored in the storage medium.

[0195] The methods provided in the embodiments of the present application may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, they may be implemented in whole or in part in the form of a computer program product.

[0196] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on an electronic device, the electronic device executes the method provided in the above embodiment.

[0197] In this embodiment, the computer instructions in the computer program product can be stored in a computer-readable storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video disc (DVD); or a semiconductor medium, such as an SSD.

[0198] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A bus communication inspection method based on a master-slave communication mode, characterized in that: A host applied to a bus communication system, the bus communication system further comprising a bus and a plurality of slaves, the host and the slaves being connected to the bus, the method comprising: determining a starting slave from the plurality of slaves; Generate a patrol command frame based on the address of the starting slave, the patrol command frame including a receiving address, an issuing address and a command code, wherein the receiving address in the patrol command frame is the address of the starting slave, and the issuing address is the address of the host; After sending the inspection command frame to the bus, monitoring the data transmitted on the bus to obtain the starting slave response data from the starting slave, wherein the receiving address of the starting slave response data is the address of the host, the sending address is the address of the starting slave, and the slave target address is the address of the next slave to be inspected; After receiving the starting slave response data, the data transmitted on the bus is continuously monitored to obtain the current slave response data from the current slave, the receiving address of the current slave response data is the address of the host, the sending address is the address of the current slave, and the slave target address is the address of the next target slave to be inspected after the current slave.

2. The method according to claim 1, characterized in that During the process of continuously monitoring the data transmitted on the bus, the method further includes: If the response data of the target slave is not received within the preset time, the next slave to be inspected after the target slave is determined as the new target slave; Generate a new inspection command frame according to the address of the new target slave; The new patrol command frame is sent to the bus, so that the new target slave receives and responds.

3. The method according to claim 2, characterized in that After determining the next slave to be inspected after the target slave as a new target slave if no response data from the target slave is received within the preset time, the method further includes: Determining whether the address of the new target slave exceeds the set maximum slave address; If so, it is determined that the current round of inspection is finished, and when the next round of inspection cycle arrives, a new round of inspection command frame is generated according to the address of the starting slave.

4. The method according to claim 1, wherein The method further comprises: Verifying the current slave response data to obtain a data verification result; If the data verification result is an error, a new inspection command frame is generated and sent to the bus, and the slave target address of the new inspection command frame is the next slave to be inspected after the current slave.

5. The method according to claim 4, characterized in that The method further comprises: Whenever the response data of the target slave is not received within the preset time, or the data verification result is an error, it is determined that an abnormal situation has occurred, and the fault count is increased by 1; When the fault count reaches a set threshold, a fault warning is issued.

6. The method according to any one of claims 1 to 5, characterized in that The inspection command frame specifically includes: a frame header, a receiving address, an issuing address, a command code, spare information, a check code and a frame tail; The response data of the slave device specifically includes a frame header, a receiving address, a sending address, a slave device target address, a command code, data information, a check code and a frame tail.

7. A bus communication inspection method based on a master-slave communication mode, characterized in that: A slave device used in a bus communication system, the bus communication system further comprising a host device and a bus, the slave device and the host device both being connected to the bus, the method comprising: When designated as the current patrol slave, receiving a patrol command frame from the host or response data from the previous slave, wherein the patrol command frame or the response data from the previous slave includes the address of the current patrol slave; Based on the inspection command frame or the response data of the previous slave, according to a preset inspection order, an address of the next slave to be inspected is determined; Generate new slave response data according to the address of the next slave to be inspected, the new slave response data including the address of the currently inspected slave, the address of the host, and the address of the next slave to be inspected as the slave target address; The new slave response data is sent to the bus for reception by the host and the next slave to be inspected.

8. An electronic device, characterized in that: including processor and memory; The memory is used to store computer program codes, where the computer program codes include computer instructions. The processor calls the computer instructions to enable the electronic device to execute the method according to any one of claims 1 to 7.

9. A computer-readable storage medium storing computer instructions, characterized in that: When the computer instructions are executed on an electronic device, the electronic device is caused to execute the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that When the computer program product is run on an electronic device, the electronic device is enabled to perform the method according to any one of claims 1 to 7.

Images