在嵌入式开发中，写出一份能稳定运行的代码，远比实现一个酷炫的功能更有挑战性。很多看似不起眼的编程习惯，一旦放到资源受限、实时性要求高的嵌入式环境中，就可能演变成难以排查的“定时炸弹”。今天，我们就来系统性地盘点一下，在嵌入式开发，特别是涉及RTOS和嵌入式Linux应用开发时，那些应该极力避免的编程实践。
1. 不检查函数返回值
这大概是嵌入式开发中最常见，也最容易被忽视的问题之一。无论是I2C读写、UART发送，还是动态内存分配（如malloc），很多开发者会习惯性地忽略这些函数的返回值。
HAL_I2C_Master_Transmit(&hi2c1, addr, data, len, 100);
// 万一发送失败呢？
如果外设通信失败，而后续代码又基于“发送成功”这一错误假设继续执行，就会引发一连串的连锁反应。这种Bug在现场复现时，真正的源头往往早已被后续的错误操作所掩盖，排查起来异常困难。
正确做法：务必检查返回值，并根据错误类型实施相应的处理逻辑。在主循环或任务中，可以加入重试机制。进行延时等待时，应使用非阻塞方式：裸机开发可以使用 HAL_Delay，而在RTOS环境中则应该使用 vTaskDelay 来让出CPU，避免任务空转。
HAL_StatusTypeDef status = HAL_ERROR;
for (int retry = 0; retry < 3 && status != HAL_OK; retry++)
{
status = HAL_I2C_Master_Transmit(&hi2c1, addr, data, len, 100);
if (status != HAL_OK)
{
HAL_Delay(10); // 裸机。若用 RTOS 则 vTaskDelay(pdMS_TO_TICKS(10));
}
}
if (status != HAL_OK)
{
handle_i2c_error();
}
2. 任务栈配置过小
在RTOS中，每个任务都拥有独立的栈空间。新手常本着“够用就行”的原则，分配诸如128或256字节的栈空间。然而，一旦该任务的调用层级加深、局部变量增多，或者使用了 printf 这类吃栈大户，便极易发生栈溢出。其典型表现就是：该任务一经执行就触发HardFault，排查半天才发现是栈空间被“撑爆”了。
// 危险：栈可能不够
xTaskCreate(task_handler, "Task", 128, NULL, 1, NULL);
// 更危险：递归、大局部数组、printf 等都很吃栈
void task_handler(void* pv)
{
char buf[200];
sprintf(buf, "...");
parse_protocol(); // 可能还有多层调用
}
正确做法：初期为任务栈配置足够大的余量，然后利用RTOS提供的栈水位检测工具（例如FreeRTOS的 uxTaskGetStackHighWaterMark ）观察运行时的实际使用情况，再逐步收紧。对于那些包含递归、大量格式化输出或大数组的任务，尤其需要预留充足的栈空间。
3. 死锁（Deadlock）
多任务环境下，死锁是一个经典的同步问题。假设任务A需要先获取互斥锁 mutex1 再获取 mutex2，而任务B则先获取 mutex2 再获取 mutex1。当某个时刻，任务A持有了 mutex1 并等待 mutex2，同时任务B持有了 mutex2 并等待 mutex1 时，两个任务将永远互相等待，导致系统卡死。这种加锁顺序的不一致，是引发死锁的典型原因。
// 任务 A
xSemaphoreTake(mutex1, portMAX_DELAY);
xSemaphoreTake(mutex2, portMAX_DELAY); // 若 B 已拿 mutex2，A 死等
// ... 操作 ...
xSemaphoreGive(mutex2);
xSemaphoreGive(mutex1);
// 任务 B：顺序相反，埋下死锁隐患
xSemaphoreTake(mutex2, portMAX_DELAY);
xSemaphoreTake(mutex1, portMAX_DELAY); // 若 A 已拿 mutex1，B 死等
正确做法：在全项目范围内，规定一个统一的锁获取顺序（例如，按照锁变量的地址从低到高排序），并要求所有任务都严格遵守这一顺序。此外，也可以考虑使用 xSemaphoreTake(..., 0) 这种非阻塞方式进行尝试获取，如果获取失败，则主动释放已持有的锁并进行重试，避免永久性阻塞。
4. 在中断服务程序(ISR)中调用阻塞型API
在RTOS环境下，诸如 xQueueSend, xSemaphoreTake, vTaskDelay 这样的API都是可能引起任务阻塞的，它们绝对不可以在中断服务程序（ISR）中调用。在ISR中，必须使用带有 FromISR 后缀的版本，并且这些API不能带有阻塞超时参数。
// 错误！在 UART 中断里这样写会挂死或触发 configASSERT
void UART_IRQHandler(void)
{
uint8_t byte = read_uart_byte();
xQueueSend(rx_queue, &byte, 0); // 错误：阻塞型 API
}
// 正确：用 FromISR 版本，且根据需要决定是否触发任务切换
void UART_IRQHandler(void)
{
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
uint8_t byte = read_uart_byte();
xQueueSendFromISR(rx_queue, &byte, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
5. 魔法数字满天飞
直接看这段代码，你能立刻明白它的意图吗？
if(status == 0x03)
{
reg = 0x1F;
delay(10);
}
else if(status == 0x05)
{
reg = 0x3F;
delay(20);
}
0x03 代表什么状态？0x1F 这个寄存器配置值又是什么意思？10 和 20 这两个延时值是怎么来的？别说三个月后，可能一周后连你自己都看不懂了。
正确做法：使用宏定义或枚举，为这些“魔法数字”赋予有意义的名字。这样做不仅提升了代码的可读性，也方便后续的维护和修改。
#define SENSOR_MODE_ACTIVE 0x03
#define SENSOR_MODE_STANDBY 0x05
#define CONFIG_REG_ACTIVE 0x1F
#define CONFIG_REG_STANDBY 0x3F
#define DELAY_ACTIVE_MS 10
#define DELAY_STANDBY_MS 20
if(status == SENSOR_MODE_ACTIVE)
{
reg = CONFIG_REG_ACTIVE;
delay(DELAY_ACTIVE_MS);
}
else if(status == SENSOR_MODE_STANDBY)
{
reg = CONFIG_REG_STANDBY;
delay(DELAY_STANDBY_MS);
}
6. 忽略编译器警告
在很多项目中，开发者常常对满屏的编译器警告视而不见，只要编译没有报错（Error），就认为万事大吉。在嵌入式开发中，这无疑是在给自己埋雷。
看看这个例子：
uint8_t data_buffer[100];
uint16_t index = 300;
data_buffer[index] = 0x55;
编译器很可能会提示“possible loss of data”或类似的警告。如果你选择忽略它，那么index的值300在赋值时会被截断成44，导致数据被写入一个完全错误的内存位置。这类Bug的隐蔽性极强，调试起来会让人抓狂。
正确做法：将编译器的警告级别调到最高（例如使用 -Wall -Wextra 等选项），并严肃对待每一个警告，尽可能将其消除。对于那些确实无法消除的警告，也必须明确知晓其原因，并通过注释加以说明。
7. 文件描述符泄漏
在嵌入式Linux应用开发中，文件描述符泄漏是一个常见问题，其最终表现就是程序运行一段时间后，系统报出 “Too many open files” 的错误，导致进程无法继续工作。
导致泄漏的原因通常有两种：open() 调用失败（返回-1）后没有检查就继续使用；或者 open() 成功打开了设备节点、socket或普通文件，但在使用完毕后忘记了调用 close() 进行关闭。
// 不推荐：打开不关、失败不检查
int fd = open(“/dev/ttyS0”, O_RDWR);
write(fd, data, len);
// 没有 close(fd)，每次调用泄漏一个 fd
正确做法：首先，必须检查 open() 的返回值，失败时应进行错误处理并返回。其次，确保在函数的所有退出路径上，都调用了 close() 来释放已打开的文件描述符。可以使用 goto 语句跳转到一个统一的清理标签，或者封装成资源自动管理风格的函数。
int fd = open(“/dev/ttyS0”, O_RDWR);
if (fd < 0)
{
perror(“open”);
return -1;
}
if (write(fd, data, len) != (ssize_t)len)
{
close(fd);
return -1;
}
close(fd);
8. 信号(Signal)处理函数使用不当
在嵌入式Linux中，信号处理函数（signal handler）有严格的调用限制。你只能调用POSIX标准中定义的异步信号安全（async-signal-safe）函数。像 printf, malloc, pthread_mutex_lock 这些常用函数都不在此列，如果在信号处理函数中调用它们，属于未定义行为，极有可能导致死锁、程序崩溃或意外覆盖全局变量 errno 的值。
// 危险！printf、malloc 等在信号处理函数里不可用
void sig_handler(int sig)
{
printf(“received signal %d\n”, sig); // 可能死锁
char* buf = malloc(64); // 可能破坏堆
sprintf(buf, “sig %d”, sig);
// ...
}
正确做法：在信号处理函数中只做最少、最安全的事情。通常的做法是设置一个 volatile sig_atomic_t 类型的全局标志变量。将复杂的处理逻辑放到主循环或一个专门的线程中，通过轮询这个标志变量来执行。
volatile sig_atomic_t g_signal_received = 0;
void sig_handler(int sig)
{
g_signal_received = sig; // 仅设置标志，安全
}
9. 忽略 read/write 的返回值与“短读/短写”
在读写文件描述符（包括设备文件、socket、管道等）时，read() 和 write() 系统调用可能不会一次性完成你请求的全部字节数，它们的返回值才是实际成功读/写的字节数。如果不检查返回值，想当然地认为“一次搞定”，很可能会导致数据丢失或读写不完整。
// 错误：假设一次 read 读完
char buf[256];
read(fd, buf, sizeof(buf)); // 可能只读到 50 字节
process_packet(buf); // 按完整包处理，数据不完整
正确做法：必须使用循环来确保读写完成。对于 write()，需要循环调用直到所有数据写完或发生错误；对于 read()，需要循环累加直到收到足够数据或遇到文件结束（EOF）。同时，要正确处理 EINTR（系统调用被信号中断）和 EAGAIN/EWOULDBLOCK（非阻塞IO下的暂时无数据）等错误情况。
ssize_t total = 0;
while (total < len)
{
ssize_t n = read(fd, buf + total, len - total);
if (n <= 0)
{
/* 处理错误或 EOF */
break;
}
total += n;
}
10. 滥用动态内存分配
malloc 和 free 在PC编程中司空见惯，但在嵌入式系统里，必须慎之又慎。嵌入式系统的内存资源本就有限，频繁地申请和释放不同大小的内存块，很容易导致内存碎片。最终，即使系统仍有空闲内存，也可能因为找不到一块足够大的连续空间而导致 malloc 失败。更关键的是，malloc 的执行时间通常是不确定的，这对于有严格实时性要求的系统来说是个大忌。
正确做法：优先使用静态分配。如果确实需要动态管理，可以考虑使用内存池（memory pool）技术，或者预分配一个大数组，然后在应用层实现自己的简单内存管理器。这样可以有效避免内存碎片，并保证分配时间的确定性。
// 不推荐
void* ptr = malloc(size);
free(ptr);
// 推荐 - 静态分配
static uint8_t buffer[256];
static uint8_t buffer_used = 0;
11. 中断服务程序里“干太多活”
中断服务程序（ISR）的设计核心原则是“快进快出”。有些人会将复杂的计算、协议解析甚至延时操作都塞进ISR里，这会导致中断响应时间变长，影响其他中断的及时处理，也可能使得主循环或低优先级任务长时间得不到执行。
void USART1_IRQHandler(void)
{
uint8_t data = USART1->DR;
// 下面这些操作不应该在中断里做
process_protocol(data); // 协议解析
save_to_buffer(data); // 保存数据
update_display(data); // 更新显示
}
正确做法：在ISR中只做最必要、最轻量的工作。通常的模式是：接收数据并放入一个缓冲区，然后设置一个“数据就绪”标志位。将所有耗时的处理逻辑，都转移到主循环或一个专门的任务中，通过检查该标志位来触发处理。
void USART1_IRQHandler(void)
{
uint8_t data = USART1->DR;
// 只做接收和标记
rx_buffer[rx_index++] = data;
data_ready_flag = 1;
}
int main(void)
{
while(1)
{
if(data_ready_flag)
{
data_ready_flag = 0;
// 在这里处理数据
process_received_data();
}
}
}
12. 忽视 volatile 关键字
这是一个经典且隐蔽的问题，主要与编译器优化有关。当一个变量可能被中断服务程序或硬件寄存器异步修改时，如果不将其声明为 volatile，编译器可能会基于其优化策略做出错误判断。
uint8_t flag = 0;
void ISR(void)
{
flag = 1;
}
void main(void)
{
while(!flag)
{
// 编译器可能优化成 while(1)
}
}
在上面的例子中，编译器发现 main 函数里的循环没有修改 flag，它可能就会认为 flag 的值永远不会改变，从而将 while(!flag) 优化成一个无限循环，程序永远无法退出等待。
正确做法：所有可能被中断服务程序、其他线程（在RTOS中）或硬件寄存器异步修改的全局变量，都必须使用 volatile 关键字进行修饰。
volatile uint8_t flag = 0;
总结
嵌入式软件开发，因其资源受限、环境复杂、调试困难等特点，对代码的严谨性提出了更高的要求。说到底，一份优秀的嵌入式代码应该追求的是：确定性、可维护性和鲁棒性。主动避开上述这些不良编程实践，是提升代码质量、保障系统稳定运行的关键一步。
嵌入式代码发布前自检清单
在将代码发布或烧录到设备前，不妨对照下面这份清单快速过一遍：
- [ ] 关键外设调用（I2C、SPI、UART）是否检查了返回值并设计了容错机制？
- [ ] RTOS中各任务的栈空间配置是否充足，并已通过水位检测验证？
- [ ] 多任务间的锁（mutex）获取顺序是否全局统一，避免了死锁可能？
- [ ] 中断服务程序(ISR)中是否只使用了
FromISR 后缀的非阻塞API？
- [ ] 代码中是否还存在难以理解的“魔法数字”？是否已用宏或枚举替换？
- [ ] 编译时是否已将警告级别调到最高，并且所有警告都已得到合理解释或处理？
- [ ] 在Linux应用开发中，所有
open() 获得的文件描述符是否都有对应的 close()？
- [ ] 信号处理函数中是否只进行了设置标志等最小化操作？
- [ ]
read()/write() 等系统调用是否处理了“短读/短写”和中断情况？
- [ ] 是否还在大量使用
malloc/free？是否考虑用内存池或静态分配替代？
- [ ] 中断服务程序是否足够简短，耗时操作都已移到主循环或任务中？
- [ ] 所有可能被异步修改的共享变量是否都正确添加了
volatile 关键字？
- [ ] 代码中的关键算法、特殊处理或硬件约束，是否添加了说明“为什么这么做”的注释？
上面的这些“坑”，你在开发过程中遇到过几个呢？如果你有其他的经验或教训，欢迎在云栈社区的嵌入式开发板块与大家交流探讨。在网络与系统编程板块，你也能找到更多关于并发、IPC等底层机制的深入讨论。
发表于 2 小时前
|
查看: 2|
回复: 0
