尧图网页设计 
1. 项目缘起为什么ESP32需要用好两个串口在嵌入式开发里串口UART的地位大概就相当于我们日常交流的嘴巴和耳朵。它简单、可靠、历史悠久是单片机与外部世界沟通最基础、最常用的方式。ESP32这颗芯片功能强大集成了Wi-Fi和蓝牙但很多开发者上手后第一个要打交道的往往还是串口——无论是用来打印调试信息还是连接GPS模块、传感器、蓝牙转串口模块甚至是与另一个单片机“对话”。ESP32有一个非常实用的特性它内置了三个硬件UART控制器UART0, UART1, UART2。其中UART0通常预留给芯片的USB转串口下载和调试也就是我们通过USB线连接电脑时用的那个串口。那么剩下的UART1和UART2就是我们可以在项目中自由配置和使用的“生产力工具”。我之所以想专门聊聊这个话题是因为在实际项目中只用一个串口的情况越来越少。一个典型的场景是你需要用UART1以较高的波特率接收来自传感器的连续数据流同时用UART2以较低的波特率向一个显示屏或另一个控制器发送状态信息。如果处理不好两个串口的中断相互干扰或者数据接收不完整就会让整个系统变得不稳定。网上很多基础的例程只演示单个串口的收发一旦涉及到多串口协同特别是基于ESP-IDF乐鑫官方物联网开发框架的“驱动篇”操作不少朋友就会遇到配置冲突、资源竞争、数据错乱这些坑。所以这篇内容的目标很明确不满足于点亮一个串口。我们要深入ESP-IDF的驱动层把UART1和UART2这两个串口都稳稳地驱动起来让它们各司其职互不干扰并且能高效、可靠地处理数据。我会从最基础的引脚配置、驱动安装讲起深入到中断处理、环形缓冲区管理最后分享一个双串口数据透传的实战案例以及我趟过的那些坑。无论你是刚接触ESP32还是正在为多串口通信烦恼希望这篇“驱动篇”的深度解析能给你带来实实在在的帮助。2. 硬件与软件准备引脚选择与工程配置在写第一行代码之前我们必须先搞清楚硬件连接和软件环境。这一步看似简单但选错了引脚或者配置不对后面所有工作都是白费力气。2.1 ESP32的UART引脚映射并非所有引脚都能用ESP32的UART引脚是高度可配置的但这并不意味着所有GPIO都可以随意用作TXD发送和RXD接收。我们需要查阅技术手册或参考uart.h头文件中的宏定义。以我手头常用的ESP32-WROOM-32模组为例UART0通常固定用于下载和调试。TXD0 - GPIO1, RXD0 - GPIO3。强烈建议不要在应用中复用这两个引脚除非你完全清楚如何切换下载模式否则容易导致无法烧录程序。UART1默认引脚是GPIO9 (RXD1) 和 GPIO10 (TXD1)。但是GPIO9和GPIO10在内部连接了ESP32的SPI Flash芯片。如果你执意要使用这两个引脚作为UART1很可能会与SPI Flash通信冲突导致程序崩溃或无法启动。因此UART1必须重新映射到其他空闲的GPIO上。UART2默认引脚是GPIO16 (RXD2) 和 GPIO17 (TXD2)。这两个引脚是相对安全的可以直接使用。所以一个常见且安全的引脚分配方案是UART1映射到 GPIO4 (RXD) 和 GPIO5 (TXD)。UART2使用默认的 GPIO16 (RXD) 和 GPIO17 (TXD)。注意在选择引脚时务必确认该引脚没有被其他功能占用例如某些引脚在上电时有特殊电平要求或连接了板载LED。GPIO4和GPIO5在大多数开发板上都是空闲的适合用作UART。2.2 ESP-IDF工程配置与驱动基础确保你已安装好ESP-IDF开发环境V4.4或V5.0版本均可本文以V5.0为例。创建一个新的项目后我们首先需要关注menuconfig中的相关配置。虽然UART驱动默认已包含但了解其配置项有助于优化性能。打开终端进入项目目录运行idf.py menuconfig进入Component config - Driver configs - UART。确认UART是启用的默认就是。关注UART ISR in IRAM选项。如果启用UART中断服务程序ISR会被放在内部RAMIRAM中执行。这可以提升中断响应速度避免因为从Flash读取代码而产生的延迟对于高波特率或高数据吞吐量的场景有益。但会占用一部分IRAM空间。对于大多数应用波特率在115200及以下可以保持默认禁用。另一个重要选项是UART ringbuffer size。这是驱动层为每个UART维护的环形缓冲区Ring Buffer的大小。当数据到达而你的应用程序来不及立刻读取时数据会暂存于此。默认值可能较小如256字节。如果你预期会有数据突发比如一帧GPS数据有几百字节建议将这个值调大例如1024或2048以避免缓冲区溢出导致数据丢失。配置完成后我们就可以开始编写代码了。核心的头文件是driver/uart.h所有UART驱动的API都在这里。3. 驱动层初始化配置两个独立的UART实例初始化是驱动工作的基石。我们需要分别对UART1和UART2进行参数化配置。这里的关键是理解uart_config_t这个结构体它定义了串口的工作模式。#include driver/uart.h #include driver/gpio.h // 定义UART1和UART2的引脚 #define UART1_TXD_PIN (GPIO_NUM_5) #define UART1_RXD_PIN (GPIO_NUM_4) #define UART2_TXD_PIN (GPIO_NUM_17) #define UART2_RXD_PIN (GPIO_NUM_16) // 定义UART端口号 #define UART1_PORT_NUM (UART_NUM_1) #define UART2_PORT_NUM (UART_NUM_2) // 定义缓冲区大小 #define BUF_SIZE (1024) void uart_init() { // 配置UART1的参数 uart_config_t uart1_config { .baud_rate 115200, // 波特率 .data_bits UART_DATA_8_BITS, // 数据位 .parity UART_PARITY_DISABLE, // 校验位无 .stop_bits UART_STOP_BITS_1, // 停止位 .flow_ctrl UART_HW_FLOWCTRL_DISABLE, // 硬件流控禁用 .source_clk UART_SCLK_DEFAULT, // 时钟源默认APB时钟 }; // 配置UART2的参数可以与UART1不同 uart_config_t uart2_config { .baud_rate 9600, // 例如连接一个9600bps的老设备 .data_bits UART_DATA_8_BITS, .parity UART_PARITY_DISABLE, .stop_bits UART_STOP_BITS_1, .flow_ctrl UART_HW_FLOWCTRL_DISABLE, .source_clk UART_SCLK_DEFAULT, }; // 步骤1参数化配置UART驱动 ESP_ERROR_CHECK(uart_param_config(UART1_PORT_NUM, uart1_config)); ESP_ERROR_CHECK(uart_param_config(UART2_PORT_NUM, uart2_config)); // 步骤2设置UART的物理引脚重点为UART1重映射引脚 ESP_ERROR_CHECK(uart_set_pin(UART1_PORT_NUM, UART1_TXD_PIN, UART1_RXD_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE)); ESP_ERROR_CHECK(uart_set_pin(UART2_PORT_NUM, UART2_TXD_PIN, UART2_RXD_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE)); // 最后两个参数是RTS和CTS引脚如果不使用硬件流控填UART_PIN_NO_CHANGE即可。 // 步骤3安装UART驱动创建内部环形缓冲区并设置中断 // 参数解释uart_driver_install(端口号, 接收缓冲区大小, 发送缓冲区大小, 事件队列大小, 事件队列句柄, 中断分配标志) ESP_ERROR_CHECK(uart_driver_install(UART1_PORT_NUM, BUF_SIZE * 2, 0, 0, NULL, 0)); ESP_ERROR_CHECK(uart_driver_install(UART2_PORT_NUM, BUF_SIZE * 2, 0, 0, NULL, 0)); }关键点解析与避坑指南uart_set_pin是重映射的关键对于UART1我们通过这个函数将其TXD和RXD从默认的危险引脚GPIO9/10转移到了我们指定的安全引脚GPIO4/5。这是使用UART1的前提务必不能省略。uart_driver_install的参数rx_buffer_size这是驱动层内部环形缓冲区的大小。我设置为BUF_SIZE * 2即2048字节这是一个比较宽松的值可以有效应对数据突发。这个缓冲区是中断服务程序ISR和你的应用程序之间的桥梁。数据到达后硬件产生中断ISR会立刻将数据从硬件FIFO搬移到这个环形缓冲区然后立刻退出。你的应用代码可以在主循环或任务中从容地读取这个缓冲区。tx_buffer_size发送缓冲区大小。如果设为0则uart_write_bytes函数会变为阻塞模式直到所有数据都从软件缓冲区送入硬件FIFO才会返回。如果设置一个大小如512则uart_write_bytes可以非阻塞地将数据拷贝到发送缓冲区后立即返回由驱动在后台发送。对于简单的应用设为0阻塞发送更简单可靠。queue_size和uart_queue用于高级的事件驱动模式。我们可以创建一个FreeRTOS队列并在这里传入其句柄。这样当发生特定事件如接收到数据、发送完成、帧错误等时驱动会向这个队列发送一个事件消息。我们的任务可以阻塞在这个队列上等待事件这是一种非常高效的事件处理方式。本例中我们先设为0和NULL采用更基础的轮询读取方式。intr_alloc_flags中断分配标志。通常设为0使用默认中断优先级。对于实时性要求极高的场景可以设置ESP_INTR_FLAG_IRAM等标志。错误检查使用ESP_ERROR_CHECK宏包裹每个可能失败的驱动函数调用是一个好习惯。一旦配置失败如引脚冲突它会打印错误信息并中止程序帮你快速定位问题而不是让程序在后续运行中产生难以调试的异常行为。完成这三步两个UART的硬件和底层驱动就准备就绪了。接下来我们要解决如何从这两个串口高效、无误地读取数据。4. 数据读取策略轮询 vs 事件驱动与环形缓冲区实战数据读取是串口应用的核心。ESP-IDF的UART驱动提供了两种主流的读取方式轮询Polling和事件驱动Event-driven。选择哪种方式取决于你的应用场景和对实时性、CPU占用的要求。4.1 轮询方式简单直接适合低速率或非实时场景轮询就是在主循环或一个任务中定期检查串口接收缓冲区里是否有数据有就读出来。uart_read_bytes函数是轮询读取的关键。void uart_read_task(void *pvParameters) { uint8_t data1[BUF_SIZE]; uint8_t data2[BUF_SIZE]; while (1) { // 读取UART1的数据非阻塞模式 int len1 uart_read_bytes(UART1_PORT_NUM, data1, BUF_SIZE, 20 / portTICK_PERIOD_MS); if (len1 0) { // 处理从UART1接收到的数据len1是实际读取到的字节数 process_uart1_data(data1, len1); } // 读取UART2的数据 int len2 uart_read_bytes(UART2_PORT_NUM, data2, BUF_SIZE, 20 / portTICK_PERIOD_MS); if (len2 0) { // 处理从UART2接收到的数据 process_uart2_data(data2, len2); } // 短暂延时避免任务空转耗尽CPU vTaskDelay(10 / portTICK_PERIOD_MS); } }参数详解与注意事项uart_read_bytes(UART_NUM_1, data, BUF_SIZE, 20 / portTICK_PERIOD_MS)第一个参数UART端口号。第二个参数用于存储读取数据的缓冲区。第三个参数期望读取的最大字节数不要超过你提供的缓冲区大小。第四个参数TickToWait这是轮询方式的灵魂。它指定了函数等待数据的超时时间。如果设置为0函数会立刻返回无论有没有数据纯非阻塞。如果设置为portMAX_DELAY函数会一直阻塞直到有数据到来纯阻塞。这里我设置为20个Tick约20ms意味着函数会等待最多20ms期间一旦有数据就返回超时则返回0。这是一个折中的方案既不会长期阻塞又给了硬件一点响应时间。CPU占用问题轮询方式即使加了vTaskDelay任务也总是在活跃状态。如果波特率很低数据间隔长大部分时间都在空转会造成CPU资源的浪费。对于电池供电的设备这不是最优选择。数据实时性轮询的实时性取决于你执行uart_read_bytes的频率。如果任务被其他高优先级任务抢占或者你的轮询间隔太长可能会导致数据接收有延迟甚至在数据量很大时造成驱动层的环形缓冲区溢出。4.2 事件驱动方式高效节能推荐用于多数应用事件驱动模式利用FreeRTOS的队列Queue机制。UART驱动在后台运行当发生我们关心的事件比如收到任意数据、收到特定模式的数据、发送完成等时它会自动向一个队列发送事件消息。我们的任务只需要阻塞在这个队列上等待一旦有事件到来就进行处理。这种方式CPU占用率极低任务在等待时处于阻塞态不消耗CPU时间实时性也很好。首先我们需要修改初始化部分创建事件队列并启用事件驱动。#include freertos/FreeRTOS.h #include freertos/queue.h #include freertos/task.h QueueHandle_t uart1_queue; QueueHandle_t uart2_queue; void uart_init_with_event() { // ... 前面的uart_config_t配置和uart_param_config、uart_set_pin保持不变 ... // 创建事件队列 uart1_queue xQueueCreate(10, sizeof(uart_event_t)); // 队列深度10 uart2_queue xQueueCreate(10, sizeof(uart_event_t)); // 安装驱动时传入队列句柄和大小 ESP_ERROR_CHECK(uart_driver_install(UART1_PORT_NUM, BUF_SIZE * 2, 0, 10, uart1_queue, 0)); ESP_ERROR_CHECK(uart_driver_install(UART2_PORT_NUM, BUF_SIZE * 2, 0, 10, uart2_queue, 0)); // 可选设置事件类型。默认会接收所有事件。我们可以进行筛选。 // 例如只关心接收数据事件和帧错误事件 ESP_ERROR_CHECK(uart_enable_rx_intr(UART1_PORT_NUM)); // 确保接收中断是开启的默认就是 // 更精细的控制可以使用 uart_event_queue_config_t但通常默认即可。 }然后创建专门的任务来处理UART事件。void uart1_event_task(void *pvParameters) { uart_event_t event; uint8_t data[BUF_SIZE]; while (1) { // 阻塞等待UART1事件队列。有事件到来时此函数才会返回。 if (xQueueReceive(uart1_queue, (void *)event, portMAX_DELAY)) { switch (event.type) { case UART_DATA: // 这是最常用的事件收到数据了 // 注意event.size 表示此次事件触发时环形缓冲区中新增的数据长度可能不是全部 // 我们需要读取所有可用的数据 int len uart_read_bytes(UART1_PORT_NUM, data, BUF_SIZE, 0); // 0表示非阻塞有多少读多少 if (len 0) { process_uart1_data(data, len); } break; case UART_FIFO_OVF: // 硬件FIFO溢出通常波特率太高或中断响应太慢 ESP_LOGE(UART_TAG, UART1 HW FIFO Overflow!); // 遇到溢出最稳妥的办法是清空缓冲区避免后续数据全是错的 uart_flush_input(UART1_PORT_NUM); break; case UART_BUFFER_FULL: // 驱动层环形缓冲区满我们设置的rx_buffer_size不够大 ESP_LOGE(UART_TAG, UART1 Ring Buffer Full!); uart_flush_input(UART1_PORT_NUM); break; case UART_FRAME_ERR: // 帧错误如停止位不对 ESP_LOGW(UART_TAG, UART1 Frame Error); break; case UART_PARITY_ERR: // 奇偶校验错误 ESP_LOGW(UART_TAG, UART1 Parity Error); break; default: ESP_LOGI(UART_TAG, UART1 Event Type: %d, event.type); break; } } } vTaskDelete(NULL); } // 为UART2创建一个类似的任务 uart2_event_task事件驱动模式的优势低功耗任务在xQueueReceive处阻塞不消耗CPU周期。高实时性数据一到中断触发事件立刻入队任务被唤醒处理延迟非常短。便于错误处理各种错误溢出、帧错误等也以事件形式上报可以集中处理。结构清晰每个UART有自己独立的事件处理任务逻辑分离便于维护。实操心得对于绝大多数双串口应用我强烈推荐使用事件驱动模式。它更健壮更高效。event.size的含义需要理解它表示触发本次事件时环形缓冲区中新增的数据长度。例如你可能设置了UART_DATA_BREAK事件在收到128字节时触发那么event.size就是128。但对于默认的UART_DATA事件它可能在任何数据到达时触发event.size可能很小比如1。因此在UART_DATA事件中我们通常调用uart_read_bytes(..., 0)来读取缓冲区中所有可用的数据而不是只读event.size个字节。错误事件如UART_FIFO_OVF的处理很重要。一旦发生溢出后续接收的数据很可能错位。清空输入缓冲区 (uart_flush_input) 是一个粗暴但有效的恢复手段。更好的方法是优化你的代码提高任务优先级、增大缓冲区、降低波特率来避免溢出发生。5. 数据发送与流控确保数据完整送达发送数据相对接收要简单一些但也有一些细节需要注意特别是在双串口同时工作或高速率发送时。5.1 基础发送阻塞与非阻塞模式在初始化驱动时我们通过uart_driver_install的tx_buffer_size参数决定了发送模式。阻塞发送tx_buffer_size 0// 向UART1发送字符串。函数会等待所有数据都送入硬件FIFO后才返回。 const char *test_str Hello from UART1\r\n; uart_write_bytes(UART1_PORT_NUM, test_str, strlen(test_str));这种方式代码简单能保证数据按顺序完整发送。缺点是在发送大量数据时你的任务会被阻塞无法处理其他事情比如响应另一个串口的数据。对于短消息或非实时系统这没问题。非阻塞发送tx_buffer_size 0// 安装驱动时指定发送缓冲区大小 ESP_ERROR_CHECK(uart_driver_install(UART1_PORT_NUM, BUF_SIZE * 2, 512, 10, uart1_queue, 0)); // 发送数据。数据被拷贝到512字节的发送缓冲区后函数立即返回。 uart_write_bytes(UART1_PORT_NUM, large_data, large_data_len); // 此时数据可能还没真正从TX引脚发出而是在驱动后台发送。非阻塞发送提高了任务响应性。但你需要关注发送缓冲区是否已满。可以通过uart_wait_tx_done函数来等待发送完成或者监听UART_TX_DONE事件如果启用了事件队列。// 等待UART1的最后一次uart_write_bytes调用数据发送完成最多等待1000个Tick。 esp_err_t err uart_wait_tx_done(UART1_PORT_NUM, 1000 / portTICK_PERIOD_MS); if (err ESP_ERR_TIMEOUT) { ESP_LOGE(UART_TAG, UART1 Send Timeout); }5.2 硬件流控RTS/CTS的必要性与配置当两个设备通过串口通信且速度不匹配时例如ESP32发送很快但另一端的MCU处理慢就需要流控来防止数据丢失。硬件流控通过RTSRequest To Send和CTSClear To Send两根信号线实现。RTS输出本设备准备好接收数据时拉低RTS信号有效。当接收缓冲区快满时拉高RTS无效告诉对方“暂停发送”。CTS输入本设备在发送数据前会检查CTS信号。如果CTS为高无效表示对方没准备好则暂停发送。在ESP-IDF中启用硬件流控uart_config_t uart_config { .baud_rate 115200, .data_bits UART_DATA_8_BITS, .parity UART_PARITY_DISABLE, .stop_bits UART_STOP_BITS_1, .flow_ctrl UART_HW_FLOWCTRL_CTS_RTS, // 启用RTS/CTS硬件流控 .source_clk UART_SCLK_DEFAULT, }; ESP_ERROR_CHECK(uart_param_config(UART_NUM_1, uart_config)); // 设置引脚时指定RTS和CTS的引脚号 ESP_ERROR_CHECK(uart_set_pin(UART_NUM_1, UART1_TXD_PIN, UART1_RXD_PIN, UART1_RTS_PIN, UART1_CTS_PIN));使用建议在与PC通信或与高速外设如4G模块通信时如果数据量大强烈建议启用硬件流控。确保连接正确本设备的RTS连接对端的CTS本设备的CTS连接对端的RTS。软件流控XON/XOFF在嵌入式领域较少使用且不适合二进制数据流硬件流控是更可靠的选择。6. 实战案例双串口数据透传与协议解析理论讲完了我们来看一个综合性的实战案例实现一个简单的“双串口数据桥接器”。假设UART1连接一个GPS模块输出NMEA 0183协议语句UART2连接一个无线模块如LoRa或Wi-Fi。我们的目标是从UART1读取GPS数据。简单解析GPS数据提取经纬度信息可选用于本地处理或显示。将原始的或解析后的GPS数据通过UART2转发出去。这个案例涵盖了双串口的初始化、事件驱动读取、数据处理和发送。// uart_bridge_example.c #include stdio.h #include string.h #include freertos/FreeRTOS.h #include freertos/task.h #include freertos/queue.h #include driver/uart.h #include esp_log.h static const char *TAG UART_BRIDGE; // 引脚定义 #define UART1_NUM UART_NUM_1 #define UART1_TXD_PIN GPIO_NUM_5 #define UART1_RXD_PIN GPIO_NUM_4 #define UART1_BAUD 9600 // 典型GPS模块波特率 #define UART2_NUM UART_NUM_2 #define UART2_TXD_PIN GPIO_NUM_17 #define UART2_RXD_PIN GPIO_NUM_16 #define UART2_BAUD 115200 // 无线模块常用波特率 #define BUF_SIZE (1024) static QueueHandle_t uart1_queue; static QueueHandle_t uart2_queue; // 简单的NMEA语句检查仅检查起始符$和校验和分隔符* static bool is_valid_nmea_start(const char *line) { return (line[0] $); } // 解析GPRMC语句提取经纬度简化版实际应用需完整解析校验和 static void parse_gprmc_and_log(const char *line) { // 示例$GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,130998,011.3,E*62 if (strstr(line, $GPRMC) ! line) { // 简单判断是否为GPRMC语句 return; } char status; float lat, lon; // 这里省略了复杂的字符串分割和解析逻辑实际项目中建议使用sscanf或自定义解析器 // 例如sscanf(line, $GPRMC,%*f,%c,%f,%*c,%f,%*c, ..., status, lat, lon); if (status A) { // A 数据有效 ESP_LOGI(TAG, GPS Valid. Lat: %.4f, Lon: %.4f, lat, lon); } else { ESP_LOGW(TAG, GPS Invalid (Status: %c), status); } } static void uart1_event_task(void *arg) { uart_event_t event; uint8_t data[BUF_SIZE]; while (1) { if (xQueueReceive(uart1_queue, (void *)event, portMAX_DELAY)) { switch (event.type) { case UART_DATA: { int len uart_read_bytes(UART1_NUM, data, BUF_SIZE - 1, 0); // 留一位给\0 if (len 0) { data[len] \0; // 转换为C字符串 // 1. 本地解析并打印GPS信息可选 // 假设数据是一行行来的GPS模块通常如此这里简化处理实际可能需要组帧。 if (is_valid_nmea_start((char*)data)) { parse_gprmc_and_log((char*)data); } // 2. 将原始数据转发到UART2 uart_write_bytes(UART2_NUM, (const char*)data, len); ESP_LOGI(TAG, Forwarded %d bytes from UART1 to UART2, len); } break; } case UART_FIFO_OVF: case UART_BUFFER_FULL: ESP_LOGE(TAG, UART1 Buffer Overflow, flushing.); uart_flush_input(UART1_NUM); break; default: break; } } } } static void uart2_event_task(void *arg) { // UART2的任务这里假设它接收来自无线模块的配置命令并回显或处理。 // 例如收到特定命令后改变GPS数据的转发频率。 uart_event_t event; uint8_t data[BUF_SIZE]; while (1) { if (xQueueReceive(uart2_queue, (void *)event, portMAX_DELAY)) { if (event.type UART_DATA) { int len uart_read_bytes(UART2_NUM, data, BUF_SIZE - 1, 0); if (len 0) { data[len] \0; ESP_LOGI(TAG, UART2 Received: %s, data); // 简单的命令处理示例 if (strstr((char*)data, SET LED ON)) { gpio_set_level(LED_GPIO, 1); uart_write_bytes(UART2_NUM, LED ON OK\r\n, 11); } } } } } } void app_main(void) { // 1. 初始化UART1 uart_config_t uart1_cfg { .baud_rate UART1_BAUD, .data_bits UART_DATA_8_BITS, .parity UART_PARITY_DISABLE, .stop_bits UART_STOP_BITS_1, .flow_ctrl UART_HW_FLOWCTRL_DISABLE, }; uart_param_config(UART1_NUM, uart1_cfg); uart_set_pin(UART1_NUM, UART1_TXD_PIN, UART1_RXD_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE); uart1_queue xQueueCreate(20, sizeof(uart_event_t)); uart_driver_install(UART1_NUM, BUF_SIZE * 2, 0, 20, uart1_queue, 0); // 2. 初始化UART2 uart_config_t uart2_cfg { .baud_rate UART2_BAUD, .data_bits UART_DATA_8_BITS, .parity UART_PARITY_DISABLE, .stop_bits UART_STOP_BITS_1, .flow_ctrl UART_HW_FLOWCTRL_DISABLE, }; uart_param_config(UART2_NUM, uart2_cfg); uart_set_pin(UART2_NUM, UART2_TXD_PIN, UART2_RXD_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE); uart2_queue xQueueCreate(20, sizeof(uart_event_t)); uart_driver_install(UART2_NUM, BUF_SIZE * 2, 0, 20, uart2_queue, 0); // 3. 创建任务处理UART事件 xTaskCreate(uart1_event_task, uart1_task, 4096, NULL, configMAX_PRIORITIES-2, NULL); xTaskCreate(uart2_event_task, uart2_task, 4096, NULL, configMAX_PRIORITIES-2, NULL); ESP_LOGI(TAG, UART Bridge Started. UART1(GPS%d) - UART2(Wireless%d), UART1_BAUD, UART2_BAUD); }案例要点与扩展数据完整性本例中假设GPS数据是完整的行。现实中数据可能被拆分成多个UART_DATA事件。你需要一个缓冲区来组帧比如寻找换行符\n作为一帧的结束。任务优先级两个UART事件任务的优先级我设置为configMAX_PRIORITIES-2这是一个较高的优先级确保串口数据能及时处理。但要注意如果处理逻辑非常耗时比如复杂的协议解析可能会阻塞另一个串口的任务。如果出现这种情况可以考虑将耗时的处理如解析、存储移交给一个低优先级的任务事件任务只负责快速读取和投递数据。流控如果UART2连接的无线模块发送较慢而GPS数据源源不断可能导致UART2的发送缓冲区积压。可以考虑在转发前检查UART2的发送缓冲区剩余空间 (uart_wait_tx_done或监听UART_TX_DONE事件)或者直接为UART2启用硬件流控。错误恢复案例中包含了缓冲区溢出的错误处理清空缓冲区。在实际产品中你可能需要更精细的恢复策略比如记录错误次数超过阈值后重启串口驱动。7. 深度避坑多串口开发中的常见问题与解决方案即使按照指南操作在实际开发中你还是可能会遇到一些棘手的问题。下面是我在多个项目中总结出来的“坑点”和解决方案。7.1 中断冲突与优先级管理ESP32的三个UART共享同一组中断源。虽然驱动层已经做了封装但在极端高负载或不当配置下仍可能出问题。现象一个串口大量收数时另一个串口的数据丢失或响应变慢。根因UART中断服务程序ISR执行时间过长或者被更高优先级的中断如Wi-Fi/蓝牙中断抢占。解决方案优化ISR确保你的UART事件处理任务uart_event_task尽快从队列中取走事件。不要在ISR或事件任务中做复杂运算、打印大量日志ESP_LOGI本身比较耗时、或调用可能阻塞的API。调整中断优先级在uart_driver_install的intr_alloc_flags参数中可以尝试设置ESP_INTR_FLAG_IRAM将ISR放入IRAM并可能结合优先级参数。但调整中断优先级是高级操作需谨慎不当设置可能导致系统不稳定。对于大多数应用保持默认0即可。核心绑定如果使用双核ESP32如ESP32-S3可以考虑将两个UART的处理任务分别绑定到不同的CPU核心上减少核心间的任务切换开销。使用xTaskCreatePinnedToCore创建任务。7.2 电源管理与睡眠唤醒当ESP32进入Light-sleep或Deep-sleep模式时外设包括UART会被关闭以省电。唤醒后UART需要重新初始化。现象设备睡眠唤醒后串口无法正常工作。解决方案在进入睡眠前调用uart_driver_delete(UART_NUM_1)来卸载驱动释放资源。从睡眠唤醒后在app_main或唤醒回调函数中重新执行完整的UART初始化流程uart_param_config,uart_set_pin,uart_driver_install。特别注意引脚状态有些GPIO在睡眠状态下可以配置为“保持”状态但唤醒后仍需重新配置为UART功能。7.3 引脚冲突与功能复用这是新手最容易踩的坑尤其是使用UART1时。问题复现将UART1的TXD/RXD配置到GPIO9/GPIO10程序运行异常甚至无法烧录。解决方案绝对避免使用GPIO6至GPIO11这些引脚通常与内部Flash/SRAM连接复用为功能引脚极易导致系统崩溃。查阅开发板原理图确认你选择的引脚没有连接板载其他器件如LED、按钮且该引脚在上电时没有特殊状态要求例如某些引脚在启动时必须为高电平或低电平。使用uart_set_pin前检查可以使用gpio_reset_pin来将引脚复位到默认状态然后再配置为UART功能。7.4 波特率误差与通信不稳定现象与某些特定设备尤其是老式设备或晶振精度不高的模块通信时出现乱码或偶发性数据错误。根因ESP32的UART波特率发生器基于APB时钟通常80MHz分频可能存在微小误差。对于标准波特率如9600, 115200误差极小。但对于非标准波特率或者对方设备时钟误差较大时累积误差可能导致采样点偏移。解决方案计算实际波特率使用uart_get_baudrate函数可以获取驱动实际设置成功的波特率与目标值对比。调整时钟源uart_config_t中的source_clk可以尝试改为UART_SCLK_APB默认或UART_SCLK_RTC精度可能更低不推荐。对于高精度需求ESP32支持外部时钟源但配置复杂。软件容错在协议层增加校验如CRC并实现重传机制。这是提高通信鲁棒性的根本方法。降低波特率在长距离、干扰大的RS-485应用中适当降低波特率可以提高稳定性。7.5 驱动卸载与资源泄漏在动态创建/销毁UART连接例如实现一个可配置的串口服务器时务必正确管理资源。正确流程停止相关数据收发任务。调用uart_driver_delete(uart_num)。这个函数会禁用UART中断。释放驱动层创建的环形缓冲区内存。复位UART寄存器。释放事件队列如果是由驱动创建的。之后该UART端口可以再次被初始化使用。常见错误只调用uart_driver_uninstall旧版API或什么都不做就直接重新初始化可能导致内存泄漏或中断状态混乱。uart_driver_delete是V4.4版本推荐的清理函数。通过理解这些底层机制和避坑指南你就能在ESP32上构建出稳定、高效的双串口乃至多串口应用。从简单的数据透传到复杂的多协议网关扎实的驱动层理解是这一切的基础。 ESP32多串口驱动开发：从引脚配置到事件驱动实战
1. 项目缘起为什么ESP32需要用好两个串口在嵌入式开发里串口UART的地位大概就相当于我们日常交流的嘴巴和耳朵。它简单、可靠、历史悠久是单片机与外部世界沟通最基础、最常用的方式。ESP32这颗芯片功能强大集成了Wi-Fi和蓝牙但很多开发者上手后第一个要打交道的往往还是串口——无论是用来打印调试信息还是连接GPS模块、传感器、蓝牙转串口模块甚至是与另一个单片机“对话”。ESP32有一个非常实用的特性它内置了三个硬件UART控制器UART0, UART1, UART2。其中UART0通常预留给芯片的USB转串口下载和调试也就是我们通过USB线连接电脑时用的那个串口。那么剩下的UART1和UART2就是我们可以在项目中自由配置和使用的“生产力工具”。我之所以想专门聊聊这个话题是因为在实际项目中只用一个串口的情况越来越少。一个典型的场景是你需要用UART1以较高的波特率接收来自传感器的连续数据流同时用UART2以较低的波特率向一个显示屏或另一个控制器发送状态信息。如果处理不好两个串口的中断相互干扰或者数据接收不完整就会让整个系统变得不稳定。网上很多基础的例程只演示单个串口的收发一旦涉及到多串口协同特别是基于ESP-IDF乐鑫官方物联网开发框架的“驱动篇”操作不少朋友就会遇到配置冲突、资源竞争、数据错乱这些坑。所以这篇内容的目标很明确不满足于点亮一个串口。我们要深入ESP-IDF的驱动层把UART1和UART2这两个串口都稳稳地驱动起来让它们各司其职互不干扰并且能高效、可靠地处理数据。我会从最基础的引脚配置、驱动安装讲起深入到中断处理、环形缓冲区管理最后分享一个双串口数据透传的实战案例以及我趟过的那些坑。无论你是刚接触ESP32还是正在为多串口通信烦恼希望这篇“驱动篇”的深度解析能给你带来实实在在的帮助。2. 硬件与软件准备引脚选择与工程配置在写第一行代码之前我们必须先搞清楚硬件连接和软件环境。这一步看似简单但选错了引脚或者配置不对后面所有工作都是白费力气。2.1 ESP32的UART引脚映射并非所有引脚都能用ESP32的UART引脚是高度可配置的但这并不意味着所有GPIO都可以随意用作TXD发送和RXD接收。我们需要查阅技术手册或参考uart.h头文件中的宏定义。以我手头常用的ESP32-WROOM-32模组为例UART0通常固定用于下载和调试。TXD0 - GPIO1, RXD0 - GPIO3。强烈建议不要在应用中复用这两个引脚除非你完全清楚如何切换下载模式否则容易导致无法烧录程序。UART1默认引脚是GPIO9 (RXD1) 和 GPIO10 (TXD1)。但是GPIO9和GPIO10在内部连接了ESP32的SPI Flash芯片。如果你执意要使用这两个引脚作为UART1很可能会与SPI Flash通信冲突导致程序崩溃或无法启动。因此UART1必须重新映射到其他空闲的GPIO上。UART2默认引脚是GPIO16 (RXD2) 和 GPIO17 (TXD2)。这两个引脚是相对安全的可以直接使用。所以一个常见且安全的引脚分配方案是UART1映射到 GPIO4 (RXD) 和 GPIO5 (TXD)。UART2使用默认的 GPIO16 (RXD) 和 GPIO17 (TXD)。注意在选择引脚时务必确认该引脚没有被其他功能占用例如某些引脚在上电时有特殊电平要求或连接了板载LED。GPIO4和GPIO5在大多数开发板上都是空闲的适合用作UART。2.2 ESP-IDF工程配置与驱动基础确保你已安装好ESP-IDF开发环境V4.4或V5.0版本均可本文以V5.0为例。创建一个新的项目后我们首先需要关注menuconfig中的相关配置。虽然UART驱动默认已包含但了解其配置项有助于优化性能。打开终端进入项目目录运行idf.py menuconfig进入Component config - Driver configs - UART。确认UART是启用的默认就是。关注UART ISR in IRAM选项。如果启用UART中断服务程序ISR会被放在内部RAMIRAM中执行。这可以提升中断响应速度避免因为从Flash读取代码而产生的延迟对于高波特率或高数据吞吐量的场景有益。但会占用一部分IRAM空间。对于大多数应用波特率在115200及以下可以保持默认禁用。另一个重要选项是UART ringbuffer size。这是驱动层为每个UART维护的环形缓冲区Ring Buffer的大小。当数据到达而你的应用程序来不及立刻读取时数据会暂存于此。默认值可能较小如256字节。如果你预期会有数据突发比如一帧GPS数据有几百字节建议将这个值调大例如1024或2048以避免缓冲区溢出导致数据丢失。配置完成后我们就可以开始编写代码了。核心的头文件是driver/uart.h所有UART驱动的API都在这里。3. 驱动层初始化配置两个独立的UART实例初始化是驱动工作的基石。我们需要分别对UART1和UART2进行参数化配置。这里的关键是理解uart_config_t这个结构体它定义了串口的工作模式。#include driver/uart.h #include driver/gpio.h // 定义UART1和UART2的引脚 #define UART1_TXD_PIN (GPIO_NUM_5) #define UART1_RXD_PIN (GPIO_NUM_4) #define UART2_TXD_PIN (GPIO_NUM_17) #define UART2_RXD_PIN (GPIO_NUM_16) // 定义UART端口号 #define UART1_PORT_NUM (UART_NUM_1) #define UART2_PORT_NUM (UART_NUM_2) // 定义缓冲区大小 #define BUF_SIZE (1024) void uart_init() { // 配置UART1的参数 uart_config_t uart1_config { .baud_rate 115200, // 波特率 .data_bits UART_DATA_8_BITS, // 数据位 .parity UART_PARITY_DISABLE, // 校验位无 .stop_bits UART_STOP_BITS_1, // 停止位 .flow_ctrl UART_HW_FLOWCTRL_DISABLE, // 硬件流控禁用 .source_clk UART_SCLK_DEFAULT, // 时钟源默认APB时钟 }; // 配置UART2的参数可以与UART1不同 uart_config_t uart2_config { .baud_rate 9600, // 例如连接一个9600bps的老设备 .data_bits UART_DATA_8_BITS, .parity UART_PARITY_DISABLE, .stop_bits UART_STOP_BITS_1, .flow_ctrl UART_HW_FLOWCTRL_DISABLE, .source_clk UART_SCLK_DEFAULT, }; // 步骤1参数化配置UART驱动 ESP_ERROR_CHECK(uart_param_config(UART1_PORT_NUM, uart1_config)); ESP_ERROR_CHECK(uart_param_config(UART2_PORT_NUM, uart2_config)); // 步骤2设置UART的物理引脚重点为UART1重映射引脚 ESP_ERROR_CHECK(uart_set_pin(UART1_PORT_NUM, UART1_TXD_PIN, UART1_RXD_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE)); ESP_ERROR_CHECK(uart_set_pin(UART2_PORT_NUM, UART2_TXD_PIN, UART2_RXD_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE)); // 最后两个参数是RTS和CTS引脚如果不使用硬件流控填UART_PIN_NO_CHANGE即可。 // 步骤3安装UART驱动创建内部环形缓冲区并设置中断 // 参数解释uart_driver_install(端口号, 接收缓冲区大小, 发送缓冲区大小, 事件队列大小, 事件队列句柄, 中断分配标志) ESP_ERROR_CHECK(uart_driver_install(UART1_PORT_NUM, BUF_SIZE * 2, 0, 0, NULL, 0)); ESP_ERROR_CHECK(uart_driver_install(UART2_PORT_NUM, BUF_SIZE * 2, 0, 0, NULL, 0)); }关键点解析与避坑指南uart_set_pin是重映射的关键对于UART1我们通过这个函数将其TXD和RXD从默认的危险引脚GPIO9/10转移到了我们指定的安全引脚GPIO4/5。这是使用UART1的前提务必不能省略。uart_driver_install的参数rx_buffer_size这是驱动层内部环形缓冲区的大小。我设置为BUF_SIZE * 2即2048字节这是一个比较宽松的值可以有效应对数据突发。这个缓冲区是中断服务程序ISR和你的应用程序之间的桥梁。数据到达后硬件产生中断ISR会立刻将数据从硬件FIFO搬移到这个环形缓冲区然后立刻退出。你的应用代码可以在主循环或任务中从容地读取这个缓冲区。tx_buffer_size发送缓冲区大小。如果设为0则uart_write_bytes函数会变为阻塞模式直到所有数据都从软件缓冲区送入硬件FIFO才会返回。如果设置一个大小如512则uart_write_bytes可以非阻塞地将数据拷贝到发送缓冲区后立即返回由驱动在后台发送。对于简单的应用设为0阻塞发送更简单可靠。queue_size和uart_queue用于高级的事件驱动模式。我们可以创建一个FreeRTOS队列并在这里传入其句柄。这样当发生特定事件如接收到数据、发送完成、帧错误等时驱动会向这个队列发送一个事件消息。我们的任务可以阻塞在这个队列上等待事件这是一种非常高效的事件处理方式。本例中我们先设为0和NULL采用更基础的轮询读取方式。intr_alloc_flags中断分配标志。通常设为0使用默认中断优先级。对于实时性要求极高的场景可以设置ESP_INTR_FLAG_IRAM等标志。错误检查使用ESP_ERROR_CHECK宏包裹每个可能失败的驱动函数调用是一个好习惯。一旦配置失败如引脚冲突它会打印错误信息并中止程序帮你快速定位问题而不是让程序在后续运行中产生难以调试的异常行为。完成这三步两个UART的硬件和底层驱动就准备就绪了。接下来我们要解决如何从这两个串口高效、无误地读取数据。4. 数据读取策略轮询 vs 事件驱动与环形缓冲区实战数据读取是串口应用的核心。ESP-IDF的UART驱动提供了两种主流的读取方式轮询Polling和事件驱动Event-driven。选择哪种方式取决于你的应用场景和对实时性、CPU占用的要求。4.1 轮询方式简单直接适合低速率或非实时场景轮询就是在主循环或一个任务中定期检查串口接收缓冲区里是否有数据有就读出来。uart_read_bytes函数是轮询读取的关键。void uart_read_task(void *pvParameters) { uint8_t data1[BUF_SIZE]; uint8_t data2[BUF_SIZE]; while (1) { // 读取UART1的数据非阻塞模式 int len1 uart_read_bytes(UART1_PORT_NUM, data1, BUF_SIZE, 20 / portTICK_PERIOD_MS); if (len1 0) { // 处理从UART1接收到的数据len1是实际读取到的字节数 process_uart1_data(data1, len1); } // 读取UART2的数据 int len2 uart_read_bytes(UART2_PORT_NUM, data2, BUF_SIZE, 20 / portTICK_PERIOD_MS); if (len2 0) { // 处理从UART2接收到的数据 process_uart2_data(data2, len2); } // 短暂延时避免任务空转耗尽CPU vTaskDelay(10 / portTICK_PERIOD_MS); } }参数详解与注意事项uart_read_bytes(UART_NUM_1, data, BUF_SIZE, 20 / portTICK_PERIOD_MS)第一个参数UART端口号。第二个参数用于存储读取数据的缓冲区。第三个参数期望读取的最大字节数不要超过你提供的缓冲区大小。第四个参数TickToWait这是轮询方式的灵魂。它指定了函数等待数据的超时时间。如果设置为0函数会立刻返回无论有没有数据纯非阻塞。如果设置为portMAX_DELAY函数会一直阻塞直到有数据到来纯阻塞。这里我设置为20个Tick约20ms意味着函数会等待最多20ms期间一旦有数据就返回超时则返回0。这是一个折中的方案既不会长期阻塞又给了硬件一点响应时间。CPU占用问题轮询方式即使加了vTaskDelay任务也总是在活跃状态。如果波特率很低数据间隔长大部分时间都在空转会造成CPU资源的浪费。对于电池供电的设备这不是最优选择。数据实时性轮询的实时性取决于你执行uart_read_bytes的频率。如果任务被其他高优先级任务抢占或者你的轮询间隔太长可能会导致数据接收有延迟甚至在数据量很大时造成驱动层的环形缓冲区溢出。4.2 事件驱动方式高效节能推荐用于多数应用事件驱动模式利用FreeRTOS的队列Queue机制。UART驱动在后台运行当发生我们关心的事件比如收到任意数据、收到特定模式的数据、发送完成等时它会自动向一个队列发送事件消息。我们的任务只需要阻塞在这个队列上等待一旦有事件到来就进行处理。这种方式CPU占用率极低任务在等待时处于阻塞态不消耗CPU时间实时性也很好。首先我们需要修改初始化部分创建事件队列并启用事件驱动。#include freertos/FreeRTOS.h #include freertos/queue.h #include freertos/task.h QueueHandle_t uart1_queue; QueueHandle_t uart2_queue; void uart_init_with_event() { // ... 前面的uart_config_t配置和uart_param_config、uart_set_pin保持不变 ... // 创建事件队列 uart1_queue xQueueCreate(10, sizeof(uart_event_t)); // 队列深度10 uart2_queue xQueueCreate(10, sizeof(uart_event_t)); // 安装驱动时传入队列句柄和大小 ESP_ERROR_CHECK(uart_driver_install(UART1_PORT_NUM, BUF_SIZE * 2, 0, 10, uart1_queue, 0)); ESP_ERROR_CHECK(uart_driver_install(UART2_PORT_NUM, BUF_SIZE * 2, 0, 10, uart2_queue, 0)); // 可选设置事件类型。默认会接收所有事件。我们可以进行筛选。 // 例如只关心接收数据事件和帧错误事件 ESP_ERROR_CHECK(uart_enable_rx_intr(UART1_PORT_NUM)); // 确保接收中断是开启的默认就是 // 更精细的控制可以使用 uart_event_queue_config_t但通常默认即可。 }然后创建专门的任务来处理UART事件。void uart1_event_task(void *pvParameters) { uart_event_t event; uint8_t data[BUF_SIZE]; while (1) { // 阻塞等待UART1事件队列。有事件到来时此函数才会返回。 if (xQueueReceive(uart1_queue, (void *)event, portMAX_DELAY)) { switch (event.type) { case UART_DATA: // 这是最常用的事件收到数据了 // 注意event.size 表示此次事件触发时环形缓冲区中新增的数据长度可能不是全部 // 我们需要读取所有可用的数据 int len uart_read_bytes(UART1_PORT_NUM, data, BUF_SIZE, 0); // 0表示非阻塞有多少读多少 if (len 0) { process_uart1_data(data, len); } break; case UART_FIFO_OVF: // 硬件FIFO溢出通常波特率太高或中断响应太慢 ESP_LOGE(UART_TAG, UART1 HW FIFO Overflow!); // 遇到溢出最稳妥的办法是清空缓冲区避免后续数据全是错的 uart_flush_input(UART1_PORT_NUM); break; case UART_BUFFER_FULL: // 驱动层环形缓冲区满我们设置的rx_buffer_size不够大 ESP_LOGE(UART_TAG, UART1 Ring Buffer Full!); uart_flush_input(UART1_PORT_NUM); break; case UART_FRAME_ERR: // 帧错误如停止位不对 ESP_LOGW(UART_TAG, UART1 Frame Error); break; case UART_PARITY_ERR: // 奇偶校验错误 ESP_LOGW(UART_TAG, UART1 Parity Error); break; default: ESP_LOGI(UART_TAG, UART1 Event Type: %d, event.type); break; } } } vTaskDelete(NULL); } // 为UART2创建一个类似的任务 uart2_event_task事件驱动模式的优势低功耗任务在xQueueReceive处阻塞不消耗CPU周期。高实时性数据一到中断触发事件立刻入队任务被唤醒处理延迟非常短。便于错误处理各种错误溢出、帧错误等也以事件形式上报可以集中处理。结构清晰每个UART有自己独立的事件处理任务逻辑分离便于维护。实操心得对于绝大多数双串口应用我强烈推荐使用事件驱动模式。它更健壮更高效。event.size的含义需要理解它表示触发本次事件时环形缓冲区中新增的数据长度。例如你可能设置了UART_DATA_BREAK事件在收到128字节时触发那么event.size就是128。但对于默认的UART_DATA事件它可能在任何数据到达时触发event.size可能很小比如1。因此在UART_DATA事件中我们通常调用uart_read_bytes(..., 0)来读取缓冲区中所有可用的数据而不是只读event.size个字节。错误事件如UART_FIFO_OVF的处理很重要。一旦发生溢出后续接收的数据很可能错位。清空输入缓冲区 (uart_flush_input) 是一个粗暴但有效的恢复手段。更好的方法是优化你的代码提高任务优先级、增大缓冲区、降低波特率来避免溢出发生。5. 数据发送与流控确保数据完整送达发送数据相对接收要简单一些但也有一些细节需要注意特别是在双串口同时工作或高速率发送时。5.1 基础发送阻塞与非阻塞模式在初始化驱动时我们通过uart_driver_install的tx_buffer_size参数决定了发送模式。阻塞发送tx_buffer_size 0// 向UART1发送字符串。函数会等待所有数据都送入硬件FIFO后才返回。 const char *test_str Hello from UART1\r\n; uart_write_bytes(UART1_PORT_NUM, test_str, strlen(test_str));这种方式代码简单能保证数据按顺序完整发送。缺点是在发送大量数据时你的任务会被阻塞无法处理其他事情比如响应另一个串口的数据。对于短消息或非实时系统这没问题。非阻塞发送tx_buffer_size 0// 安装驱动时指定发送缓冲区大小 ESP_ERROR_CHECK(uart_driver_install(UART1_PORT_NUM, BUF_SIZE * 2, 512, 10, uart1_queue, 0)); // 发送数据。数据被拷贝到512字节的发送缓冲区后函数立即返回。 uart_write_bytes(UART1_PORT_NUM, large_data, large_data_len); // 此时数据可能还没真正从TX引脚发出而是在驱动后台发送。非阻塞发送提高了任务响应性。但你需要关注发送缓冲区是否已满。可以通过uart_wait_tx_done函数来等待发送完成或者监听UART_TX_DONE事件如果启用了事件队列。// 等待UART1的最后一次uart_write_bytes调用数据发送完成最多等待1000个Tick。 esp_err_t err uart_wait_tx_done(UART1_PORT_NUM, 1000 / portTICK_PERIOD_MS); if (err ESP_ERR_TIMEOUT) { ESP_LOGE(UART_TAG, UART1 Send Timeout); }5.2 硬件流控RTS/CTS的必要性与配置当两个设备通过串口通信且速度不匹配时例如ESP32发送很快但另一端的MCU处理慢就需要流控来防止数据丢失。硬件流控通过RTSRequest To Send和CTSClear To Send两根信号线实现。RTS输出本设备准备好接收数据时拉低RTS信号有效。当接收缓冲区快满时拉高RTS无效告诉对方“暂停发送”。CTS输入本设备在发送数据前会检查CTS信号。如果CTS为高无效表示对方没准备好则暂停发送。在ESP-IDF中启用硬件流控uart_config_t uart_config { .baud_rate 115200, .data_bits UART_DATA_8_BITS, .parity UART_PARITY_DISABLE, .stop_bits UART_STOP_BITS_1, .flow_ctrl UART_HW_FLOWCTRL_CTS_RTS, // 启用RTS/CTS硬件流控 .source_clk UART_SCLK_DEFAULT, }; ESP_ERROR_CHECK(uart_param_config(UART_NUM_1, uart_config)); // 设置引脚时指定RTS和CTS的引脚号 ESP_ERROR_CHECK(uart_set_pin(UART_NUM_1, UART1_TXD_PIN, UART1_RXD_PIN, UART1_RTS_PIN, UART1_CTS_PIN));使用建议在与PC通信或与高速外设如4G模块通信时如果数据量大强烈建议启用硬件流控。确保连接正确本设备的RTS连接对端的CTS本设备的CTS连接对端的RTS。软件流控XON/XOFF在嵌入式领域较少使用且不适合二进制数据流硬件流控是更可靠的选择。6. 实战案例双串口数据透传与协议解析理论讲完了我们来看一个综合性的实战案例实现一个简单的“双串口数据桥接器”。假设UART1连接一个GPS模块输出NMEA 0183协议语句UART2连接一个无线模块如LoRa或Wi-Fi。我们的目标是从UART1读取GPS数据。简单解析GPS数据提取经纬度信息可选用于本地处理或显示。将原始的或解析后的GPS数据通过UART2转发出去。这个案例涵盖了双串口的初始化、事件驱动读取、数据处理和发送。// uart_bridge_example.c #include stdio.h #include string.h #include freertos/FreeRTOS.h #include freertos/task.h #include freertos/queue.h #include driver/uart.h #include esp_log.h static const char *TAG UART_BRIDGE; // 引脚定义 #define UART1_NUM UART_NUM_1 #define UART1_TXD_PIN GPIO_NUM_5 #define UART1_RXD_PIN GPIO_NUM_4 #define UART1_BAUD 9600 // 典型GPS模块波特率 #define UART2_NUM UART_NUM_2 #define UART2_TXD_PIN GPIO_NUM_17 #define UART2_RXD_PIN GPIO_NUM_16 #define UART2_BAUD 115200 // 无线模块常用波特率 #define BUF_SIZE (1024) static QueueHandle_t uart1_queue; static QueueHandle_t uart2_queue; // 简单的NMEA语句检查仅检查起始符$和校验和分隔符* static bool is_valid_nmea_start(const char *line) { return (line[0] $); } // 解析GPRMC语句提取经纬度简化版实际应用需完整解析校验和 static void parse_gprmc_and_log(const char *line) { // 示例$GPRMC,081836,A,3751.65,S,14507.36,E,000.0,360.0,130998,011.3,E*62 if (strstr(line, $GPRMC) ! line) { // 简单判断是否为GPRMC语句 return; } char status; float lat, lon; // 这里省略了复杂的字符串分割和解析逻辑实际项目中建议使用sscanf或自定义解析器 // 例如sscanf(line, $GPRMC,%*f,%c,%f,%*c,%f,%*c, ..., status, lat, lon); if (status A) { // A 数据有效 ESP_LOGI(TAG, GPS Valid. Lat: %.4f, Lon: %.4f, lat, lon); } else { ESP_LOGW(TAG, GPS Invalid (Status: %c), status); } } static void uart1_event_task(void *arg) { uart_event_t event; uint8_t data[BUF_SIZE]; while (1) { if (xQueueReceive(uart1_queue, (void *)event, portMAX_DELAY)) { switch (event.type) { case UART_DATA: { int len uart_read_bytes(UART1_NUM, data, BUF_SIZE - 1, 0); // 留一位给\0 if (len 0) { data[len] \0; // 转换为C字符串 // 1. 本地解析并打印GPS信息可选 // 假设数据是一行行来的GPS模块通常如此这里简化处理实际可能需要组帧。 if (is_valid_nmea_start((char*)data)) { parse_gprmc_and_log((char*)data); } // 2. 将原始数据转发到UART2 uart_write_bytes(UART2_NUM, (const char*)data, len); ESP_LOGI(TAG, Forwarded %d bytes from UART1 to UART2, len); } break; } case UART_FIFO_OVF: case UART_BUFFER_FULL: ESP_LOGE(TAG, UART1 Buffer Overflow, flushing.); uart_flush_input(UART1_NUM); break; default: break; } } } } static void uart2_event_task(void *arg) { // UART2的任务这里假设它接收来自无线模块的配置命令并回显或处理。 // 例如收到特定命令后改变GPS数据的转发频率。 uart_event_t event; uint8_t data[BUF_SIZE]; while (1) { if (xQueueReceive(uart2_queue, (void *)event, portMAX_DELAY)) { if (event.type UART_DATA) { int len uart_read_bytes(UART2_NUM, data, BUF_SIZE - 1, 0); if (len 0) { data[len] \0; ESP_LOGI(TAG, UART2 Received: %s, data); // 简单的命令处理示例 if (strstr((char*)data, SET LED ON)) { gpio_set_level(LED_GPIO, 1); uart_write_bytes(UART2_NUM, LED ON OK\r\n, 11); } } } } } } void app_main(void) { // 1. 初始化UART1 uart_config_t uart1_cfg { .baud_rate UART1_BAUD, .data_bits UART_DATA_8_BITS, .parity UART_PARITY_DISABLE, .stop_bits UART_STOP_BITS_1, .flow_ctrl UART_HW_FLOWCTRL_DISABLE, }; uart_param_config(UART1_NUM, uart1_cfg); uart_set_pin(UART1_NUM, UART1_TXD_PIN, UART1_RXD_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE); uart1_queue xQueueCreate(20, sizeof(uart_event_t)); uart_driver_install(UART1_NUM, BUF_SIZE * 2, 0, 20, uart1_queue, 0); // 2. 初始化UART2 uart_config_t uart2_cfg { .baud_rate UART2_BAUD, .data_bits UART_DATA_8_BITS, .parity UART_PARITY_DISABLE, .stop_bits UART_STOP_BITS_1, .flow_ctrl UART_HW_FLOWCTRL_DISABLE, }; uart_param_config(UART2_NUM, uart2_cfg); uart_set_pin(UART2_NUM, UART2_TXD_PIN, UART2_RXD_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE); uart2_queue xQueueCreate(20, sizeof(uart_event_t)); uart_driver_install(UART2_NUM, BUF_SIZE * 2, 0, 20, uart2_queue, 0); // 3. 创建任务处理UART事件 xTaskCreate(uart1_event_task, uart1_task, 4096, NULL, configMAX_PRIORITIES-2, NULL); xTaskCreate(uart2_event_task, uart2_task, 4096, NULL, configMAX_PRIORITIES-2, NULL); ESP_LOGI(TAG, UART Bridge Started. UART1(GPS%d) - UART2(Wireless%d), UART1_BAUD, UART2_BAUD); }案例要点与扩展数据完整性本例中假设GPS数据是完整的行。现实中数据可能被拆分成多个UART_DATA事件。你需要一个缓冲区来组帧比如寻找换行符\n作为一帧的结束。任务优先级两个UART事件任务的优先级我设置为configMAX_PRIORITIES-2这是一个较高的优先级确保串口数据能及时处理。但要注意如果处理逻辑非常耗时比如复杂的协议解析可能会阻塞另一个串口的任务。如果出现这种情况可以考虑将耗时的处理如解析、存储移交给一个低优先级的任务事件任务只负责快速读取和投递数据。流控如果UART2连接的无线模块发送较慢而GPS数据源源不断可能导致UART2的发送缓冲区积压。可以考虑在转发前检查UART2的发送缓冲区剩余空间 (uart_wait_tx_done或监听UART_TX_DONE事件)或者直接为UART2启用硬件流控。错误恢复案例中包含了缓冲区溢出的错误处理清空缓冲区。在实际产品中你可能需要更精细的恢复策略比如记录错误次数超过阈值后重启串口驱动。7. 深度避坑多串口开发中的常见问题与解决方案即使按照指南操作在实际开发中你还是可能会遇到一些棘手的问题。下面是我在多个项目中总结出来的“坑点”和解决方案。7.1 中断冲突与优先级管理ESP32的三个UART共享同一组中断源。虽然驱动层已经做了封装但在极端高负载或不当配置下仍可能出问题。现象一个串口大量收数时另一个串口的数据丢失或响应变慢。根因UART中断服务程序ISR执行时间过长或者被更高优先级的中断如Wi-Fi/蓝牙中断抢占。解决方案优化ISR确保你的UART事件处理任务uart_event_task尽快从队列中取走事件。不要在ISR或事件任务中做复杂运算、打印大量日志ESP_LOGI本身比较耗时、或调用可能阻塞的API。调整中断优先级在uart_driver_install的intr_alloc_flags参数中可以尝试设置ESP_INTR_FLAG_IRAM将ISR放入IRAM并可能结合优先级参数。但调整中断优先级是高级操作需谨慎不当设置可能导致系统不稳定。对于大多数应用保持默认0即可。核心绑定如果使用双核ESP32如ESP32-S3可以考虑将两个UART的处理任务分别绑定到不同的CPU核心上减少核心间的任务切换开销。使用xTaskCreatePinnedToCore创建任务。7.2 电源管理与睡眠唤醒当ESP32进入Light-sleep或Deep-sleep模式时外设包括UART会被关闭以省电。唤醒后UART需要重新初始化。现象设备睡眠唤醒后串口无法正常工作。解决方案在进入睡眠前调用uart_driver_delete(UART_NUM_1)来卸载驱动释放资源。从睡眠唤醒后在app_main或唤醒回调函数中重新执行完整的UART初始化流程uart_param_config,uart_set_pin,uart_driver_install。特别注意引脚状态有些GPIO在睡眠状态下可以配置为“保持”状态但唤醒后仍需重新配置为UART功能。7.3 引脚冲突与功能复用这是新手最容易踩的坑尤其是使用UART1时。问题复现将UART1的TXD/RXD配置到GPIO9/GPIO10程序运行异常甚至无法烧录。解决方案绝对避免使用GPIO6至GPIO11这些引脚通常与内部Flash/SRAM连接复用为功能引脚极易导致系统崩溃。查阅开发板原理图确认你选择的引脚没有连接板载其他器件如LED、按钮且该引脚在上电时没有特殊状态要求例如某些引脚在启动时必须为高电平或低电平。使用uart_set_pin前检查可以使用gpio_reset_pin来将引脚复位到默认状态然后再配置为UART功能。7.4 波特率误差与通信不稳定现象与某些特定设备尤其是老式设备或晶振精度不高的模块通信时出现乱码或偶发性数据错误。根因ESP32的UART波特率发生器基于APB时钟通常80MHz分频可能存在微小误差。对于标准波特率如9600, 115200误差极小。但对于非标准波特率或者对方设备时钟误差较大时累积误差可能导致采样点偏移。解决方案计算实际波特率使用uart_get_baudrate函数可以获取驱动实际设置成功的波特率与目标值对比。调整时钟源uart_config_t中的source_clk可以尝试改为UART_SCLK_APB默认或UART_SCLK_RTC精度可能更低不推荐。对于高精度需求ESP32支持外部时钟源但配置复杂。软件容错在协议层增加校验如CRC并实现重传机制。这是提高通信鲁棒性的根本方法。降低波特率在长距离、干扰大的RS-485应用中适当降低波特率可以提高稳定性。7.5 驱动卸载与资源泄漏在动态创建/销毁UART连接例如实现一个可配置的串口服务器时务必正确管理资源。正确流程停止相关数据收发任务。调用uart_driver_delete(uart_num)。这个函数会禁用UART中断。释放驱动层创建的环形缓冲区内存。复位UART寄存器。释放事件队列如果是由驱动创建的。之后该UART端口可以再次被初始化使用。常见错误只调用uart_driver_uninstall旧版API或什么都不做就直接重新初始化可能导致内存泄漏或中断状态混乱。uart_driver_delete是V4.4版本推荐的清理函数。通过理解这些底层机制和避坑指南你就能在ESP32上构建出稳定、高效的双串口乃至多串口应用。从简单的数据透传到复杂的多协议网关扎实的驱动层理解是这一切的基础。