The increasing variety of microcontrollers with diverse functions provides us with many new methods and ideas for design. For certain applications, such as complex background computation and communication systems with high real-time foreground control systems, systems with high software resource consumption, powerful low-power systems, and encryption systems, the reasonable use of various types of microcontrollers in combination can achieve extremely high flexibility and performance-price ratio. Therefore, the design of systems using multiple heterogeneous microcontrollers is gradually becoming a new approach. However, communication between microcontrollers has always been a major problem hindering the expansion of this method.
This article will analyze and compare the approaches and challenges of several microcontrollers, and propose a solution.
1. Several common communication methods between microcontrollers
① Asynchronous serial communication using hardware UART. This is an efficient and reliable communication method that requires few I/O lines; however, many small microcontrollers lack hardware UART, and some only have one UART. If the system also needs to communicate with a host computer, the hardware resources are insufficient. This method is generally used when the microcontroller has hardware UART and does not need to communicate serially with the outside world, or when using a dual-UART microcontroller.
② It adopts serial communication via an on-chip SPI interface or I2C bus module. The SPI/I2C interface has the advantages of simple hardware and easy software programming, but most microcontrollers currently do not have a hardware SPI/I2C module.
③ Using software to simulate SPI/I2C communication mode is difficult to simulate slave mode. Both communicating parties need to respond to each bit, creating a significant conflict between communication speed and software resource overhead. If not handled properly, this can lead to a sharp decline in overall system performance. This method can only be used in situations with very low communication volume.
④ Point-to-point parallel communication utilizes the microcontroller's I/O lines for direct connection, along with 1-2 handshake signal lines. This method is characterized by high communication speed, capable of transmitting 4 or 8 bits, or even more, at a time. However, it requires a large number of I/O lines, and data transmission is quasi-synchronous. After one microcontroller transmits one byte to another, it must wait for the other microcontroller's receive response signal before transmitting the next data. This method is generally used in situations where there are ample hardware I/O lines.
⑤ Use dual-port RAM as a buffer for communication. The biggest advantage of this method is its fast communication speed, and both sides can directly operate using read and write instructions to the memory; however, this method requires a large number of I/O lines, and dual-port RAM is very expensive, so it is generally only used in some applications with special speed requirements.
From the above solutions, it's clear that each method places significant demands and limitations on hardware, particularly making implementation difficult on simple microcontrollers. Therefore, finding a simple and effective method for communication between various microcontrollers is crucial. In solutions ③ and ④, each microcontroller needs to respond to every bit or byte transmitted. When the amount of communication data is large, this consumes substantial software resources, which is unacceptable in applications with high real-time requirements. To address this issue, consider adding a data buffer between the microcontrollers. Large amounts of data are first written to the buffer, and then retrieved by the other microcontroller. Each microcontroller operates in master mode for the data buffer, significantly improving communication efficiency. When discussing data buffering, parallel RAM immediately comes to mind. However, parallel RAM requires a large number of I/O lines (data lines + address lines + read/write lines + chip select lines + handshake lines), typically more than 16. This is a daunting number and significantly increases PCB area, complicating routing; therefore, this approach is rarely used. Serial interface RAM is also rare on the market, being both difficult to obtain and very expensive. Shift registers can also be used as data buffers, but the largest capacity currently available is only 128 bits. Because they are "first-in, first-out" (FIFO) structures, the receiver must shift the entire register regardless of the amount of data being transferred, resulting in poor flexibility. Furthermore, large-capacity shift registers are rare and difficult to obtain. The emergence of a chip called "ferroelectric memory" has provided a solution.
2. Communication method using ferroelectric memory as a data buffer
Ferroelectric RAM (FRAM) is a new type of non-volatile memory device recently introduced by Ramtran, Inc. Compared to ordinary EEPROM and Flash-ROM, it has advantages such as no write time, unlimited read/write cycles, and continuous write/put functionality without a distributed structure. Therefore, it possesses the dual characteristics of RAM and EEPROM, and its price is relatively low. Most microcontroller systems are currently equipped with serial EEPROMs (such as 24CXX and 93CXX) for storing parameters. If a single FRAM is used to replace the original EEPROM, it can both store parameters and act as a buffer for serial data communication. Two (or more) microcontrollers can be connected to a single FRAM in a multi-master-slave I2C bus configuration. By adding a few handshake lines, a simple and efficient communication hardware circuit can be obtained. On the software side, as long as the control conflicts and communication protocol issues of the I2C multi-master-slave configuration are resolved, simple, efficient, and reliable communication can be achieved.
3. Example (Dual microcontroller architecture, multi-functional low-power system)
(1) Hardware
The W78LE52 and EMC78P458 form a battery-powered, remotely communicating industrial flow meter. The 78P458 uses a 32.768kHz crystal oscillator, has low operating current, and operates continuously, acquiring real-time sensor pulses and analog quantities such as temperature and pressure. The W78LE52 uses an 11.0592MHz crystal oscillator; due to its higher operating current, it operates intermittently and is responsible for nonlinear flow correction, parameter input, LCD display, and communication with the host computer. Its UART is used for remote communication. The communication interface circuit is shown in Figure 1. The two microcontrollers share a single I2C interface FRAM (FM24CL16) to form a two-master, one-slave I2C bus control mode. P3.5 and P3.2 of the W78LE52 are connected to P51 and P50 of the 78P458 as handshake signal lines A and B, respectively. We define handshake line A (A line for short) as the bus control and indicator line, mainly used to acquire bus control and determine whether the bus is "busy"; handshake line B (B line for short) is defined as the notification line, mainly used to notify the other party to take the data.
(2) I2C bus arbitration
Since we are using a two-master, one-slave I2C bus configuration, preventing two masters from simultaneously operating the slave (anti-collision) is a crucial issue. Devices with hardware I2C modules typically have an internal bus arbiter and a bus timeout timer: when the timeout timer expires, it indicates the bus is idle. At this point, the microcontroller can issue a command to acquire the bus. The bus arbiter confirms success or failure after a series of operations; the timeout timer is then reset. Each subsequent SCL state change resets the timeout timers of all masters on the bus to prevent overflow, indicating the bus is in a "busy" state until one master finishes controlling the bus and no longer generates SCL pulses; when the timeout timer overflows, the bus returns to an "idle" state. However, most microcontrollers currently lack hardware I2C modules, and when the operating frequencies of the two masters differ significantly, the timeout timer value must be set to a larger value, which also affects bus efficiency. The following describes a method for simulating I2C bus arbitration using software (software simulation of I2C read/write operations is very common and will not be elaborated here): A handshake line A is used, and the flowchart is shown in Figure 2. When line A is high, it indicates the bus is idle. When one host wants to acquire bus control, it first checks if the bus is idle. If it is "busy," it exits; if it is idle, it sends a test sequence to line A (e.g., 1000101011001011), reading the status of line A after each "1" bit is sent. If the read status is "0," it immediately exits, indicating that another device has already acquired the bus. If all the read statuses of line A in a sequence are correct, it means that bus control has been successfully acquired. At this point, line A is pulled low to indicate the bus is "busy," until line A is read/written high, returning the bus to the "idle" state. Different hosts use different test sequences, or random test sequences are generated. The test sequence length can be chosen to be longer, which can increase the reliability of arbitration.
(3) Communication Protocol
Besides good hardware circuitry, a reliable communication system also requires a robust communication protocol. Given the limited RAM resources and execution speed of microcontroller systems, a simple and efficient protocol is crucial. Below, we introduce a protocol well-suited for microcontroller communication, where data is transmitted in packet format. Data packet structure:
① Packet header – Indicates the beginning of the data packet, which is helpful for packet integrity detection and can sometimes be omitted;
② Address – The destination address to which the data packet is to be transmitted. This can be omitted if there is only two-machine communication or if the address is hardware-distinguished.
③ Packet length — Indicates the length of the entire data packet;
④ Command – Indicates the function of this data packet;
⑤ Parameters — The data and parameters that need to be transmitted;
⑥ Verification – This verifies the correctness of the data packet. Verification methods include checksum, XOR checksum, CRC checksum, or a combination thereof.
⑦ Packet end – Indicates the end of the data packet, which is helpful for packet integrity detection and can sometimes be omitted.
(4)Communication process
First, the FRAM needs to be divided into different areas, such as the parameter area and data receiving area for each microcontroller. Then, a microcontroller can send a data packet to another microcontroller. After sending, it sends a pulse to handshake line B to notify the other party to retrieve the data. The receiver reads and processes the data, then writes the returned data or a communication failure flag into the sender's data receiving area in the FRAM, and then sends another pulse to handshake line B in response to the sender. Table 3 shows an example of microcontroller 1 initiating communication with microcontroller 2 once.
If microcontroller 2 needs to send data, simply swap the operation process.
4. Summary
Practice has shown that the above methods are feasible. Compared with other methods, they have the following advantages:
① Simple. It occupies fewer microcontroller I/O lines (SCL, SDA, handshake line A, handshake line B).
② Versatile. Software-simulated I2C host mode enables communication between any type of microcontroller.
③ High efficiency. Due to the use of data buffering, communication is possible between microcontrollers with different clock frequencies and speeds; when reading and writing data, it can be done at the highest speed of the I2C bus, which can achieve the transfer of a large amount of data at once; when one microcontroller transfers data to the FRAM, the other microcontroller does not need to respond or wait, and can perform other program operations, thus improving software efficiency.
④ Flexibility. The communication hardware interface is equal for each microcontroller. Through software configuration, each microcontroller can either actively send communication as needed or simply respond to calls from other microcontrollers.
⑤ Easy to expand. By adding address identification lines and modifying the communication protocol, multi-machine communication can be achieved.
The following addresses require attention:
① To improve communication efficiency, handshake line B should ideally use an interrupt port, and the negative pulse width must meet the interrupt signal requirements of low-speed microcontrollers. If there is no interrupt, an additional port line should be added, and the other party should be notified by changing the port status, waiting for the other party to query, instead of using a negative pulse.
② When sending a negative pulse to the other party, your own interrupt should be masked.
③ Since the parameters and communication buffer are both located in the same FRAM, it is necessary to avoid erroneous operations on the parameter section. A better solution is to store the parameters in the latter half of the address (A2=1), and pull the WP pin of the FRAM high during communication operations (write protection for cells in the latter half of the address). This can effectively prevent erroneous operations on the parameter area during testing.
④ Since the I2C bus only has one master and one slave at a time, when one microcontroller is writing communication data, another microcontroller cannot operate on the FRAM. If it is necessary to read parameters from the FRAM frequently in real time, please read the parameters into the RAM unit in advance or add a separate chip to store the parameters.
Disclaimer: This article is a reprint. If it involves copyright issues, please contact us promptly for deletion (QQ: 2737591964). We apologize for any inconvenience.
