裸机调度器不能直接用std::priority_queue，因其依赖动态内存分配且不保证o(1)最高优先级获取；应采用静态数组+就绪位图+双向链表实现确定性抢占调度。
为什么裸机调度器不能直接用 std::priority_queue
嵌入式裸机环境通常没 STL，也没堆管理——std::priority_queue 依赖 new 和分配器，中断上下文里调用会崩。更关键的是，它不保证 O(1) 的最高优先级获取，而抢占调度要求在中断退出前就决定该切谁，延迟必须确定且极低。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 用静态数组 + 就绪位图（bitmask）实现优先级索引，查最高优先级任务只要一条
__builtin_clz或查表，典型 1–3 个周期 - 每个优先级挂一个双向链表（非单向），插入/删除都是 O(1)，避免遍历
- 禁止在任务中动态增删就绪队列节点；所有任务控制块（TCB）必须静态定义或从固定内存池分配
如何在 SysTick 中断里安全触发优先级抢占
SysTick 是唯一能可靠打断任意任务的异常源，但它的 ISR 里不能直接调用上下文切换函数——Cortex-M 的 PendSV 才是干这事的正道。硬在 SysTick 里切，会破坏异常返回流程，尤其当被中断的是 SVC 或 PendSV 自身时，栈和寄存器状态极易错乱。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- SysTick ISR 只做两件事：更新系统滴答计数、调用
portSET_PENDSV（本质是写ICSR寄存器置位PendSV异常） -
PendSV的优先级必须低于 SysTick（数值更大），确保它不会打断滴答处理，但又能被 SysTick 主动“触发” - 上下文保存/恢复必须用汇编手写（如
svc_context_save），不能依赖编译器生成的函数序言/尾声，否则压栈顺序和寄存器覆盖不可控
高优先级任务就绪后，怎么避免“抢占延迟毛刺”
常见错误是：任务 A 调用 vTaskResume 唤醒高优先级 B，但 B 并不立刻运行，要等到下一个 SysTick 才检查就绪队列——这造成毫秒级延迟，在电机控制或ADC采样同步场景里就是失控。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有能改变就绪状态的操作（如延时到期、信号量释放、消息入队），都应检查新就绪任务的优先级是否高于当前运行任务；若是，立即触发
PendSV - 不要把“唤醒”和“调度决策”拆成两个阶段；唤醒即调度，除非当前已在中断上下文且已挂起
PendSV - 关中断时间必须严格限定——只保护就绪队列操作本身（如链表插入+位图置位），绝不在关中断里做任何可能阻塞或调用其他模块的事
vTaskDelay 的精度为何总比预期多 1 个 tick
这不是 bug，是设计取舍：vTaskDelay(1) 表示“至少延时 1 个 tick”，内核在 tick 中断里统一检查所有延时任务是否到期。如果任务在 tick 中断刚发生后才调用 vTaskDelay(1)，那它要等到下下个 tick 才被唤醒——实际耗时接近 2 个 tick。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 对亚毫秒级定时需求（如 PWM 同步），别用
vTaskDelay，改用硬件定时器 + 中断通知，再由中断唤醒任务 - 若必须用延时，且需精确到 1 tick，确保调用时机尽量靠近 tick 中断点（比如在上一个
xTaskGetTickCount()返回值变化后立刻调用） - 不要重写
vTaskDelay去“修复”这个行为——它保障了调度器的可预测性；想绕过，说明你其实需要的是事件驱动，不是周期延时
优先级抢占的本质不是“快”，而是“可预测的最坏响应时间”。位图查优先级、PendSV 接管切换、关中断粒度控制——这些细节一旦松动，确定性就塌了。很多人卡在“功能跑通”，却没意识到示波器测出的 50μs 抖动，往往来自某次忘了清零的就绪位图或一次隐式内存分配。