Hello everyone, I am XXX. Today I bring you a detailed analysis of microcontroller communication protocols, including mainstream protocols such as UART, I2C, and SPI. These protocols are the bridge for data exchange between microcontrollers and other devices, and mastering them is crucial for embedded system development. Let’s break them down one by one, and I hope this will be helpful to you!
UART Communication
First, let’s start with the most familiar UART communication. Imagine two people wanting to have a conversation; they need to speak a language that both understand, and only one person can speak while the other listens. This is the principle of how UART works; it is a form of serial, simplex communication.
A small chip on the microcontroller is specifically responsible for this task, called UART (Universal Asynchronous Receiver-Transmitter). Its main job is to convert parallel data streams into serial output or to convert serial input into parallel data streams.
However, to understand each other, both parties need to agree on two parameters:
-
Baud Rate: Refers to the number of symbols transmitted per second, equivalent to the speed of speech. -
Data Format: Refers to how many bits make up each data transmission, equivalent to how many words are spoken at once.
For example, in the Windows Device Manager, we can see that the default settings for UART are 9600 baud, 8 data bits, no parity bit, and 1 stop bit. As long as both sides are set consistently, they can “communicate.”
Of course, in real life, communication between people is bidirectional, but the simplex nature of UART means that it can only transmit data in one direction at a time, making it half-duplex communication. If bidirectional communication is needed, a program must be written to coordinate the switching between the two directions.
In addition to these settings, we also need to assign two hardware pins for UART, namely TXD (Transmit) and RXD (Receive). UART transmits data through these two lines, which is simple and practical, making it the most commonly used communication method in embedded development. However, the data transmission rate is relatively low, around 115200 bps, mainly used for short-distance communication with small data volumes.
I2C Bus
If we need to transmit large amounts of data or connect multiple peripheral devices, we need to use bus-type communication protocols such as I2C and SPI. Taking I2C as an example, it is like a “group chat.”
The I2C bus consists of two lines: the Serial Data Line (SDA) (similar to the content of speech) and the Serial Clock Line (SCL) (similar to the rhythm of speaking). All devices connected to the bus must first “introduce” their addresses (similar to a WeChat ID) before they can “speak” on the SDA line.
Since the SCL line sets a unified rhythm, I2C can transmit one byte (8 bits) of data at a time without needing to agree on a baud rate in advance. Additionally, the master can send start and stop signals to switch communication with multiple slaves, achieving true full-duplex communication.
However, both SDA and SCL lines are open-drain structures that need to be enabled through pull-up resistors, and since only two lines carry all transmissions, the actual maximum rate does not exceed 400 KHz, which is slower than UART. Therefore, I2C is suitable for building simple systems with relatively low speed requirements, such as data exchange with a few simple sensors. Other mainstream applications include reading and writing EEPROM data and setting real-time clocks, etc.
SPI Bus
Similar to I2C, the SPI bus is also commonly found in embedded systems for connecting multiple peripheral devices. It consists of the following signal lines:
-
MOSI – Master Out Slave In -
MISO – Master In Slave Out -
SCLK – Clock signal line, generated by the master -
CS – Chip Select signal line
SPI is a full-duplex synchronous serial communication protocol, allowing the master and slave to send and receive data simultaneously under the same clock signal, without needing to transmit addresses. When CS is active, the master starts sending or reading data from the slave device.
Since SPI only specifies the communication timing and does not define specific working frequencies, data frame formats, or byte transmission orders, the master and slave must coordinate these parameters in advance. However, this also provides SPI with high flexibility, allowing for optimization of the transmission method based on application scenarios, commonly used in mobile reading and writing large data volumes for multimedia applications.
Additionally, SPI supports multiple slaves connected to the same bus, requiring only the corresponding slave’s CS to be active during data transmission. Theoretically, the maximum speed of the SPI bus can reach 70 Mbps, which is beneficial for building high-speed communication systems.
Other Communication Methods
In addition to the aforementioned UART and bus communication, the following methods are also commonly used for data exchange in embedded systems:
-
USB: Nowadays, many microcontrollers support USB communication with PCs. -
Ethernet: Microcontrollers can be connected to the network via Ethernet modules. -
Wi-Fi/Bluetooth: To enable wireless communication, dedicated modules are often interfaced with microcontrollers. -
ZigBee: A low-power, short-range wireless mesh network standard.
Different communication methods have their own advantages and disadvantages in terms of speed, cost, power consumption, and reliability. Developers need to choose the most suitable communication protocol based on actual needs.
In summary, the “dialogue” between microcontrollers and external devices relies on the communication protocols introduced above. After reading today’s content, I hope everyone can have a comprehensive understanding of the communication methods in microcontroller systems.
Finally, I would like to leave you with a small practice task:
Display the text sent from the computer on the microcontroller’s LCD screen via UART, and also read the values from a temperature and humidity sensor through the I2C interface, displaying them on the LCD screen as well. Completing this small practice will help you experience the collaboration between different communication interfaces and deepen your understanding of protocol usage. Feel free to provide feedback if you have any questions, and see you next time!