Abstract: This paper proposes a scheme for information interaction in a multi-CPU system using the MODBUS protocol, analyzes the design of the hardware and software communication mechanism, the method of system collaborative development, and various measures to improve communication efficiency. Keywords: MODBUS communication protocol, multi-CPU system communication. In the fields of power system microcomputer integrated protection and control devices and other industrial automation control, the application of microcontrollers is becoming increasingly widespread, and the complexity of these devices is also increasing. To address the real-time multitasking requirements of their development targets, the single-CPU, single-input development mode is being replaced by a mode of multi-CPU, multi-type CPU, and multi-person collaborative development. In this new development mode, a new problem arises—how to standardize the hardware and software for information interaction between CPUs during the implementation process. This is crucial to the successful implementation of this mode. Among numerous communication methods, the RS-485 serial communication mode based on UART is widely used due to its simple wiring, high reliability, and ability to drive multi-CPU and multi-device cascading. Regarding the selection of software communication protocols, the MODBUS protocol offers many advantages to users due to its universal and mature third-party standard testing software. Therefore, in the development of the new TH21-4M integrated motor protection device, RS-485 serial communication and MODBUS communication protocol were adopted to realize the information exchange of data and control commands between multiple CPUs. To enhance the efficiency and coordination of serial communication, many measures were taken in the hardware and software structure of the communication mechanism, achieving excellent results. During the system communication debugging phase, each CPU module first communicated with the MODBUS standard test software, and then they were mutually debugged, greatly improving the efficiency of collaborative development. Practice has proven that this design concept simplifies the system structure and greatly improves the operating efficiency and reliability of the device. This paper will combine the design concept of TH21-4M and introduce how to use the MODBUS communication protocol to realize the collaborative development of a multi-CPU structure from both hardware design and software planning aspects. 1. Features of the TH21-4M Integrated Motor Protection Device In addition to its integrated protection function, the TH21-4M integrated motor protection device also has measurement, remote control, and communication functions; a large-screen Chinese character LCD display provides a user-friendly human-machine interface; and it uses a CAN bus to communicate with the monitoring host, thus forming a subsystem of a hierarchical and distributed substation integrated automation system. In terms of design, due to the need for the device to perform multiple tasks, a multi-CPU system architecture was adopted to optimize system functionality. One CPU is responsible for timing sampling pulse transmission; the main CPU module is responsible for data processing, power calculation, fault diagnosis, and switching operations; while the CPU on the board module is responsible for human-machine interaction and communication with the main protection module and monitoring host. Each CPU module has a clear division of labor, which facilitates collaborative development by multiple people. In the entire structure, serial communication connects the main CPU and the board CPU, making human-machine interaction possible, and therefore plays an important role. Establishing a reasonable communication mechanism is the core of the serial communication part, which determines the coordination of communication and the efficiency of debugging in the later stages of system development. 2 Introduction to Communication Mechanism 2.1 Hardware Design Principles of Communication Mechanism The communication mechanism of this system is proposed with the aim of high efficiency and reliability. RS-485 is a half-duplex structure, which is often closer to practical use than full-duplex in the field. Here, the simplest connection with only 2 signal lines is adopted. The system interface circuit diagram is shown in Figure 1. The TTL logic level output by the 80C196 microcontroller on the main protection module is converted to RS-495 level by the MAX485 chip after opto-isolation, and then converted to TTL logic level by the MAX485 chip on the panel module, which is then read by the 80C31 microcontroller; the same applies to the 80C196 microcontroller. On the 80C196 microcontroller side, one bit P2.7 of parallel input/output port 2 (IO_PORT2) is used to control the MAX input enable terminal RE and the output enable terminal DE. As shown in Figure 1, when P2.7 outputs a high level, RE is enabled, and the microcontroller receives data; when P2.7 outputs a low level, DE is enabled, and the microcontroller sends data. This avoids data loss due to blind transmission, ensuring high communication quality and communication speed. 2.2 Introduction to Communication Protocol To ensure that the two modules in the protection device can correctly transmit data, there must be a set of regulations regarding the mode, data format, and content of information transmission, i.e., a protocol or communication protocol. Although the communication inside the protection device is relatively simple and the amount of data transmitted between the two modules is not much, the disadvantages of the custom internal communication protocol are obvious. First, it is difficult for the custom communication protocol to coordinate well in terms of timing and task, and the reliability of data transmission is also difficult to guarantee; second, since there is no readily available mature debugging software, the main CPU module is basically a black box, and there are many difficulties in system joint debugging that are difficult to overcome. Therefore, the currently popular MODBUS communication protocol was adopted and simplified in combination with the characteristics of this device, thus realizing communication between modules, and the results have proven to be very good. The MODBUS communication mode is master-slave mode [2]. The master first sends a communication request instruction to the slave, and the slave sends back data to the master according to the function code in the request instruction. Each slave has its own independent address. The request frame sent by the master and the response frame sent by the slave both start with the slave address. The slave only reads the instructions sent to itself and does not respond to messages that start with other slave addresses. This question-and-answer communication mode greatly improves the accuracy of communication. However, this master-slave method also has drawbacks for microcomputer protection. When the master protection module performs a protection action, it cannot immediately transmit fault information to the host computer. The host computer must continuously query the master protection module to see if the protection has been activated. If so, it then requests further specific fault information. MODBUS has two transmission modes: RTU (Remote Terminal Unit) and ASCII. To ensure high communication speed, the RTU mode is used. Data bytes have no parity bit; with start and stop bits, the byte length is 10 bits, and the data interval is within 24 bits. Cyclic redundancy check is used to verify the message. A typical MODBUS message format is as follows: The specific content of a communication message depends on the function code of the instruction string. The standard function codes defined in MODBUS are shown in Table 1. Table 1 Standard Function Codes in the MODBUS Protocol. From the definition of the function codes, it can be seen that the transmitted message objects are mainly divided into analog and digital quantities, and the content of the message is determined by the function code in the message header. In practical applications, function codes 02, 04, 05, and 06 are mainly used to complete the reading and setting of digital and analog quantities. The data start address and data volume are the main contents of the message. MODBUS specifies that the data volume is either data read from or written to the device being communicated with. Each communication device has its own address. In the internal communication of the protection device, each communication device is designated by the digital and analog quantities stored in the motherboard's RAM, as well as the protection configurations and settings set in the EEPROM. When processing communication messages, the reading or sending task is performed based on the message's data start address and corresponding data volume length. When transmitting digital quantities, data values ​​at different addresses are represented by different bits in the message's data volume, thus transmitting more data information and efficiently utilizing the communication message. Because each frame of data has a variable length, it is convenient and flexible, avoiding the waste of CPU time and memory space caused by fixed frame lengths. Furthermore, the MODBUS communication protocol specifies that the address in the communication string is "1" smaller than the actual address, which is convenient for array operations. The last two bytes of the message are check bytes. RTU communication uses CRC-16 cyclic redundancy check, which involves shifting the entire string (excluding the last two bytes) according to a specified method and performing an XOR operation. The result is stored in the last two bytes of the string, and the receiver checks for consistency using the same calculation method. This check method is very effective in verifying frame corruption caused by random or sudden errors. 3 Measures to Improve Communication Efficiency In the software design process after establishing the hardware platform and communication protocol, the author adopted many methods to improve communication efficiency and reliability. 3.1 Dividing Communication into Two Independent Tasks: Receiving and Sending. The 80C196 microcontroller can use both polling and interrupt methods to send and receive data through the serial port. For interrupt methods, the 80C196 microcontroller provides two serial port interrupt methods: The first method is a separate serial port interrupt, controlled by bit D6 of the interrupt mask register INT_MASK, corresponding to interrupt vector 200CH. Setting bits D5 (transmission complete flag TI) and D6 (reception complete flag RI) of the serial port status register SP_STAT (11H) will trigger this interrupt. The second method sets separate interrupt numbers for receiving and transmitting. Bit D0 of INT_MASK1 corresponds to the transmit interrupt, interrupt vector 2030H, and setting TI triggers this interrupt; bit D1 of INT_MASK1 corresponds to the receive interrupt, interrupt vector 2032H, and setting RI triggers this interrupt. The author adopted the second communication method. This way, after each byte is received or transmitted, the corresponding interrupt is triggered, directly proceeding to the next round of receiving or transmitting tasks, without needing to check the serial port control/status registers SP_CON/SP_STAT (11H), making the interrupt subroutine more concise and efficient. 3.2 Minimize Interrupt Time Since multiple interrupts are used in the software architecture design, to ensure reliable program operation and reduce the probability of conflicts between different interrupts, the tasks of various interrupts should be simplified as much as possible during software development to shorten interrupt execution time. In the communication interrupt subroutine, necessary tasks are performed after entering the interrupt, such as: clearing the corresponding status bits in the serial port status register SP_STAT, reading or writing the recently received or to-be-sent character from the buffer, incrementing the number of received or sent characters by 1, etc., and then immediately exiting the interrupt. Other tasks, such as determining the validity of the frame, responding to received frame commands (telemetry, remote control commands), and preparing to send frames, are all completed in the main program. 3.3 Reliably Determine Frame End to Prevent Communication Stall Using a separate software timer to determine the end of a received message frame can prevent the communication task of that frame from failing to end if the message reception is incomplete, thus affecting the reception of the next frame. Because the time interval between bytes in a message frame is much smaller than the time interval between frames, a software timer is started whenever a new byte is received. The timer's duration is set to the minimum time interval between frames. This time interval varies depending on the baud rate. If the next byte is received before the predetermined time, it indicates that a message frame has not ended, and the timer restarts. If the timer successfully counts to the predetermined time, the corresponding interrupt number is triggered. In the timer interrupt subroutine, a frame end flag byte is set, indicating that a message frame has been received. When the main program detects that a message frame has been received, it checks the slave address and cyclic redundancy check byte to determine the frame's validity. If it is determined that the received message is a correct message sent to the slave, the frame command is processed according to the function code within the message, and preparation is made to send the frame. The MODBUS protocol also specifies an error frame to be sent back when the slave receives an incorrect message. Considering that the internal communication process of the device is not very complex, in practical applications, if the message received by the slave is incorrectly checked, no response is given. If the master does not receive a response message from the slave within the specified time, it will resend the request message; if it fails to receive a response message from the slave multiple times, it will report a communication failure. 3.4 Determining the Communication Rate Since all the devices are located in the same chassis, the distance between modules is very short. MODBUS is based on RS485 for long-distance communication, so the impact of distance on the communication baud rate can be disregarded. Furthermore, due to the master-slave communication mode, there will be no line congestion. Therefore, from the perspective of communication efficiency alone, as long as the maximum baud rate limit of the chip used by the module is not exceeded, the higher the baud rate, the faster the information exchange and the higher the communication efficiency. However, for real-time multitasking systems, the coordination of various tasks must be considered. The MODBUS communication protocol only specifies the formats of various communication messages, without making strict requirements on the communication baud rate and parity. When a message frame is long and the baud rate is high, the CPU may be busy processing communication and may lose other real-time tasks, such as real-time sampling. Therefore, when selecting the communication baud rate, it is necessary to consider coordination with other tasks, rather than simply choosing the highest possible value. In practical applications, the baud rate was set to 19200bps, and the system was tested. Because the baud rates of both communicating parties were set to be completely identical, the sampling of each data bit at the receiving end occurred at the midpoint of the bit period, achieving reliable communication. Furthermore, parity bits were not used during character transmission, thus relatively increasing the rate of effective byte transmission. 3.5 Reasonable Debugging Methods In the early stages of development, tools such as simulators could only monitor a single CPU module in real time, and could not simultaneously monitor both sides of the serial communication, making it difficult to pinpoint problems and significantly impacting debugging efficiency. Therefore, each CPU module was first tested to communicate with the microcomputer via an RS485/RS232 data conversion module. Only after successful testing were inter-module joint debugging performed, greatly improving the efficiency of joint debugging. During the debugging process of each module communicating with the microcomputer, the microcomputer used MODBUS debugging software to simulate the master's communication process, actively requesting information from the slave (each CPU module). The entire receiving and transmitting process was transparent and clear, allowing most problems in the modules to be discovered and resolved promptly during communication with the microcomputer. During inter-CPU module debugging, bus monitoring software can be used to observe the data sent by both sides. When communication problems occur, it becomes easier to determine which module is sending incorrect data, thus pinpointing the problem. This debugging method greatly enhances coordination between different developers and different CPUs, improving the efficiency and progress of device development.