-
MQTT 协议详解：QoS、遗嘱与断线重连
MQTT 跑在 TCP 之上，报文头最小只有 2 字节，这套设计是为窄带宽、高延迟、不稳定的链路准备的。理解它的关键点不在于"能连上发消息"，而在于想清楚消息在哪个环节可能丢、丢了之后由谁负责重发。 发布订阅模型与 broker 的位置 设备不直接互相寻址。发布者把消息发到 broker，带上一个主题字符串；订阅者提前告诉 broker 自己关心哪些主题；broker 负责匹配和转发。这个解耦带来
苏念禾
-
IoT 设备安全：认证、加密与固件防篡改
一批同型号设备共用同一套密钥时，破解其中一台的成本会被均摊到全部设备上。单台的破解难度也许只是"拆开外壳、读一次 flash"，但当它换来十万台设备的身份，投入产出比就变了。设备安全的许多设计，本质是抬高杠杆的另一头。 设备身份：一机一密还是全网共享 设备接入时服务端要回答：连上来的到底是不是我出厂的那台。答案的可靠程度取决于身份密钥的粒度。 方案 身份唯一性 吊销粒度 产线要求 单台被破波及范围
硅屿
-
低功耗设计：休眠模式与功耗预算
电池供电设备的续航不是靠某一个技巧凑出来的，而是一开始就按功耗预算倒推出来的。先把平均电流的目标定下来，再往回拆每个环节能花多少，这是唯一可控的路径。 功耗的四个来源 运行电流 ：MCU 跑代码、外设工作时的电流。主频和供电电压越高电流越大。同一任务用高主频跑完再休眠往往比低主频慢慢跑更省电——这就是后面说的占空比思维。 休眠电流 ：内核停止但部分电路仍工作时的电流。这是决定续航的关键量，因为设备
林砚
-
边缘计算实践：设备侧推理与数据聚合
把计算放到设备侧，出发点是"数据传不动"或者"数据不该传"。想清楚到底是哪一条在驱动，才能决定该放多少算力在端上。 为什么要算在设备侧 带宽 ：一路摄像头或者振动传感器的原始数据量级远大于蜂窝网络的实际可用上行带宽，全量上传既不现实也不经济。在端上做一帧推理，只把结果和少量特征传上去，流量能降几个数量级。 时延 ：云端往返的时延量级在几十到几百毫秒，且抖动大。闭环控制、联动响应这类场景等不起，本地
码同客
-
IoT 固件 OTA：差分升级与回滚
OTA 的风险不在下载过程，而在"写进去之后能不能跑起来"和"跑不起来怎么办"。所有 OTA 设计都围绕这两点：让失败可检测，让失败可回退。 分区方案的取舍 单分区 + 备份区 ：运行区只有一个，升级时把新固件下载到备份区，校验后由 bootloader 拷贝到运行区。地址固定、代码无需位置无关处理；但拷贝期间断电会留下半个固件。 A/B 双分区 ：flash 里放两个同样大小的应用分区，设备总是
许既白
-
嵌入式 C 的内存管理：栈、堆与静态分配
MCU 上写 C 和写 Linux 应用最大的区别之一是内存是"看得见"的：编译链接完就能算出静态占用多少，剩下的 RAM 全部归栈和堆。搞清楚这五段分别装什么、在哪里定义，是排查内存类故障的前提。 五段布局与链接脚本 一段典型的布局（地址从低到高，具体排列以芯片手册和链接脚本为准）： 段 内容 存放位置 .text 代码、常量、中断向量表 flash .rodata const 数据、字符串字面
KernelPan
-
传感器数据采集：采样率、滤波与校准
ADC 读回来的数字只是"某个时刻的某个电压"，从它到"可信的物理量"之间还有采样、滤波、校准三段路。这三段各自有各自的坑，而且互相耦合——采样率定错了，后面再好的滤波器也救不回来。 奈奎斯特与为什么要过采样 奈奎斯特采样定理说的是：采样频率必须大于信号最高频率的两倍，才能无失真地重建信号。低于这个频率，高频成分会混叠成低频假信号——你在数据里看到的"缓慢波动"，可能根本不存在，只是混叠的产物。
KernelPan
-
串口通信调试：协议解析与常见故障
串口看起来是最简单的外设，接三根线就能通。它的故障也大多不是协议层的，而是电平、地线、时序这些物理层面的问题。排查时先确认物理层，再谈协议解析，顺序反了会浪费大量时间。 UART 帧结构 一帧数据的构成： [起始位] [数据位 5~9] [校验位 可选] [停止位 1/1.5/2] 0 LSB 先发 奇/偶/无 1 空闲时 TX 保持高电平。起始位是一个位的低电平，接收方靠这个下降沿做位同步。数据
Embedded 徐
-
RTOS 入门：任务调度与同步原语
裸机程序写久了会习惯用一个 while(1) 串起所有事情：读传感器、算一遍、刷屏、再看有没有按键。功能简单时这个结构工作得很好，直到某个环节耗时开始不稳定——显示刷新从 2ms 变成 200ms，按键响应跟着劣化。RTOS 解决的是同一件事，但把"谁先跑"从代码书写顺序交给了调度器。 从超级循环到多任务 超级循环加中断的结构常被称为前后台：中断处理紧急事务，主循环依次做常规事务。它的调度是隐式的
何遇
-
ESP32 开发入门：从点灯到联网上报
从点灯到把数据稳定送到云端，中间隔着 GPIO 电气特性、RTOS 任务调度、WiFi 状态机、看门狗四件事。这四件事里任何一个没想清楚，设备都会在跑一段时间之后才出问题。 开发框架的定位差异 ESP-IDF 是官方框架，直接基于 FreeRTOS，暴露完整的组件配置（menuconfig）、分区表、驱动层。适合需要对内存布局、外设时钟、低功耗模式做精细控制的项目。构建基于 CMake，组件化的目
Kernighan 林