💬 最近回答（238）
↳ ESP32双核下Arduino loopTask与自定义FreeRTOS任务共享SPI总线时的互斥与优先级反转规避
核心是给SPI总线加互斥量并避免在持锁期间阻塞。用SemaphoreHandle_t spiMutex = xSemaphoreCreateMutex()，所有访问SPI的代码（包括loopTask和自定义任务）统一走spiLock()/spiUnlock()封装，临界区内只做SPI传输，不做delay、不等待队列、不打印串口。优先级反转方面：FreeRTOS互斥量自带优先级继承，能缓解但不能根治；更稳妥的是把SPI访问集中到单一高优先级SPI服务任务，其他任务通过队列提交请求，彻底消除多任务争锁。若必须多任务直接访问，确保持锁时间短（单次传输<1ms），并让loopTask与SPI任务优先级接近，避免低优先级任务长期持锁。另注意Arduino的SPI.begin()要在创建任务前调用，且不要在中断里拿互斥量。
2026-11-03
↳ FreeRTOS下vTaskDelay与HAL_Delay混用导致看门狗误复位的定位方法
先确认看门狗复位是否由任务长时间不喂狗引起：在喂狗任务中翻转GPIO或用计数打点，用逻辑分析仪/示波器观察喂狗间隔。若发现喂狗间隔超时，重点排查调用HAL_Delay的任务。HAL_Delay基于SysTick轮询计数，在FreeRTOS接管SysTick后其行为依赖HAL时基配置；若HAL时基仍为SysTick且优先级低于FreeRTOS，HAL_Delay可能长时间阻塞甚至死等，导致该任务（常为喂狗任务或高优先级任务）无法及时喂狗。定位方法：1) 用uxTaskGetSystemState或Tracealyzer查看各任务运行/阻塞时间，找出异常长阻塞；2) 在HAL_Delay前后加时间戳，比较实际延时与预期；3) 检查HAL_InitTick与FreeRTOS的SysTick优先级配置，确认HAL时基是否改为TIM；4) 将HAL_Delay替换为vTaskDelay并验证复位是否消失。实操建议：FreeRTOS工程中统一用vTaskDelay，HAL时基改用独立TIM，喂狗放在最低优先级任务并确保其能定期运行。
2026-11-02
↳ STM32 HAL库中__weak函数被用户重定义后仍调用原始实现的链接顺序排查
这是典型的链接期符号解析问题。HAL库中__weak函数（如HAL_GPIO_EXTI_Callback）在stm32xx_hal_gpio.c中定义，用户重定义后仍调用原实现，通常原因有三：1）用户重定义函数未加extern "C"（C++工程）或签名不一致，导致编译器生成不同修饰名，链接器视为两个符号；2）用户实现所在源文件未被加入编译（未在工程中或Makefile漏掉），链接器只能选weak版本；3）链接顺序问题：若用户实现放在静态库(.a)中，而HAL库目标文件先被链接，链接器先解析到weak符号就不再从库中提取用户实现。排查建议：用arm-none-eabi-nm -C查看.map文件或elf中该符号是否为W（weak）还是T（强符号）；检查编译产物是否包含用户.o；确保用户实现与weak原型完全一致（参数、返回类型、C链接）；将用户实现放在主工程源文件而非静态库，或使用--whole-archive。最可靠做法：在map文件中确认最终选用的是哪个目标文件的符号。
2026-11-01
↳ STM32 ADC 注入通道与规则通道交替采样时，如何避免JDR寄存器覆盖导致的数据错位
核心是让注入通道的JDR读取与规则通道的DR读取在时序上解耦，避免注入转换在规则DMA搬运期间抢占JDR。实操建议：1) 规则通道用DMA循环模式搬运到独立缓冲区，注入通道用JEOC中断单独读取JDRx，且中断优先级高于DMA；2) 注入组一次只配置1个通道，JEOC中立即读JDR并清标志，避免连续注入覆盖；3) 若需多注入通道，用JDRx多寄存器分别映射，不要复用同一JDR；4) 规则组与注入组触发源分开（如TIM1_CC4触发注入、软件触发规则），并保证注入转换不插入规则DMA传输的临界区；5) 必要时在JEOC中短暂关闭规则DMA请求，读完JDR再恢复，或使用双ADC交替模式让注入由主ADC、规则由从ADC分担。关键原则：JDR只允许在JEOC后单次读取，绝不轮询。
2026-10-25