freertos相关问题

1. 列表与队列List 是 FreeRTOS 内核自己用来管理对象的内部数据结构。FreeRTOS 的 List 本质是一个链表管理结构Queue 是提供给用户任务/中断通信的数据结构。Queue 是 FreeRTOS 提供给用户的通信机制两者最大的区别ListQueue中文列表(使用链表实现)队列主要用途内核管理任务通信使用者FreeRTOS 内核用户程序存储内容任务控制块等对象用户数据是否阻塞没有可以是否用于IPC否是是否给ISR用内部使用有 FromISR API2. 任务的动态和静态方式创建首先一个任务需要的内存空间是TCB Task Stack可以这么理解从哪申请的内存 用来做什么删除任务时在空闲任务中释放内存2.1 动态FreeRTOS 动态创建任务时从 Heap 中申请所需内存Heap┌──────────────────────────────┐│ TCB_A │├──────────────────────────────┤│ Stack_A[128] │└──────────────────────────────┘Stack_A 的地址不会因为任务切换而改变Heap 里的这块内存来源上是 Heap用途上是 Task Stack2.2 静态直接定义TCB 和 Task Stack通常是放在全局存储区C 语言里的“栈”这个概念在 FreeRTOS 多任务环境下被具体落实成“每个 Task 各自拥有的 Task Stack”3. 任务调度器调度器Scheduler负责决定“下一个运行哪个 Task”调度器不是一个 TaskvTaskSuspendAll()暂时挂起 FreeRTOS 的调度器也就是在这期间内任务不会发生切换但是中断仍然可以运行xTaskResumeAll()恢复 Scheduler重新判断当前到底应该运行哪个 Task。Scheduler↓决定“谁该运行”PendSV承载上下文切换的异常↓提供一个合适的异常上下文执行切换Context Switch↓保存/恢复 CPU Context4. Exception(异常)pendsv是一种异常中断属于异常5. FreeRTOS的中断管理注意任务优先级与中断优先级两个体系完全不同中断可以打断 Task5. 1FreeRTOS的中断管理使用configMAX_SYSCALL_INTERRUPT_PRIORITY宏来设置BASEPRI寄存器只看高四位这个宏理解为允许调用 FreeRTOS 系统调用FromISR API的中断优先级边界BASEPRIBase Priority Mask Register基本优先级屏蔽寄存器假设BASEPRI 5IRQ Priority0 ─────────── 允许1 ─────────── 允许2 ─────────── 允许3 ─────────── 允许4 ─────────── 允许 ← 不能调用 FromISR中操作内核的API------------------------ BASEPRI 55 ─────────── 屏蔽6 ─────────── 屏蔽7 ─────────── 屏蔽8 ─────────── 屏蔽 . ← 可以调用 FromISR原因因为 FreeRTOS 可能正在进入临界区 ↓ BASEPRI 5 ↓ 修改 Queue / List / TCB这时候Priority 7 ISR ↓ 被 BASEPRI 挡住所以不会破坏内核操作。但是Priority 3 ISR ↓ BASEPRI 挡不住 ↓ 如果调用 xQueueSendFromISR() ↓ 可能与内核正在进行的操作冲突因此不允许。5. 2FreeRTOS的临界段代码临界段通过设置BASEPRI实现taskENTER_CRITICAL()↓保存当前中断屏蔽状态↓设置 BASEPRI↓屏蔽 FreeRTOS 所规定范围内的中断↓执行临界段↓taskEXIT_CRITICAL()↓恢复原来的屏蔽状态6. 队列Queue│├── 数据存储区│├── 写位置├── 读位置├── 当前消息数量├── 最大容量│├── xTasksWaitingToSend└── xTasksWaitingToReceive7. 信号量信号量可以看作长度为1的队列类型作用例子Binary Semaphore事件通知ADC完成通知Counting Semaphore计数资源5个缓冲区Mutex保护共享资源SPI/I2C互斥7.1 互斥信号量互斥信号量是包含优先级继承机制的二进制信号量用途保护共享资源。功能: 优先级继承8. 队列集实际中不常用原因:1. 模块没有隔离2. 调试不方便队列集本质上是一个队列9.任务通知TCB|├── xStateListItem|├── xEventListItem|├── ulNotifiedValue|└── ucNotifyState任务通知保存在TCB中模式1二值通知Binary模式2计数通知Counting模式3通知值Value可以直接传32位数据。类似队列但是只能传给一个任务模式4位事件Bits类似事件标志组10. 软件定时器使用软件定时器而不是使用xTaskDelayUntil()的原因:创建多个任务浪费资源软件定时器组成:Timer对象 | Timer Service Task | Timer Command QueueTimer Service Task由FreeRTOS自动创建,并且可以通过宏设置优先级Timer对象里面保存定时周期回调函数当前状态名称SysTick ISR -- xTickCount增加 -- Timer Service Task -- Timer Callback()注意:问:vtaskdelayuntil与使用软件定时器有什么区别?答:vTaskDelayUntil()让一个任务按照固定周期运行。软件定时器在某个时间点触发一个事件/回调。重要区别:前者实时性更强vTaskDelayUntil()更适合周期控制任务软件定时器适合非关键周期事件例如LED闪烁超时检测状态刷新软件延时事件11. Tickless低功耗模式核心概念:Tickless 模式就是当系统没有任务需要运行时让系统停止周期性的 Tick 中断进入低功耗睡眠并在唤醒时补偿这段时间丢失的 Tick主要是进入stm32的sleep低功耗模式中12 .栈监控和栈溢出检测栈监控事前评估看栈用了多少预防溢出主动统计栈余量栈溢出检测事后报警栈已经越界了通知你故障被动捕获溢出错误12.1 前置基础概念必须搞懂任务栈PSP每个任务独立私有栈任务切换时切换 PSP 指针xTaskCreate传入的栈深度就是这个栈单位words字。全称Process Stack Pointer中文进程堆栈指针也叫任务堆栈指针Cortex‑M 32 位1 word 4字节栈深度 128 → 128×4 512 字节中断主栈MSP所有中断、异常共用在链接脚本设置大小。FreeRTOS 软件机制完全不监控 MSP栈监控、栈溢出检测只管任务 PSP 栈栈魔数 0xA5任务创建时把整个任务栈内存预先填满0xA5没被使用的栈保持0xA5已经使用过的栈被函数局部变量、寄存器压栈覆盖不再是0xA5注意只要configCHECK_FOR_STACK_OVERFLOW ! 0系统才会填充 0xA5等于 0 时栈没有魔数栈监控 API 结果无效12.2 第一部分栈监控High‑WaterMark 高水位12.2.1 什么是高水位高水位 任务运行历史上栈剩余空间的最小值举例子 任务栈配置200 wordsuxTaskGetStackHighWaterMark()返回40含义运行过程中最少只剩下 40 个字空闲最大已使用栈 200‑40 160 words安全判断40word 余量开发够用产品建议预留≥30~50words12.2.2 核心 API运行// 查询指定任务历史最小剩余栈 UBaseType_t uxTaskGetStackHighWaterMark( TaskHandle_t xTask ); // xTask NULL → 查询当前正在运行的任务 // FreeRTOS10新增同时返回总栈大小 UBaseType_t uxTaskGetStackHighWaterMark2(TaskHandle_t xTask, configSTACK_DEPTH_TYPE *pxStackSize);配套工具函数 vTaskList打开宏运行#define configUSE_TRACE_FACILITY 1 #define configUSE_STATS_FORMATTING_FUNCTIONS 1运行char buf[1024]; vTaskList(buf); printf(%s,buf);输出表格里Stack那一列就是每个任务的高水位剩余 words一键查看全部任务。12.2.3 栈监控工作原理任务创建栈全部填充魔数0xA5调用 API 时代码从栈底向上遍历内存统计连续还是0xA5的内存字数这个数值就是此刻看到的空闲栈内核内部记录历史最小空闲值就是高水位。12.2.4. 栈监控的局限性非常重要采样式不是实时连续监控API 调用那一刻才扫描栈。如果有短暂栈尖峰刚好发生在两次查询中间抓不到尖峰高水位不会更新。 例函数瞬间爆栈但是很快返回释放栈监控没赶上采样完全看不到。只看任务 PSP 栈中断 MSP 完全看不到中断里面局部变量过大导致 MSP 溢出软件栈监控毫无感知只会直接 HardFault。高水位只降不升任务不重启就不会重置一旦出现一次大栈消耗就算后面程序逻辑再也不用这么多栈高水位数值保持那个最小值不变。想要重新统计必须删除重建任务。魔数污染导致统计不准如果业务代码恰好往栈里写入数值0xA5会被误认为这部分栈没有被使用统计出来剩余栈偏大低估风险概率很低但客观存在。依赖魔数填充configCHECK_FOR_STACK_OVERFLOW0时栈没有 0xA5API 返回值无意义。12.2.5. 使用方式方式 A独立低优先级监控任务周期打印各个任务水位方式 B调试时调用一次vTaskList快速摸底方式 C日志保存压力测试观察最坏工况下最小余量。用途开发阶段评估栈配得够不够提前把栈调大预防溢出不能检测已经发生的栈溢出故障。12.3 第二部分栈溢出检测Stack Overflow Detection栈已经超出分配栈空间内存越界改写其他内存TCB、其他任务栈、全局变量。FreeRTOS 提供两种软件检测模式由configCHECK_FOR_STACK_OVERFLOW控制。⚠️ 软件栈溢出检测都不是硬件实时捕获都在任务上下文切换的时候才做检查。溢出发生瞬间不会立刻触发。模式 1configCHECK_FOR_STACK_OVERFLOW 1栈底水印检查原理任务栈底部预留一段魔数标记区。每次任务被切出去上下文切换检查栈底部标记有没有被改写。标记被破坏 → 判断栈溢出调用溢出钩子vApplicationStackOverflowHook。优缺点✅ 开销极小 ❌ 漏检概率高 如果栈向上溢出没有破坏栈底部标记检测不到 溢出发生后必须等到下一次任务切换才报警 如果溢出直接覆盖 TCB系统直接崩溃钩子根本跑不到。模式 2configCHECK_FOR_STACK_OVERFLOW 2水印 边界 Guard推荐调试使用原理在模式 1 栈底水印基础上栈最顶端栈增长边界放置一个守护魔数 Guard。 每次上下文切换检查栈底水印额外检查栈边界 Guard 值是否被改写。 只要任意一处被破坏判定栈溢出进入钩子。Cortex‑M 栈是向下增长SP 越来越小栈往低地址生长一旦超出分配大小直接踩掉 Guard。优缺点✅ 检出率比模式 1 高很多调试首选 ❌ 依然是任务切换时刻才检查 ❌ 极端情况一次超大压栈直接越过 Guard直接破坏 TCB/RAMCPU 直接 HardFault来不及执行检测逻辑与钩子函数 ❌ 上下文切换增加少量 CPU 开销。溢出钩子函数 vApplicationStackOverflowHook检测到溢出后内核调用这个钩子必须用户自己实现系统没有默认实现c运行void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { // 系统此时内存已经损坏状态不稳定 // 禁止调用vTaskDelay、printf、malloc、任何会阻塞的FreeRTOS API // 建议点灯、置标志、死循环停机不要继续运行 for(;;); }开启钩子宏configUSE_STACK_OVERFLOW_HOOK 1非常关键不是每次栈溢出钩子都能执行。 如果溢出直接把 TCB任务控制块也破坏内核逻辑已经损坏直接进入 HardFault 异常钩子完全不会执行。软件检测有盲区。模式 0configCHECK_FOR_STACK_OVERFLOW 0关闭关闭魔数填充关闭溢出检测无额外开销此时uxTaskGetStackHighWaterMark返回无效。适合量产发布关闭减少开销。软件栈溢出检测共同短板只检测任务 PSP 栈中断 MSP 栈溢出完全管不了只会直接 HardFault检测点在上下文切换溢出瞬间不能立刻响应极端越界直接摧毁内核数据结构 → HardFault钩子无法执行。硬件补充方案Cortex‑M MPU 内存保护把每个任务栈设置 MPU 访问区域一旦访问栈以外内存硬件立即触发异常溢出瞬间捕获不依赖任务切换。可靠性最高缺点配置复杂占用 MPU 区域资源项目复杂才用。12.4 第三部分栈监控 vs 栈溢出检测完整对比表项目栈监控uxTaskGetStackHighWaterMark栈溢出检测 (configCHECK_FOR_STACK_OVERFLOW1/2)核心目的事前评估栈余量防止溢出栈已经溢出后报错告警触发时机用户主动调用 API 查询任务上下文切换被动检查检测对象任务 PSP 栈任务 PSP 栈对中断 MSP 栈完全看不到完全看不到依赖条件栈填充 0xA5栈填充 0xA5能否捕获瞬时尖峰采样盲点有可能抓不到只有切换时刻才能发现瞬时崩溃抓不到输出信息剩余栈多少 words量化余量只告诉你发生溢出不告诉你栈用了多少运行开销调用瞬间少量遍历内存每次任务切换少量开销钩子函数无返回数值触发 vApplicationStackOverflowHook 钩子使用场景开发调试压力测试优化栈大小调试阶段捕获溢出故障量产可关闭13. 函数栈帧与任务栈函数栈帧就 “存放” 在任务栈里面任务栈 一整块连续的内存区域容器固定大小函数栈帧 (stack frame) 这块内存里面给单个函数使用的一小块临时数据容器里的内容任务栈你用xTaskCreate(..., 200, ...)分配的一整块连续内存属于这个任务独占。是一块内存缓冲区总容量固定例200 words任务运行时使用 PSP 指针指向这块内存所有在这个任务里面调用的全部函数共用这一块内存任务切换时内核保存 / 恢复这个任务的 PSP也就是保存这个任务栈当前的栈指针位置类比一整间房间任务栈房间大小固定不函数栈帧Stack Frame函数栈帧Stack Frame每当调用一个 C 函数时编译器会在当前栈任务栈上开辟一小块内存专门给这个函数用这一小块就叫栈帧。 栈帧里面一般存放函数的局部变量函数返回地址LR 链接寄存器保存值函数参数部分放在栈上ARM 很多参数放寄存器栈对齐填充字节、保存的寄存器R4~R11 等被调用保存寄存器类比房间里面临时放的一个纸箱栈帧函数运行时摆进来函数 return 之后纸箱拿走空间回收调用链下的堆叠关系任务栈房间总大小固定。 函数一层层调用栈帧一层层堆叠在任务栈里Cortex‑M 栈向下增长往低地址堆叠。例子调用链TaskEntry → foo() → func()任务栈内存里从高地址→低地址依次存放TaskEntry 的栈帧先放foo () 的栈帧foo 调用后压在上面func () 的栈帧func 调用后再压在上面函数还没 return → 栈帧保留占用任务栈内存函数 return → 栈帧销毁SP 回退这块内存标记为空闲不会擦除数据后续调用会覆盖✅ 关系多个栈帧叠放在同一个任务栈内存里任务栈是内存载体栈帧是载体上动态创建 / 销毁的一小块数据。14 为什么任务栈的使用情况不同原因 1每一轮的函数调用路径不完全相同最主要原因 2中断抢占时机不同带来临时额外栈开销非常常见Cortex‑M 规则任务正在 PSP 上运行的时候如果来了中断部分寄存器会压入当前任务 PSP 栈再切到 MSP 执行中断服务函数中断退出后弹出PSP 恢复原样原因 3运行时可变栈开销VLA、alloca栈大小随数据变化原因 4编译器栈对齐带来微小差异小幅度波动ARM AAPCS 规范要求栈 8 字节对齐。 进入函数那一刻 SP 必须是 8 字节对齐。 虽然函数都正常返回但是上一次中断返回、系统调度之后 SP 对齐状态会造成个别函数入口分配少量填充字节带来1~2word 微小波动。只会带来很小差异不会产生巨大峰值差距。