RTBus-based communication method, apparatus and device, and computer readable medium

Abstract

The invention relates to a communication method, device and equipment based on RTBus and a computer readable medium. The method comprises the following steps: after receiving a handshake signal sent by host equipment through an RTBus, slave equipment sends a communication confirmation signal to the host equipment; after receiving the communication confirmation signal, the host device sends a data frame containing GPIO state information and a first CRC check code to the slave device; the slave equipment extracts the corresponding GPIO state information and the check code after receiving the data frame, performs CRC check on the GPIO state information through the first CRC check code, and sends error prompt information to the host equipment if the check fails; and after receiving the error prompt information, the host device resends the data frame to the slave device through the RTBus until the CRC passes. The problems that a common GPIO can only send and cannot confirm that receiving is correct, data transmission is prone to being interfered, and a communication protocol is complex are solved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a communication method, device, equipment and computer-readable medium based on RT_Bus. Background Art

[0002] In the field of industrial equipment communication, signal transmission between devices is crucial. Traditionally, when GPIO (general input and output) signal communication is needed between two devices, it is often dependent on complex cable connections. There are a large number of these cables, and there are many problems in practical applications. For example, when the current involved in some GPIOs is large, such as the GPIO cables used to control solenoid valves, the cables themselves will be relatively thick. When many cables are close to each other, mutual interference is prone to occur, which may cause signal transmission errors and affect the normal operation of the equipment. In order to reduce this interference, it is often necessary to add shielding measures to GPIO cables with higher currents, which undoubtedly increases the cost and complexity of installation.

[0003] Existing real-time communication technology uses IP core to parse real-time signals, superimposes external GPIO signals on the RT_Bus IP core, and sends the signal from the master node to the slave node through the RT_Bus bus. Only two RT_Bus+ / - lines are needed to realize GPIO communication between two devices, which greatly reduces the wiring harness. However, this technology has certain limitations. RTBus (serial real-time bus) is different from the common MODBUSRTU industrial communication protocol. MODBUSRTU has strictly defined address fields, data fields, function codes, etc., and each bit has a clear meaning. RTBus only requires the sending and receiving ends to agree on the definition of each bit, which increases the complexity of configuration and potential error risks to a certain extent. Although RTBus can ensure mutual monitoring and transmission accuracy of devices at both ends to a certain extent by jumping the heartbeat bit once per frame, and superimposing all GPIO signals on the RT_Bus IP (sending) core, sending them to the RT_Bus IP (receiving) core via the bus and parsing them into normal GPIO signals, it still has shortcomings compared with the solution proposed in this patent. Ordinary GPIO can only send but cannot confirm correct reception, data transmission is susceptible to interference, and the communication protocol is complex and lacks a mechanism to ensure data accuracy.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The present application provides a communication method based on RT_Bus to solve the above-mentioned technical problems of "ordinary GPIO can only send but cannot confirm correct reception, data transmission is susceptible to interference, and the communication protocol is complex and lacks a mechanism to ensure data accuracy".

[0006] According to one aspect of an embodiment of the present application, the present application provides a communication method based on RT_Bus, including: after the slave device receives a handshake signal sent by the host device through the RT_Bus bus, the slave device sends a communication confirmation signal to the host device; after the host device receives the communication confirmation signal, it sends a data frame containing GPIO status information and a first CRC check code to the slave device; after the slave device receives the data frame, it extracts the corresponding GPIO status information and the check code, performs a CRC check on the GPIO status information through the first CRC check code, and sends an error prompt message to the host device if the check fails; after receiving the error prompt message, the host device resends the data frame to the slave device through the RT_Bus bus until the CRC check passes.

[0007] Optionally, before the slave device receives the handshake signal sent by the host device through the RT_Bus bus, it also includes: determining the communication connection mode between the host device and the slave device according to the RT_Bus bus specification; configuring the RT_Bus bus interface of the host device and the slave device according to the communication connection mode; writing the driver program and communication protocol stack between the host device and the slave device in the RT_Bus bus interface; initializing the host signal processing module of the host device and the slave signal processing module of the slave device, and loading the RT_BusIP core in the host signal processing module and the slave signal processing module; the host device generates a handshake signal through the host signal processing module and sends the handshake signal to the slave signal processing module of the slave device through the RT_Bus bus.

[0008] Optionally, after the slave device receives the handshake signal sent by the host device via the RT_Bus bus, it sends a communication confirmation signal to the host device, including: after the slave device receives the handshake signal sent by the host device, it obtains the host identity based on the handshake signal, compares the host identity with a preset identity, and sends an invalid identity message to the host device if the host identity is invalid; the slave device compares the communication protocol of the handshake signal with a preset communication protocol, and sends a communication failure signal to the host device if the communication protocol is invalid, and sends a communication confirmation signal to the host device if the communication protocol is valid.

[0009] Optionally, after receiving the communication confirmation signal, the host device sends a data frame including GPIO status information and a first CRC check code to the slave device, including: the host device collects the GPIO status information of the GPIO pin through a host signal processing module; generates a first CRC check code for the GPIO status information through a CRC algorithm; generates a data frame based on the GPIO status information and the corresponding first CRC check code; and the host signal processing module of the host device sends the data frame to the slave signal processing module of the slave device through the RT_Bus bus.

[0010] Optionally, before the host signal processing module of the host device sends the data frame to the slave signal processing module of the slave device through the RT_Bus bus, it also includes: the host device generates a status synchronization signal for detecting whether the communication between the host device and the slave device is normal; the status synchronization signal is added at a preset position of the data frame, and the status synchronization signal is provided with a signal transmission clock of the host device and the slave device.

[0011] Optionally, after receiving the data frame, the slave device extracts the corresponding GPIO status information and the check code, performs CRC check on the GPIO status information through the first CRC check code, and sends an error prompt message to the host device if the check fails, including: after receiving the data frame, the slave device parses it to extract the GPIO status information, the first CRC check code and the status synchronization signal; the slave device generates a second CRC check code corresponding to the GPIO status information through a CRC algorithm; the second CRC check code is compared with the first CRC check code, if the second CRC check code is the same as the first CRC check code, the CRC check passes; if the second CRC check code is different from the first CRC check code, the CRC check fails, and the slave device generates an error prompt message and sends it to the host device through the RT_Bus bus; the slave device determines whether the communication between the slave device and the host device is normal according to the status synchronization signal, and if not, sends a communication abnormality signal to the host device; the host device adjusts the status synchronization signal after receiving the communication abnormality signal.

[0012] Optionally, after receiving the error prompt information, the host device resends the data frame to the slave device through the RT_Bus bus until the CRC check passes, including: the host device parses the error prompt information sent by the slave device to obtain the error type and the error cause; the host device re-collects the GPIO status information through the host signal processing module, and generates a CRC check code corresponding to the GPIO status information based on the CRC algorithm; the data frame is updated based on the GPIO status information and the CRC check code, and the updated data frame is sent to the slave signal processing module of the slave device through the RT_Bus bus; the slave signal processing module of the slave device extracts the GPIO status information and the CRC check code based on the data frame, and performs CRC check on the GPIO status information based on the CRC check code; and iteratively executes the above steps until the CRC check passes.

[0013] According to another aspect of an embodiment of the present application, the present application provides a communication device based on RT_Bus, including: a communication establishment module, which is used for sending a communication confirmation signal to the host device after the slave device receives a handshake signal sent by the host device through the RT_Bus bus; a data sending module, which is used for sending a data frame including GPIO status information and a first CRC check code to the slave device after the host device receives the communication confirmation signal; a data check module, which is used for extracting the corresponding GPIO status information and the check code after the slave device receives the data frame, performing CRC check on the GPIO status information through the first CRC check code, and sending an error prompt message to the host device if the check fails; a data retransmission module, which is used for resending the data frame to the slave device through the RT_Bus bus after the host device receives the error prompt message until the CRC check passes.

[0014] According to another aspect of an embodiment of the present application, the present application provides an electronic device, including a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, the memory and the processor communicate through the communication bus and the communication interface, and the processor implements the steps of the above-mentioned RT_Bus-based communication method when executing the computer program.

[0015] According to another aspect of the embodiment of the present application, the present application further provides a computer-readable medium having a non-volatile program code executable by a processor, wherein the program code enables the processor to execute the above-mentioned communication method based on RT_Bus.

[0016] The above technical solution provided by the embodiment of the present application has the following advantages compared with the related art:

[0017] This application can ensure that a reliable connection has been successfully established between the host and the slave before starting data transmission by sending a communication confirmation signal to the host device after receiving the handshake signal of the host device, effectively avoiding data loss or transmission errors caused by unstable connection, and laying a solid foundation for subsequent information interaction. The first CRC check code is included in the data frame, and the slave device uses the check code to perform CRC check on the GPIO status information, which can accurately detect whether the data is wrong during the transmission process. The CRC check algorithm has a strong error detection capability and can detect common error types such as multi-bit errors and burst errors in the data frame, thereby ensuring the accuracy of the GPIO status information received by the slave device. When the check fails, the slave device sends an error prompt message to the host device, and the host device resends the data frame until the CRC check passes. This feedback and retransmission mechanism forms a closed-loop error correction system. It ensures that the data can be received by the slave device in the correct form, thereby ensuring the reliability of data transmission of the entire communication system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1 A schematic diagram of a hardware environment of a communication method based on RT_Bus provided according to an embodiment of the present application;

[0021] Figure 2 A flow chart of a communication method based on RT_Bus provided according to an embodiment of the present application;

[0022] Figure 3 A communication principle diagram of a communication method based on RT_Bus provided according to an embodiment of the present application;

[0023] Figure 4 A structural block diagram of a communication device based on RT_Bus provided according to an embodiment of the present application;

[0024] Figure 5 A schematic diagram of an optional electronic device structure provided in an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0026] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application and have no specific meaning. Therefore, "module" and "component" can be used interchangeably.

[0027] In the related technology, ordinary GPIO can only send but cannot confirm correct reception, data transmission is susceptible to interference, and the communication protocol is complex and lacks a mechanism to ensure data accuracy.

[0028] In order to solve the problem mentioned in the background technology, according to one aspect of an embodiment of the present application, an embodiment of a communication method based on RT_Bus is provided.

[0029] Optionally, in the embodiment of the present application, the above method can be applied to Figure 1 In the hardware environment composed of the terminal 101 and the server 103 shown in FIG. Figure 1 As shown, the server 103 is connected to the terminal 101 via a network, and can be used to provide services for the terminal or a client installed on the terminal. A database 105 can be set on the server or independently of the server to provide data storage services for the server 103. The above-mentioned network includes but is not limited to: a wide area network, a metropolitan area network or a local area network, and the terminal 101 includes but is not limited to a PC, a mobile phone, a tablet computer, etc.

[0030] In the embodiment of the present application, a communication method based on RT_Bus can be executed by the server 103, or can be executed by the server 103 and the terminal 101 together, such as Figure 2 As shown, the method may include the following steps:

[0031] Step S202, after receiving the handshake signal sent by the host device via the RT_Bus bus, the slave device sends a communication confirmation signal to the host device;

[0032] Optionally, before the slave device receives the handshake signal sent by the host device through the RT_Bus bus, the following steps are further included:

[0033] Determine the communication connection method between the host device and the slave device according to the RT_Bus bus specification;

[0034] Configure the RT_Bus bus interface of the host device and the slave device according to the communication connection mode;

[0035] Write the driver and communication protocol stack between the host device and the slave device in the RT_Bus bus interface;

[0036] Initialize the host signal processing module of the host device and the slave signal processing module of the slave device, and load the RT_BusIP core in the host signal processing module and the slave signal processing module;

[0037] The host device generates a handshake signal through the host signal processing module and sends the handshake signal to the slave signal processing module of the slave device through the RT_Bus bus.

[0038] It can be understood that the present embodiment mainly realizes the communication between the host device (Master) and the slave device (Slave) through the RT_Bus bus. The present embodiment first determines the communication connection mode between the host device and the slave device according to the RT_Bus bus specification, wherein the host device is responsible for initiating the communication and data transmission scheduling, and the slave device mainly receives and responds to data. For the RT_Bus bus interface of the host device, its electrical parameters are set according to the RT_Bus bus specification, such as the voltage range is 3.3V, the data transmission rate is set to 10Mbps, etc. At the same time, a suitable transceiver chip is configured in the interface circuit to realize the level conversion of the signal and enhance the driving capability. For the interface of the slave device, corresponding electrical parameter matching and transceiver configuration are also performed to ensure that the two can be connected and communicated normally at the physical layer. A driver is written in the RT_Bus bus interface of the host device, and the driver is responsible for controlling the initialization of the bus interface, the sending and receiving operations of data, interrupt processing and other functions. For example, when the host device has data to send, the driver packages the data in a predetermined format and controls the sending pin of the bus interface to send the data to the RT_Bus. At the same time, write a communication protocol stack and define the structure of the data frame. For example, the frame header is a specific byte sequence (such as 0xAB), indicating the beginning of the data frame; the frame tail is 0xCD, which is used to mark the end of the data frame. Specific fields are reserved in the data frame for placing GPIO (general input and output) status information, device address, command code and other contents. And the data verification method is specified, such as using the CRC-16 algorithm for data verification, and placing the calculated CRC check code in the check field of the data frame. Write the corresponding driver and communication protocol stack in the RT_Bus bus interface of the slave device. The driver of the slave device is mainly responsible for monitoring the RT_Bus bus. When a data frame arrives, it triggers an interrupt and receives data. The communication protocol stack is responsible for parsing the received data frame, extracting the GPIO status information, judging the correctness of the data (through CRC verification), and other operations. Initialize the host signal processing module of the host device and set its internal cache size to 1024 bytes for temporarily storing the data to be sent. At the same time, the RT_Bus IP core is loaded in the host signal processing module. The IP core realizes the efficient processing function of the RT_Bus bus data through programming configuration, such as data packaging, unpacking, CRC calculation, etc. The slave signal processing module of the slave device is initialized similarly, and the cache size is set to 512 bytes to meet its data reception and processing requirements. The RT_Bus IP core is loaded in the slave signal processing module and configured to the data reception and parsing mode, which can accurately extract the GPIO status information from the received data frame and perform corresponding processing. The host signal processing module of the host device generates a handshake signal according to the communication protocol.The data frame structure of the handshake signal contains information such as the host device's identity (such as the device number 0x01), the handshake command code (such as 0x0A), etc. Then, the handshake signal is sent to the slave signal processing module of the slave device through the RT_Bus bus. After receiving the handshake signal, the slave device parses the host identity and command code in the handshake signal according to the communication protocol to determine whether it is legal. If it is legal, the subsequent communication preparation work is carried out; if it is illegal, the identity invalid information is sent to the host device to notify the host device to check its identity settings or communication link.

[0039] refer to Figure 3 As shown, the host signal processing module and the slave signal processing module of this embodiment use FPGA, wherein the host signal processing module corresponds to FPGA1, and the slave signal processing module corresponds to FPGA2. At the FPGA1 / Master end, it includes a first emergency button, a valve opening signal, and a clutch opening signal, and at the FPGA2 / lave end, it includes a second emergency button, a reset button, and a workbench movement signal. FPGA1 / Master and FPGA2 / Slave are connected via the RT-Bus bus, specifically including a signal line RTL+ and a signal line RTL-, which are used to transmit data and control signals. In the specific implementation process, first follow Figure 3 The architecture in the FPGA is used to build hardware circuits and cable connections. Then, an IP core is created to handle communication on the RT-Bus. Then the GPIO status is sampled and entered into FPGA1. The GPIO status includes the first emergency button, valve opening signal, and clutch opening signal. FPGA1 superimposes these states on the RT-Bus through the IP core. The host device first sends a handshake signal, and the slave device receives the handshake signal to ensure the synchronization of communication between the master and slave devices. Finally, the RT-Bus is read separately through the Master / Slave IP core, each bit is parsed, and a CRC check is performed.

[0040] In the above implementation, by determining the communication connection mode according to the RT_Bus bus specification, and configuring the RT_Bus bus interface of the host device and the slave device in a targeted manner, the accuracy and efficiency of the connection between the devices are ensured. It enables the host and slave devices of different types and different functional requirements to smoothly establish a stable communication link on the RT_Bus bus, reducing the problems of connection failure or communication instability caused by improper connection configuration, and improving the compatibility and scalability of the system. For example, in a composite operating room environment containing a variety of medical devices, devices produced by different manufacturers can be configured for RT_Bus connection according to this standardized process to achieve interconnection between devices. By writing the driver and communication protocol stack between the host and the slave, the communication compatibility and functional integrity between the devices are enhanced. The driver can accurately control the operation of the hardware device (such as the RT_Bus bus interface) to make the data transmission between different devices smoother; the communication protocol stack defines the rules and formats of data transmission, ensuring that the host and slave devices can accurately understand and process the data sent to each other, which helps to reduce data transmission errors and improve the reliability of communication. Initialize the signal processing modules of the host and slave and load the RT_BusIP core. The RT_BusIP core can realize fast processing of RT_Bus bus data at the hardware level, such as data superposition, analysis and CRC verification, which improves the data processing speed and reduces the data processing delay, so that the device can respond to the other party's state changes and control instructions in time. For example, in the communication between medical devices, the transmission and processing of key status information such as whether the device is in the Home position and whether the Clutch is released can be faster, which improves the operating efficiency and safety of the entire medical system. The host generates a handshake signal through the host signal processing module and sends it to the slave signal processing module of the slave device. The handshake signal is the key starting link for establishing communication between devices, which improves the success rate and stability of establishing communication between devices, thereby ensuring the reliable operation of the entire RT_Bus bus communication system.

[0041] Optionally, after receiving the handshake signal sent by the host device through the RT_Bus bus, the slave device sends a communication confirmation signal to the host device, including:

[0042] After receiving the handshake signal sent by the host device, the slave device obtains the host identity based on the handshake signal, compares the host identity with the preset identity, and sends an invalid identity information to the host device if the host identity is invalid;

[0043] The slave device compares the communication protocol of the handshake signal with the preset communication protocol, and sends a communication failure signal to the host device if the communication protocol is invalid, and sends a communication confirmation signal to the host device if the communication protocol is valid.

[0044] In this embodiment, when the slave device receives the handshake signal sent by the host device via the RT_Bus bus, it first extracts the host identity from the data frame of the handshake signal. For example, the host device identity is set to a specific 16-bit binary code:

[0045] "0101101011001110". The intelligent terminal compares the extracted host identity with the preset identity list stored in itself. If no matching identity is found in the preset identity list, it means that the host identity is invalid, and the slave device immediately sends an invalid identity information to the host device through the RT_Bus bus. The information format can be a specific error code data frame, such as "0xFF01" indicates an identity error, so that the host device can check and process it. If the host identity verification is successful, the slave device then compares the communication protocol of the handshake signal with the preset communication protocol. The preset communication protocol specifies the data frame format of the handshake signal, the meaning of the data bit, the verification method, etc. For example, the frame header of the handshake signal is specified as "0x55AA", the frame tail is "0xAA55", the first 8 bits of the data field indicate the host type, and the last 8 bits indicate the communication version number, etc. The slave device checks the received handshake signal according to these regulations. If it is found that the format of the frame header, frame tail or data field of the handshake signal does not match the preset communication protocol, such as the frame header becomes "0x55AB", the communication protocol is determined to be invalid, and the slave device sends a communication failure signal to the host device, such as sending a data frame "0xFF02" to indicate a communication protocol error. If the communication protocol of the handshake signal completely matches the preset communication protocol, it means that the communication protocol is valid, and the slave device sends a communication confirmation signal to the host device, such as sending a specific data frame "0x0001" to indicate communication confirmation. After the host device receives the communication confirmation signal, it knows that the handshake process with the slave device has been successfully completed, and formal data transmission and interactive operations can be carried out subsequently. For example, the host device sends a data acquisition instruction to the slave device, and the slave device collects field data according to the instruction and sends the data back to the main controller through the RT_Bus bus. During the data transmission process, CRC checks and other operations are also performed to ensure the accuracy of the data.

[0046] In the above implementation, by verifying the host identity, the slave device can effectively prevent illegal devices from accessing the communication link. In a complex multi-device interconnected environment, such as an industrial automation production line or an intelligent medical system, there may be multiple devices from different sources trying to connect to the RT-Bus bus. Only when the identity of the host device matches the preset legal identity, further communication is allowed. The risk of malicious devices disguising themselves as legal hosts to steal data, tamper with or destroy system operation is greatly reduced, and the security and integrity of the entire system data are guaranteed. Verification of the communication protocol ensures that both parties in communication exchange data under the same rules. If the communication protocol does not match, it may cause data transmission errors, confusion in information interpretation, and other problems, and in severe cases, the entire system will fall into a fault state. The slave device strictly checks the consistency of the communication protocol of the handshake signal with the preset communication protocol, promptly discovers and rejects connection attempts due to protocol mismatches, avoids communication failures caused by inconsistent protocols, and thus improves the reliability and stability of communication. Accurate host identity identification and effective communication protocol verification lay a solid foundation for subsequent data transmission. When the slave device confirms that the host identity is valid and the communication protocol is correct, the two parties can accurately exchange data according to the predetermined specifications. For example, when transmitting key patient physiological data or device status information between medical devices, only when communication is accurate can the correctness of medical decisions and the effectiveness of device collaboration be guaranteed, reducing serious consequences such as misdiagnosis or device misoperation caused by erroneous data. The slave device promptly feeds back invalid identity information or communication failure signals to the host device, which helps the host device quickly know the connection problem and take corresponding measures. The host device can perform self-checks based on the feedback information, such as checking whether its own identity setting is incorrect or adjusting the communication protocol parameters, thereby improving the error correction capability and adaptability of the entire communication system, ensuring that the communication link can resume normal working conditions as soon as possible, and reducing system downtime caused by communication failures.

[0047] Step S204, after receiving the communication confirmation signal, the host device sends a data frame including GPIO status information and a first CRC check code to the slave device;

[0048] Optionally, after receiving the communication confirmation signal, the host device sends a data frame including GPIO status information and a first CRC check code to the slave device, including:

[0049] The host device collects GPIO status information of the GPIO pin through the host signal processing module;

[0050] Generate a first CRC check code of the GPIO status information by using a CRC algorithm;

[0051] Generate a data frame based on the GPIO state information and a corresponding first CRC check code;

[0052] The host signal processing module of the host device sends the data frame to the slave signal processing module of the slave device through the RT_Bus bus.

[0053] In this embodiment, taking the composite surgical laboratory scenario as an example, the PET (positron emission tomography) device is used as the host device, and the CT (computed tomography) device is used as the slave device. The two are connected through the RT_Bus bus to realize real-time interaction and collaborative work of key status information, and ensure accurate monitoring and coordination of the operating status of the equipment during the operation. The host signal processing module (FPGA1) of the PET device starts the information collection process. For the detection of whether the Home position is completed, a special GPIO pin is connected to the corresponding position sensor. When the device is in the Home position after the initial calibration is completed, the GPIO pin is low (indicated as 0), and if it is not in the Home position, it is high (indicated as 1). For example, at this time, it is detected that the PET device is in the Home position, and the corresponding GPIO status information is recorded as 0. For whether the Clutch is released, there is a corresponding GPIO line connected to the clutch state detection device. If the clutch is released, the GPIO is high (indicated as 1), and if it is not released, it is low (indicated as 0). Assuming that the current clutch is in the released state, this GPIO information is recorded as 1. In addition, for whether it is an Emergency, there is an emergency button connected to the GPIO, which is high level (indicated as 1) in normal state, and becomes low level (indicated as 0) if the emergency button is pressed. At this time, the emergency is not triggered, and the GPIO state is 1. There is also a GPIO detection for Reset. When the device is not in the reset process, it is high level (indicated as 1). Assuming that the current PET device is not in reset, its corresponding GPIO state is 1. The host signal processing module of the PET device collects and temporarily stores these GPIO state information about whether the Home position (0), whether the Clutch is released (1), whether it is Emergency (1), and whether it is Reset (1). The host signal processing module uses the CRC-8 algorithm to calculate the collected GPIO state information (0111) of the above PET device to generate a first CRC check code. After the algorithm operation, an 8-bit CRC check code is obtained, which is assumed to be 0x56. Based on these GPIO state information and the corresponding first CRC check code, the host signal processing module constructs a data frame. The header of the data frame is set to a specific identifier 0xAA55, indicating the start of the data frame. In the data domain, the GPIO status information of the PET device is written in a predetermined order, that is, the Home bit status (0) is written first, followed by the Clutch release status (1), the Emergency status (1), and the Reset status (1). Then the generated first CRC check code 0x56 is placed in the check area of ​​the data frame. Finally, a specific end mark 0x55AA is added to the end of the data frame. The host signal processing module of the PET device sends the complete data frame to the slave signal processing module of the CT device through the RT_Bus bus.After receiving the data frame, the CT device extracts the status information of the PET device and performs a CRC check to determine the accuracy and completeness of the information, thereby adjusting its own working mode or performing operations such as status display based on this information. For example, if it is known that the PET device is in the Home position and there is no emergency, the CT device can optimize the image acquisition parameters accordingly to match the current status of the PET device, or display the status information of the PET device on the operation interface for the surgeon's reference.

[0054] In the above implementation, the first CRC check code of the GPIO status information is generated by the CRC algorithm, and it is encapsulated in the data frame together with the GPIO status information and sent, which provides a strong guarantee for the integrity of the data during the transmission process. The CRC check code is a kind of redundant information generated according to a specific algorithm based on the data content. After the slave device receives the data frame, the check code can be recalculated for the received GPIO status information by the same CRC algorithm, and compared with the received first CRC check code. If the two are consistent, it indicates to a great extent that the data has not been erroneous or tampered with during the transmission process, ensuring that the GPIO status information obtained by the slave device is complete and accurate, and can effectively avoid serious consequences such as erroneous control instructions or misdiagnosis caused by data errors. The data integrity verification mechanism based on CRC can detect various types of data transmission errors, including data bit flipping, data loss or additional data insertion. For example, in an environment with electromagnetic interference, data may be affected when transmitted on the RT-Bus bus, resulting in changes in individual data bits. The CRC check can keenly capture this change, promptly detect data errors and notify related devices for processing, thereby improving the adaptability of the entire communication system to complex environments and the reliability of data transmission. The host device collects the status information of the GPIO pins and generates a data frame through the host signal processing module. The host signal processing module can efficiently coordinate the acquisition of GPIO data and the construction of data frames, reducing delays and resource waste in the data processing process. For example, in a high-speed data acquisition system, the status information of multiple GPIO pins can be quickly integrated into a data frame and sent out to meet the system's real-time requirements. The data frame is generated based on clear GPIO status information and the corresponding CRC check code, so that the structure of the data frame is standardized and easy to parse. After receiving the data frame, the slave device can quickly extract the GPIO status information and perform a CRC check according to the predetermined format and rules, thereby improving the efficiency of data processing.

[0055] Optionally, before the host signal processing module of the host device sends the data frame to the slave signal processing module of the slave device through the RT_Bus, it also includes:

[0056] The host device generates a status synchronization signal for detecting whether the communication between the host device and the slave device is normal;

[0057] A state synchronization signal is added at a preset position of the data frame, and the state synchronization signal is provided with a signal transmission clock of the host device and the slave device.

[0058] In this embodiment, the host signal processing module of the PET device is responsible for generating a state synchronization signal (heartbeat bit). First, the initial state of the heartbeat bit is determined, assuming that it is set to 0. Then the jump period of the heartbeat bit is set, for example, it jumps once every 5 milliseconds. In the process of generating the heartbeat bit, the signal transmission clock information of the host device (PET) and the slave device (CT) is embedded at the same time. Assuming that the signal transmission clock frequency agreed by both parties is 2MHz, the host device integrates the clock frequency information into the generation logic of the heartbeat bit according to a specific encoding rule. For example, the high level duration and low level duration of the heartbeat bit are accurately set according to the 2MHz clock frequency to transmit the clock information. The host signal processing module collects GPIO information about the status of its own device. For example, it is detected that the PET device is in the Home position (corresponding to the GPIO state of 0), the Clutch has been released (corresponding to the GPIO state of 1), there is no Emergency situation (corresponding to the GPIO state of 1), and it is not in the Reset state (corresponding to the GPIO state of 1). Then, the CRC check code of these GPIO state information is generated by the CRC algorithm (such as CRC-8), and it is assumed that the obtained check code is 0x23. When constructing a data frame, according to the RT_Bus bus communication protocol, a specific frame header identifier, such as 0x1234, is set at the beginning of the data frame. Then, each GPIO status information is written in sequence at the predetermined data field position, namely, the Home bit (0), Clutch release status (1), Emergency status (1), and Reset status (1). A heartbeat bit is added to the 8th bit (preset position) of the data frame. If the heartbeat bit is 0 at this time, 0 is written to this bit. Finally, the CRC check code 0x23 is placed in the check area of ​​the data frame, and a specific frame tail identifier, such as 0x4321, is added to the end of the data frame. The host signal processing module of the PET device sends the constructed data frame to the slave signal processing module of the CT device through the RT_Bus bus. After receiving the data frame, the CT device first extracts the heartbeat bit and adjusts its own receiving clock according to the clock information in the heartbeat bit to ensure synchronization with the PET device. For example, the 2MHz clock frequency information is parsed from the level change period of the heartbeat bit, and then its own receiving clock is adjusted to match it. Then the slave device parses the GPIO status information in the data frame and performs a CRC check. If the CRC check passes and the heartbeat bit continues to jump normally (once every 5 milliseconds), the CT device confirms that the data is received normally and performs corresponding operations based on the status information of the PET device, such as adjusting its own image acquisition parameters or displaying the PET device status on the operation interface. If the CT device detects abnormal jumps in the heartbeat bit, such as no change for multiple consecutive cycles or the jump cycle significantly deviates from 5 milliseconds, or the CRC check fails, the CT device determines that there is a problem with the communication with the PET device.At this time, the CT device sends a communication abnormality signal to the PET device. After receiving the signal, the PET device checks its own signal processing module, clock circuit, RT_Bus bus interface and other components according to the pre-set troubleshooting strategy, and adjusts the relevant parameters of the heartbeat bit, such as slightly changing the heartbeat bit's jump period or signal strength, in an attempt to re-establish a stable communication connection to ensure the reliability and stability of communication between devices during surgery.

[0059] In the above implementation, accurate synchronization between the host device and the slave device is ensured by using a unified clock reference. In the data transmission process, both devices can accurately interpret various types of information in the data frame based on the clock information in the synchronization signal, effectively avoiding data reading errors or misalignment caused by clock differences. At the same time, it helps the slave device to clearly determine the start and end positions of the data frame and the valid interval of the data based on the preset clock signal and format, so as to carry out data parsing and processing work in an orderly manner, greatly enhancing the stability and reliability of data transmission. The state synchronization signal can reflect the communication connection status between the host device and the slave device in real time and continuously. The slave device can timely and accurately determine whether the connection with the host device is normal by detecting its regularity and integrity. Once the state synchronization signal appears such as interruption, abnormal jump or delay, the slave device can quickly detect and determine that there is a problem with the communication link.

[0060] Step S206, after receiving the data frame, the slave device extracts the corresponding GPIO status information and the check code, performs a CRC check on the GPIO status information using the first CRC check code, and sends an error prompt message to the host device if the check fails;

[0061] Optionally, after receiving the data frame, the slave device extracts the corresponding GPIO status information and the check code, performs a CRC check on the GPIO status information using a first CRC check code, and sends an error prompt message to the host device if the check fails, including:

[0062] After receiving the data frame, the slave device parses it to extract the GPIO state information, the first CRC check code and the state synchronization signal;

[0063] The slave device generates a second CRC check code corresponding to the GPIO status information through a CRC algorithm;

[0064] The second CRC check code is compared with the first CRC check code. If the second CRC check code is the same as the first CRC check code, the CRC check passes; if the second CRC check code is different from the first CRC check code, the CRC check fails, and the slave device generates an error prompt message and sends it to the host device through the RT_Bus bus;

[0065] The cluster device determines whether the communication with the host device is normal based on the status synchronization signal. If not, it sends a communication abnormality signal to the host device.

[0066] The host device adjusts the status synchronization signal after receiving the communication abnormality signal.

[0067] In this embodiment, the CT device (slave device) receives a data frame sent by the PET device (host device) through the RT-Bus bus. The data frame contains the GPIO status information of the PET device, the first CRC check code and the status synchronization signal. The slave signal processing module of the CT device first parses it according to the predetermined data frame format. For example, the first 8 bits of the data frame are specific identification bytes used to confirm the validity of the data frame, and then the GPIO status information indicating whether the PET device is ready is extracted from the 9th to the 16th bit (assuming that 1 indicates ready and 0 indicates not ready), the 17th to the 24th bit is information on whether it is in the scanning calibration state, and the 25th to the 32nd bit is fault warning information, etc. At the same time, the first CRC check code is extracted from a specific position of the data frame, assuming that it is 0x3456, and the status synchronization signal (heartbeat bit) is obtained, whose initial state is 0 and the jump period is 5 milliseconds. The slave signal processing module of the CT device uses the same CRC algorithm (such as CRC-16) to recalculate the extracted GPIO status information to generate a second CRC check code. After calculation, the second CRC check code is assumed to be 0x3457. Then the second CRC check code is compared with the received first CRC check code. Since 0x3457 is different from 0x3456, the CRC check fails. Because the CRC check fails, the CT device generates an error prompt message, the information content includes the error type (CRC check error), data frame related identification, etc., and then sends the error prompt message to the PET device through the RT-Bus bus. At the same time, the CT device determines whether the communication with the PET device is normal based on the state synchronization signal (heartbeat bit). There is a counter inside the CT device to record the number of jumps and time intervals of the heartbeat bit. If the number of jumps of the heartbeat bit does not match the expectation within a predetermined time (such as 100 milliseconds) (it is expected to jump 20 times, but it actually only jumps 15 times), it is determined that the communication is abnormal. In this case, the CT device sends a communication abnormality signal to the PET device, and the signal contains specific information of the abnormality, such as the time point of the abnormal heartbeat bit jump and the actual number of jumps. After receiving the abnormal communication signal, the PET device first checks its own status synchronization signal (heartbeat bit) generation module. It checks whether the internal clock source is stable and whether there are errors in the heartbeat bit generation logic. If a slight frequency drift is found in the clock source, the PET device will adjust the frequency of the clock source to stabilize the heartbeat bit transition period to 5 milliseconds. At the same time, the PET device will also record relevant information about the communication abnormality, such as the time when the error occurred and which GPIO status information transmission is related, so as to facilitate subsequent troubleshooting and analysis.Then, the PET device re-collects the GPIO status information, generates the data frame again and sends it to the CT device, repeating the above verification and communication monitoring process until the data can be accurately transmitted and the communication is stable, thereby ensuring the reliability of information exchange between devices during the operation.

[0068] In the above implementation, by performing CRC check on the received data frame by the slave device, it is possible to effectively detect whether an error occurs in the data transmission process. The regenerated second CRC check code is compared with the received first CRC check code, and the data is considered to be accurate only when the two are consistent, thereby improving the accuracy of the data and ensuring that the GPIO state information obtained by the slave device is reliable. When the CRC check fails, the slave device sends an error prompt message to the host device, so that the host device can promptly know that there is a problem with the data transmission. The host device can take corresponding measures accordingly, such as resending the data frame or checking the data transmission link, thereby improving the error correction capability of the entire communication system for data errors and ensuring the stability and reliability of data transmission. The slave device determines whether the communication between the slave device and the host device is normal based on the state synchronization signal, which provides an effective means for real-time monitoring of the communication link. If the communication is abnormal, a communication abnormality signal is sent to the host device in a timely manner, so that both parties can quickly locate and solve the communication fault. After receiving the communication abnormality signal, the host device adjusts the state synchronization signal, which helps to optimize the communication connection. The host device can adjust the parameters of the status synchronization signal according to abnormal situations, such as changing the signal transmission clock frequency, adjusting the signal strength or optimizing the signal encoding method, etc., to adapt to different communication environments and needs. It can improve the adaptability of the system in complex and changing environments, ensure the continuity and stability of communication, and promote the efficient operation of the entire system.

[0069] Step S208, after receiving the error prompt information, the host device resends the data frame to the slave device via the RT_Bus bus until the CRC check passes.

[0070] Optionally, after receiving the error prompt information, the host device resends the data frame to the slave device through the RT_Bus bus until the CRC check passes, including:

[0071] The host device analyzes the error prompt information sent by the slave device to obtain the error type and error cause;

[0072] The host device re-collects the GPIO status information through the host signal processing module, and generates a CRC check code corresponding to the GPIO status information based on the CRC algorithm;

[0073] Update the data frame based on the GPIO status information and the CRC check code, and send the updated data frame to the slave signal processing module of the slave device through the RT_Bus bus;

[0074] The slave signal processing module of the slave device extracts the GPIO status information and the CRC check code based on the data frame, and performs a CRC check on the GPIO status information based on the CRC check code;

[0075] The above steps are iterated until the CRC check passes.

[0076] In this embodiment, the PET device receives the error prompt information sent by the CT device. This information indicates that the CRC check is wrong, and some GPIO status information in the data frame is suspected to be lost. The host signal processing module of the PET device parses the error prompt information and determines that the error type is a data integrity problem and a CRC check mismatch. The cause of the error may be interference during data transmission or an encoding error when the data frame is constructed. The host signal processing module re-collects the GPIO status information. For example, read the GPIO pin connected to the detector temperature sensor again, obtain the current detector temperature value (assuming it is 37.5°C, converted to the corresponding GPIO status code 0x1234), and the GPIO information of the data acquisition module status (assuming the normal state code is 0x5678), etc. Then regenerate the CRC check code corresponding to these GPIO status information based on the CRC algorithm (such as CRC-16), assuming it is 0xABCD. Based on the re-collected GPIO status information (0x1234 represents the detector temperature, 0x5678 represents the data acquisition module status) and the newly generated CRC check code 0xABCD, the host signal processing module of the PET device updates the data frame. The data frame header is set to a specific identifier 0xEEEE, indicating a resent data frame. The GPIO status information and CRC check code are written in sequence according to the predetermined format, and then the updated data frame is sent to the slave signal processing module of the CT device through the RT_Bus bus. After receiving the data frame, the slave signal processing module of the CT device extracts the GPIO status information (0x1234 and 0x5678) and the CRC check code (0xABCD), and performs a CRC check on the GPIO status information based on the CRC check code. If the check still fails, the CT device sends an error prompt message to the PET device again and repeats the above steps. If the check passes, the CT device confirms that the data is received correctly and adjusts its own scanning parameters according to these GPIO status information. For example, if the detector temperature of the PET device is high, the CT device may appropriately reduce its own scanning power to reduce the heat generation of the overall device, and use the data acquisition module status information of the PET device to optimize the image fusion algorithm to ensure the efficiency and accuracy of the collaborative work of the equipment during the operation.

[0077] In the above implementation, when the host device receives the error prompt information, it can analyze the error type and cause, and re-collect the GPIO status information and generate the check code to update the data frame and resend it, which effectively improves the probability of the data being correctly transmitted in the end. In a communication environment with interference or unstable factors, such as a scene with a large amount of electromagnetic interference or large network fluctuations in an industrial site, the data transmitted for the first time may be erroneous, but through this automatic retransmission error correction mechanism, it can continuously try until the data is accurately received by the slave device, ensuring that the key GPIO status information is complete and correctly transmitted, and enhancing the data transmission reliability of the entire system. The process of iteratively executing data retransmission until the CRC check passes forms a closed-loop error correction system, so that the system will not cause the entire communication process to be interrupted or data lost due to a single data transmission error, ensuring the continuity and integrity of data transmission, and even under relatively harsh communication conditions, it can ensure that the basic functions of the system are not affected and maintain the stable operation of the system. The host device's ability to analyze and take different countermeasures based on the error prompt information enables the system to adapt to a variety of different types of error situations. Whether it is due to a short-term anomaly in the data collection process, signal interference in the data transmission process, or other potential causes of errors, the system can attempt to self-repair and adjust. This makes the system more robust in the face of complex and changing actual application environments, and can flexibly respond to various emergencies, reduce the impact of environmental changes or unexpected events on system operation, and improve the overall adaptability and flexibility of the system.

[0078] According to another aspect of the embodiment of the present application, Figure 4 As shown, a communication device based on RT_Bus is provided, comprising:

[0079] The communication establishment module 401 is used for sending a communication confirmation signal to the host device after the slave device receives the handshake signal sent by the host device via the RT_Bus bus;

[0080] The data sending module 403 is used for the host device to send a data frame including GPIO status information and a first CRC check code to the slave device after receiving the communication confirmation signal;

[0081] The data verification module 405 is used to extract the corresponding GPIO status information and the verification code after receiving the data frame from the slave device, perform CRC verification on the GPIO status information through the first CRC verification code, and send an error prompt message to the host device if the verification fails;

[0082] The data retransmission module 407 is used for the host device to retransmit the data frame to the slave device through the RT_Bus bus after receiving the error prompt information until the CRC check passes.

[0083] It should be noted that the communication establishment module 4011 in this embodiment can be used to execute step S202 in the embodiment of the present application, the data sending module 403 in this embodiment can be used to execute step S204 in the embodiment of the present application, the data verification module 405 in this embodiment can be used to execute step S206 in the embodiment of the present application, and the data retransmission module 407 in this embodiment can be used to execute step S208 in the embodiment of the present application.

[0084] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments. It should be noted that the above modules as part of the device can be run in Figure 1 In the hardware environment shown, it can be implemented by software or by hardware.

[0085] According to another aspect of the embodiments of the present application, the present application provides an electronic device, such as Figure 5 As shown, it includes a memory 502, a processor 504, a communication interface 506 and a communication bus 508. The memory 502 stores a computer program that can be run on the processor 504. The memory 502 and the processor 504 communicate through the communication interface 506 and the communication bus 508. When the processor 504 executes the computer program, the steps of the above method are implemented.

[0086] The memory and processor in the above electronic device communicate through the communication bus and the communication interface. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

[0087] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0088] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0089] According to another aspect of the embodiments of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps of any of the above embodiments.

[0090] Optionally, in an embodiment of the present application, the computer-readable medium is configured to store program codes for the processor to execute the following steps:

[0091] Step S202: After receiving the handshake signal sent by the host device via the RT_Bus bus, the slave device sends a communication confirmation signal to the host device.

[0092] Step S204 , after receiving the communication confirmation signal, the host device sends a data frame including GPIO status information and a first CRC check code to the slave device.

[0093] Step S206, after receiving the data frame, the slave device extracts the corresponding GPIO status information and the check code, performs a CRC check on the GPIO status information using the first CRC check code, and sends an error prompt message to the host device if the check fails.

[0094] Step S208, after receiving the error prompt information, the host device resends the data frame to the slave device via the RT_Bus bus until the CRC check passes.

[0095] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0096] When the embodiments of the present application are specifically implemented, reference may be made to the above-mentioned embodiments, which have corresponding technical effects.

[0097] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the present application, or a combination thereof.

[0098] For software implementation, the technology described herein can be implemented by a unit that performs the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0099] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0100] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0101] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0102] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0103] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0104] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk. It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, article or device. Without more constraints, an element defined by the phrase "comprising a..." does not exclude the existence of other identical elements in the process, method, article or apparatus comprising the element.

[0105] The above description is only a specific implementation of the present application, so that those skilled in the art can understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest range consistent with the principles and novel features applied for herein.

Claims

1. A communication method based on RT_Bus, characterized in that: include: After receiving the handshake signal sent by the host device through the RT_Bus bus, the slave device sends a communication confirmation signal to the host device; After receiving the communication confirmation signal, the host device sends a data frame including GPIO status information and a first CRC check code to the slave device; After receiving the data frame, the slave device extracts the corresponding GPIO status information and the check code, performs CRC check on the GPIO status information through the first CRC check code, and sends an error prompt message to the host device if the check fails; After receiving the error prompt information, the host device resends the data frame to the slave device via the RT_Bus bus until the CRC check passes.

2. The communication method based on RT_Bus according to claim 1, characterized in that: Before the slave device receives the handshake signal sent by the host device through the RT_Bus bus, it also includes: Determine the communication connection method between the host device and the slave device according to the RT_Bus bus specification; Configure the RT_Bus bus interface of the host device and the slave device according to the communication connection mode; Writing a driver and a communication protocol stack between the host device and the slave device in the RT_Bus bus interface; Initialize the host signal processing module of the host device and the slave signal processing module of the slave device, and load the RT_BusIP core in the host signal processing module and the slave signal processing module; The host device generates a handshake signal through the host signal processing module and sends the handshake signal to the slave signal processing module of the slave device through the RT_Bus bus.

3. The communication method based on RT_Bus according to claim 1, characterized in that: After receiving the handshake signal sent by the host device via the RT_Bus bus, the slave device sends a communication confirmation signal to the host device, including: After receiving the handshake signal sent by the host device, the slave device obtains the host identity based on the handshake signal, compares the host identity with a preset identity, and sends an invalid identity message to the host device if the host identity is invalid; The slave device compares the communication protocol of the handshake signal with the preset communication protocol, and sends a communication failure signal to the host device if the communication protocol is invalid, and sends a communication confirmation signal to the host device if the communication protocol is valid.

4. The communication method based on RT_Bus according to claim 2, characterized in that: After receiving the communication confirmation signal, the host device sends a data frame including GPIO status information and a first CRC check code to the slave device, including: The host device collects GPIO status information of the GPIO pin through the host signal processing module; Generate a first CRC check code of the GPIO state information by a CRC algorithm; Generate a data frame based on the GPIO state information and the corresponding first CRC check code; The host signal processing module of the host device sends the data frame to the slave signal processing module of the slave device through the RT_Bus bus.

5. The communication method based on RT_Bus according to claim 4, characterized in that: Before the host signal processing module of the host device sends the data frame to the slave signal processing module of the slave device through the RT_Bus bus, it also includes: The host device generates a status synchronization signal for detecting whether the communication between the host device and the slave device is normal; The state synchronization signal is added at a preset position of the data frame, and the state synchronization signal is provided with a signal transmission clock of the host device and the slave device.

6. The communication method based on RT_Bus according to claim 5, characterized in that: After receiving the data frame, the slave device extracts the corresponding GPIO status information and the check code, performs CRC check on the GPIO status information through the first CRC check code, and sends error prompt information to the host device if the check fails, including: After receiving the data frame, the slave device parses the data frame to extract the GPIO state information, the first CRC check code and the state synchronization signal; The slave device generates a second CRC check code corresponding to the GPIO state information through a CRC algorithm; Compare the second CRC check code with the first CRC check code. If the second CRC check code is the same as the first CRC check code, the CRC check passes. If the second CRC check code is different from the first CRC check code, the CRC check fails, and the slave device generates an error prompt message and sends it to the host device through the RT_Bus bus. The cluster device determines whether the communication with the host device is normal according to the status synchronization signal, and sends a communication abnormality signal to the host device if it is not normal; The host device adjusts the status synchronization signal after receiving the communication abnormality signal.

7. The communication method based on RT_Bus according to claim 1, characterized in that: After receiving the error prompt information, the host device resends the data frame to the slave device through the RT_Bus bus until the CRC check passes, including: The host device analyzes the error prompt information sent by the slave device to obtain the error type and error cause; The host device re-collects the GPIO status information through the host signal processing module, and generates a CRC check code corresponding to the GPIO status information based on a CRC algorithm; Updating a data frame based on the GPIO status information and the CRC check code, and sending the updated data frame to a slave signal processing module of a slave device via an RT_Bus bus; A slave signal processing module of the slave device extracts the GPIO state information and the CRC check code based on the data frame, and performs a CRC check on the GPIO state information based on the CRC check code; The above steps are iterated until the CRC check passes.

8. A communication device based on RT_Bus, characterized in that: include: The communication establishment module is used for sending a communication confirmation signal to the host device after the slave device receives the handshake signal sent by the host device through the RT_Bus bus; A data sending module, used for the host device to send a data frame including GPIO status information and a first CRC check code to the slave device after receiving the communication confirmation signal; A data verification module, configured to extract the corresponding GPIO status information and the verification code after receiving the data frame from the slave device, perform CRC verification on the GPIO status information through the first CRC verification code, and send an error prompt message to the host device if the verification fails; The data retransmission module is used for the host device to resend the data frame to the slave device through the RT_Bus bus after receiving the error prompt information until the CRC check passes.

9. An electronic device, comprising a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, and the memory and the processor communicate through the communication bus and the communication interface, characterized in that: When the processor executes the computer program, the RT_Bus-based communication method described in any one of claims 1 to 7 is implemented.

10. A computer readable medium having a non-volatile program code executable by a processor, characterized in that: The program code enables the processor to execute the RT_Bus-based communication method described in any one of claims 1 to 7.

Images