嵌入式

树莓派光照传感器：实时采集环境光照强度数据

基于HC-SR501传感器的人体检测装置制作教程

树莓派温湿度监测：DHT11/DHT22传感器实战教程

树莓派全新上手指南：从零开始玩转微型单板计算机

自抗扰控制（ADRC）替代PID，无人机FOC中的下一代控制算法

在无人机电机控制领域，PID控制器已经统治了数十年。它结构简单、参数直观、实现容易，几乎成了嵌入式开发的入门必修课。但随着无人机应用场景的拓展——高原巡检、重载运输、高速竞速——PID的局限性正变得越来越明显：它处理不了外部扰动带来的持续性误差，也无法适应环境变化引起的模型漂移。自抗扰控制正在从学术界走向工程界，成为FOC系统中PID的有力替代者。

中断优先级分组：NVIC配置如何影响FreeRTOS的实时性？

同一套代码，换个中断分组，系统响应时间能差出一个数量级。这不是夸张——FreeRTOS的实时性，有一半捏在NVIC优先级分组的手里。多数开发者只知道"设置优先级"，却不知道分组方式选错了，整个调度体系就从"确定性实时"退化成"看运气响应"。

栈溢出检测的三种方法：水位线法、钩子函数与MPU硬件防护

嵌入式RTOS开发，栈溢出是最常见也最隐蔽的运行时错误之一。一个任务分配的栈空间不足，并不会立即导致系统崩溃——而是静默地覆盖相邻的内存区域，可能破坏另一个任务的控制块、篡改全局变量，甚至在数小时后才触发一个莫名其妙的HardFault。FreeRTOS提供了三种不同层级的栈溢出检测方法，它们分别适用于开发调试、生产部署和安全苛求等不同场景。

优先级继承协议（PIP）在FreeRTOS中的实现，Mutex如何自动解决优先级反转

实时系统最怕什么?不是任务跑得慢，是高优先级任务被低优先级任务"绑架"。这就是优先级反转——实时系统里最阴险的调度陷阱。FreeRTOS的互斥量(Mutex)内置了优先级继承协议(Priority Inheritance Protocol, PIP)，不需要你写一行额外代码，内核自动完成优先级提升与恢复。理解它的实现原理，才能真正用好这个机制。

用FreeRTOS实现MCU的多级休眠策略：从睡眠到深度睡眠的任务切换

电池供电的物联网设备中，MCU的功耗往往占据系统总功耗的相当比重。一个典型的传感器节点可能每秒采集一次数据，其余时间都在等待。如果让MCU在这段时间内全速运行，电池能量将很快耗尽。FreeRTOS提供了Tickless低功耗模式，但仅支持“全速运行”和“深度睡眠”两级切换。在多级休眠策略下，系统可以根据空闲时间的长短动态选择不同深度的休眠模式，从而在功耗和唤醒延迟之间取得最佳平衡。

用ChibiOS实时操作系统跑FOC：比FreeRTOS快在哪里？

同样跑FOC，一个电流环抖5微秒，一个抖50微秒——差距就在操作系统的骨子里。ChibiOS和FreeRTOS都能跑电机控制，但当你把示波器接上去看电流波形，ChibiOS的干净程度会让你重新理解"实时"两个字。快，不是营销话术，是纳秒级的工程事实。

无人机FOC调试的五大经典翻车现场与排查手册

在无人机FOC电调的调试过程中，总会遇到一些让人摸不着头脑的问题。电机像踩了刹车一样堵转，PWM波形忽快忽慢，电机尖叫着发烫就是不转。这些问题往往不是PID参数没调好，而是代码配置、硬件连接或时序逻辑中藏着某些容易被忽略的错误。以下从实测数据出发，梳理五个经典“翻车”现场及其排查方法。

三相电流采样的三种拓扑：低侧电阻、高侧电阻与单电阻方案的精度对决

在电机驱动系统中，电流采样精度决定了FOC控制的性能上限。采样误差会导致转矩脉动、效率下降，甚至触发过流保护。目前主流的电流采样方案有三种：低侧电阻采样、高侧电阻采样和直流母线单电阻采样。它们各自在精度、成本和复杂度之间做出了不同的取舍。本文将系统解析三种方案的测试原理、实测数据与工程意义。

内存池（Memory Pool）设计：如何用FreeRTOS实现零碎片的对象分配？

在嵌入式实时系统中，动态内存分配向来是一把双刃剑。一方面，它带来了灵活性，允许系统在运行时按需分配资源;另一方面，标准堆分配算法的时间不确定性和内存碎片问题，在实时系统中可能成为致命缺陷。FreeRTOS内核自身的任务、队列等对象创建时，默认就是从堆中分配内存的。但如果想在应用层也实现高效、零碎片、时间恒定的对象分配，就需要设计专用的内存池。

基于UART的电调参数实时修改：飞行中调PID的工程实现

在无人机调试过程中，工程师常常面临一个令人沮丧的场景：悬停测试发现电机响应过冲，需要降低P值，于是降落后连接USB线，打开上位机，写入参数，解锁升空，再次测试，发现调整过头了，于是重复上述流程。每轮调试需要3-5分钟，而实际调参时间不到30秒。这种“落地-接线-烧写-起飞”的循环，在户外调试现场尤为耗时。

互斥量（Mutex）vs 信号量（Semaphore）：90%的开发者都用错了

互斥量和信号量长得像，用法像，连API都像——但它们的设计意图完全相反。互斥量管的是"谁能进这扇门"，信号量管的是"还剩几张票"。用错了，轻则优先级反转死锁，重则整个系统卡死。90%的开发者把二进制信号量当互斥量用，这是FreeRTOS里最贵的一个错误。