当前位置:首页 > 嵌入式 > 嵌入式分享
[导读]项目中正在排查一个棘手的问题:系统在正常运行数小时后,突然毫无征兆地死锁。所有任务都停止了响应,但心跳定时器却还在走。他用了一周的时间排查内存泄漏、检查数组越界,甚至怀疑芯片有硬件bug。

项目中正在排查一个棘手的问题:系统在正常运行数小时后,突然毫无征兆地死锁。所有任务都停止了响应,但心跳定时器却还在走。他用了一周的时间排查内存泄漏、检查数组越界,甚至怀疑芯片有硬件bug。

最后,一个被忽略的细节浮出水面:在一个SPI外设的中断服务程序中,他无意中调用了`printf`。

在裸机系统中,ISR里做任何操作似乎都不会立即引发灾难。但在FreeRTOS这类抢占式实时系统中,ISR就相当于一个“超级特工”——它拥有最高特权,能打断任何任务的执行。如果这个“特工”在执行时违反了基本规则,系统的稳定性就会受到威胁。

规则一:不能在ISR中调用不带“FromISR”后缀的API

FreeRTOS为了让内核数据结构在多任务和多中断环境下保持完整性,使用了特殊的机制来避免死锁。许多API函数(如`xQueueSend`、`xSemaphoreGive`)内部可能会执行任务切换操作。

在ISR中调用普通版本的API,相当于在一个抢占了任务的高优先级上下文中去操作一个可能处于锁定状态的内核对象。

错误示例:

void SPI_IRQHandler(void) {

uint32_t data = SPI_ReceiveData();

xQueueSendToBack(xUARTQueue, &data, 0); // 危险操作!

}

这段代码如果恰好赶上任务正在修改队列,ISR强行介入,会导致队列结构损坏。

正确示例:

void SPI_IRQHandler(void) {

uint32_t data = SPI_ReceiveData();

BaseType_t xHigherPriorityTaskWoken = pdFALSE;

xQueueSendToBackFromISR(xUARTQueue, &data, &xHigherPriorityTaskWoken);

portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

}

规则二:不能在ISR中死等或轮询

ISR的本质是挂起CPU的正常流程去处理紧急事务。因此ISR的执行时间应该非常短。如果在ISR中用`while`循环等待某个硬件标志位,或者调用`vTaskDelay`试图让ISR“睡一会”,整个系统就会卡死,因为调度器无法在中断上下文中运行。

错误示例:

void ADC_IRQHandler(void) {

while(!(SPI->SR & SPI_SR_RXNE)); // 绝对不要在ISR里死等

int data = SPI->DR;

}

如果SPI数据迟迟不来,系统就停在这里。

正确做法:如果外设数据量较大或响应较慢,应使用DMA配合中断,或者只在ISR中做最轻量的数据搬移。

规则三:不能在ISR中执行阻塞操作

为了区分优先级,FreeRTOS允许任务在获取不到资源时进入阻塞态。但在ISR中,不存在“阻塞”的概念。若在ISR中调用带阻塞时间的API,该参数会被无视,且如果资源暂时不可用,函数会立即返回错误,而非阻塞等待。

错误示例:

void CAN_IRQHandler(void) {

uint32_t msg;

// 即使第二个参数是10(ticks),也不能阻塞等待

xQueueReceive(xCANQueue, &msg, 10);

}

规则四:不能执行耗时过长的浮点运算或复杂逻辑

入栈保存现场需要开销,执行浮点运算更是需要占用大量CPU周期。如果在ISR中做FFT变换或PID运算,可能会导致中断延迟超出系统容忍范围。SR中只做两件事——“数据搬家”和“触发任务”。真正的处理逻辑,应该交给高优先级的任务。

规则五:不能忘记上下文切换请求

FreeRTOS API中的`FromISR`函数大多有一个名为`pxHigherPriorityTaskWoken`的参数。如果在ISR中发送信号量唤醒了比当前被中断任务优先级更高的任务,FreeRTOS建议在ISR末尾进行一次手动任务切换,以确保高优先级任务能立即执行。

如果每次都机械地执行`portYIELD_FROM_ISR`,虽然安全,但会引入不必要的开销。标准的写法是先判断标志位是否为`pdTRUE`,再决定是否切换。

BaseType_t xHigherPriorityTaskWoken = pdFALSE;

// 执行某些FromISR操作,并传入 &xHigherPriorityTaskWoken

xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);

// 按需请求切换

portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

封装实践的示例

将SPI接收中断处理封装如下:

// 全局变量

QueueHandle_t xSpiRxQueue;

BaseType_t xTaskWoken = pdFALSE;

void SPI1_IRQHandler(void) {

// 1. 清除中断标志

if (SPI1->SR & SPI_SR_RXNE) {

uint16_t rx_data = SPI1->DR;

// 2. 存储数据 (快速操作)

if (xQueueSendFromISR(xSpiRxQueue, &rx_data, &xTaskWoken) != pdPASS) {

// 队列满了,处理错误(如丢弃数据)

}

// 3. 检查并触发任务切换

portYIELD_FROM_ISR(xTaskWoken);

}

}

// 高优先级任务:处理SPI数据

void vSPIProcessingTask(void *pvParameters) {

uint16_t rx_data;

BaseType_t xStatus;

for(;;) {

xStatus = xQueueReceive(xSpiRxQueue, &rx_data, portMAX_DELAY);

if(xStatus == pdPASS) {

// 以下是耗时的数据处理:

// 查表、滤波、协议解析等

}

}

}

总结

中断处理函数是一个危险的执行环境。上述五条规则——**不调用普通API、不阻塞、不轮询、不浮点运算、不忘切换**——共同指向一个核心原则:尽量缩短ISR执行时间。将数据从ISR中快速取出,存放到队列或信号量中,然后立即唤醒高优先级任务来处理。掌握这套机制,FreeRTOS系统才能在高数据吞吐量的场景下保持稳定。

本站声明: 本文章由作者或相关机构授权发布,目的在于传递更多信息,并不代表本站赞同其观点,本站亦不保证或承诺内容真实性等。需要转载请联系该专栏作者,如若文章内容侵犯您的权益,请及时联系本站删除( 邮箱:macysun@21ic.com )。
关闭