为什么需要一个 Multi-Pass Review Skill：让大模型代码审核从“会说”变成“可控”
@[toc] 为什么需要一个 Multi-Pass Review Skill：让大模型代码审核从“会说”变成“可控” 开篇：大模型已经能审代码，但还不能无约束地审代码大模型进入软件工程之后，最容易被低估的能力之一，是代码审核。 它能读 diff，能指出可疑逻辑，能解释风险，能补充测试建议，也能把复杂变更整理成清晰的审查报告。对于开发者来说，这种能力非常有吸引力：过去需要同事花时间帮忙看的改动，现在可以先交给模型过一遍；过去需要反复检查的错误路径、参数契约和边界条件，现在模型能快速给出一组候选问题。 但是，只要真正把大模型放进代码审核流程里，就会遇到一个很现实的问题： 大模型能发现问题，但它的发现过程不稳定。 它有时能指出非常关键的 bug；有时会漏掉明显风险；有时会把不存在的问题讲得很有说服力；有时会在没有证据的情况下假设某个调用方、配置项、运行环境或历史背景存在。 这不是简单的“模型不够聪明”。这是一类结构性问题。 因为代码审核不是问答题，而是工程判断。它要求模型同时处理： diff 中实际出现了什么； 改动前后的契约是否一致； 新增路径是否覆盖失败和回滚场景； 删...
解决 Linux 使用符号链接的 Git 仓库在 Windows 下无法创建符号链接的问题
@[toc] 解决 Linux 使用符号链接的 Git 仓库在 Windows 下无法创建符号链接的问题本文说明：当一个在 Linux 下正常使用 符号链接（symlink） 的 Git 仓库，被拉到 Windows 上后，出现 无法创建符号链接、symlink 被检出成普通文本文件、编译时报 expected identifier or '(' before '.' token 等问题时，应该如何定位和解决。 适用场景： 仓库中有大量 *.c / *.h / 资源文件通过符号链接复用 在 Linux 或 macOS 上工作正常 到 Windows 上后，git clone、git checkout、git reset --hard、构建或 IDE 索引阶段出现异常 先看典型现象这类问题在 Windows 上通常表现为两组症状。 现象 1：Git 无法恢复符号链接例如执行检出、重置、清理后，Git 报错： 1error: unable to create symlink <link-path>: Permi...
GCC 的 `-O0`、`-Og` 与发布版调试说明
@[toc] GCC 的 -O0、-Og 与发布版调试说明 结论 -O0：基本关闭大多数优化，调试时更接近源码书写顺序。 -Og：不是完全不优化，而是“为了调试体验而保留一部分优化”。 因为 -Og 仍然会做一部分优化，所以它不能按 -O0 的方式理解；单步、变量位置、控制流都可能和 -O0 不同。 如果发布版本使用 -Os，那么定位发布版问题时，通常更适合使用 -Os -g -gdwarf-2，而不是切回 -Og 或 -O0。 -g 的作用是生成调试信息。 -gdwarf-2 的作用是强制调试信息使用 DWARF2 格式，常用于兼容较旧的 GDB、IDE 或嵌入式调试器。 -O0 和 -Og 的核心区别-O0-O0 是 GCC 的默认优化级别。它会关闭大多数优化阶段，目标是让： 编译结果尽量直接 机器指令和源码的对应关系更直观 单步调试更容易按源码顺序观察 因此，-O0 更适合这些场景： 你要确认某一行到底有没有执行 你要观察最原始的控制流 你要尽量减少“编译器改写代码形态”带来的干扰 但 -O0 也有明显代价： 代码通常更大、更慢 时序行为更容易偏离发布版 ...
MCU内核电压不稳导致程序跑飞的现象、原因与影响
@[toc] MCU内核电压不稳导致程序跑飞的现象、原因与影响 一、问题概述本次异常的本质不是单纯的软件逻辑错误，而是内核供电不稳定引发的系统级异常。当芯片内部核心电压不能被稳定维持时，CPU、总线、外设控制逻辑都会受到影响，最终表现为程序执行异常，也就是现场常说的“跑飞”。 这类问题通常具有较强的迷惑性：表面看像是线程异常、定时器异常、偶发 HardFault，甚至像软件定时或中断处理有问题；但实际根因在于供电相关电路未按规格书要求正确连接，导致内核工作电压不稳定。 二、典型现象内核电压不稳时，系统通常不会一上电立即完全失效，而是表现出一定的随机性和偶发性，常见现象包括： 1. 运行一段时间后随机异常系统上电后可以启动，基本功能初期也可能正常，但运行一段时间后会突然出现异常，表现为： 程序卡死 线程调度异常 某些任务不再按预期运行 定时行为紊乱 2. 异常位置不固定问题出现时，表面上的故障点往往并不一致，例如： 有时记录在线程上下文 有时表现为中断处理异常 有时进入 HardFault 有时停在某个看似无关的函数或流程中 这类“落点不固定”的问题，正是供电不稳的典型特...
FNV-1a 64-bit 在 MCU-32bit 上的实现与取舍：从原理、代码到适用边界
FNV-1a 64-bit 在 MCU-32bit 上的实现与取舍：从原理、代码到适用边界先看核心结论FNV-1a 64-bit 的重点，不是“32 位 MCU 能不能跑 64 位整数”，而是下面三件事： 这个散列为什么能工作。 代码实现里每一步到底在做什么。 哪些场景适合用，哪些场景不适合用。 把这三件事讲清楚后，再讨论 32-bit 和 64-bit 的工程取舍，结构会更稳，也更接近实际选型过程。 FNV-1a 的标准更新过程可以概括成一条固定循环： 状态从 offset_basis 开始 每读取一个字节，先异或进状态 再乘上固定的 FNV_Prime 运算结果保留在固定比特宽度内 对 64-bit 版本，标准常量是： 12#define FNV1A64_OFFSET_BASIS 0xCBF29CE484222325ULL#define FNV1A64_PRIME 0x00000100000001B3ULL 这两个常量不是任意挑选出来的。offset_basis 决定初始状态，FNV_Prime 决定每次吸收新字节后如何扩散已有状态。 先把原...
一次由 C 位域非原子写入引发的状态上报异常
@[toc] 一次由 C 位域非原子写入引发的状态上报异常在一套嵌入式控制固件中，出现过一类很典型、但又很容易被忽略的异常：传感器物理状态已经持续触发，心跳报文却长时间仍然上报为 0；重新手动触发一次后，状态又恢复正常。 表面上看，这类问题很像采样抖动、消息队列满、或者 CAN 发送延迟。但沿着发送链路继续深挖后，真正的问题并不在总线，也不在消息队列，而是在 C 语言位域写入不是原子操作 这一点上。 先看现象，不要先怪 CAN异常表现有几个很强的特征： 传感器已经进入触发状态，并且维持了很长时间。 心跳报文仍然持续发送，但目标状态位始终是 0。 再次手动触发一次传感器后，状态恢复正常。 不是“完全没报文”，而是“报文一直有，但某一位一直不对”。 这类现象说明一件事：发送通道本身大概率是通的。如果 CAN 队列、发送线程、或总线仲裁是主因，更常见的表现会是丢帧、延迟、或整帧不发，而不是“整帧一直发，但某一位长期错误”。 因此，排查重点不该先放在“是否发出去”，而应该放在“发出去的那 8 个字节是谁构造的，以及构造时有没有被并发写坏”。 位域写入通常是读改写，不是原子更...
MAX14830 可移植 C 驱动实现分析：一个适合多串口扩展场景的开源基础版本
@[toc] MAX14830 可移植 C 驱动实现分析：一个适合多串口扩展场景的开源基础版本在嵌入式系统中，串口资源不足是一个非常常见的问题。当主控需要同时连接调试接口、通信模组、下位机设备或多路传感器时，片上 UART 数量往往很快成为限制条件。此类场景下，外扩串口芯片通常是更现实的方案，而 MAX14830 就是其中较典型的一种：通过 SPI 或 I2C 总线，可以扩展出 4 路独立 UART，同时提供 FIFO 和 GPIO 能力，适合承担多串口桥接角色。 GitHub 上的 wdfk-prog/max14830，就是一个面向这颗芯片的开源 C 驱动实现。这个项目的重点不在“做了多少高级功能”，而在于它明确采用了 可移植、平台无关、基于 HAL 抽象 的实现思路。对于正在做 MAX14830 接入、板级驱动开发，或者准备搭建多串口扩展方案的人来说，这类代码通常比单平台 Demo 更有参考价值。 仓库地址: https://github.com/wdfk-prog/max14830 项目定位很明确：不是平台示例，而是通用驱动骨架从仓库主页给出的描述来看，...
M104BPCSX-5024 RFID 驱动与应用层开源实现分析
@[toc] M104BPCSX-5024 RFID 驱动与应用层开源实现分析wdfk-prog/m104bpcsx_5024 是一个面向 M104BPCSX-5024 RFID 模块的开源实现，项目以 C 语言编写，围绕 RFID 模块接入的典型嵌入式应用场景，构建了较完整的驱动层与应用层一体化方案。从仓库公开信息来看，该项目不仅提供了底层协议封装与通信接口实现，还进一步覆盖了多通道轮询、RTOS 线程调度、CAN 总线结果上报以及功耗控制等业务逻辑，具备较强的工程参考意义。 与常见仅停留在寄存器读写或单一通信接口封装的示例工程不同，该项目更接近真实产品环境中的 RFID 子系统实现方式，尤其适合作为以下方向的参考样例： 嵌入式驱动分层设计 SPI / UART 双通信路径抽象 基于 RTOS 的设备轮询任务组织 多通道 RFID 读卡器管理 CAN 总线状态上报集成 一、项目定位与功能概述该项目面向 M104BPCSX-5024 RFID 模块，目标是构建一套可移植、可扩展、适用于多硬件接入方案的驱动与应用实现框架。项目核心功能包括： 对多个 RFID...
Qboot V2：让 Bootloader 从“能升级”走向“可持续演进”
@[toc] Qboot V2：让 Bootloader 从“能升级”走向“可持续演进”固件升级这件事，早已不只是“把新程序写进去”这么简单。 在不少 MCU 项目中，最初的目标通常很明确：先把 Bootloader 做出来，先把固件升级跑通，先让设备具备基本的远程维护能力。这样的阶段里，结构简单、接入直接、功能够用，往往比“架构漂亮”更重要。 Qboot V1 正是在这样的背景下体现出价值。它最初的定位就是一个用于快速制作 bootloader 的组件，目标非常务实：把启动、分区、校验、解密、解压、恢复和升级这些关键环节尽快组织起来，让升级链路尽早落地。现有公开版本中，已经包含 AES、GZIP、QuickLZ、FastLZ、HPatchLite、OTA downloader 等能力，本身并不是一个“只有基础功能”的轻量壳子，而是一套已经能够解决实际问题的升级组件。 但项目一旦继续往前推进，问题就会开始变化。 最开始关心的是“能不能升级”，很快就会变成`“升级能不能稳定跑”``“能不能适配更多存储方式”“能不能支持更多算法”“能不能减少包体积”“能...
hid-core
[toc] HID Core：全面了解与深度解析文件路径 / 技术中文名 / 功能概述 文件路径：drivers/hid/hid-core.c 技术中文名：HID 核心层驱动 功能概述：hid-core.c 是 Linux HID 子系统的公共核心实现，负责 HID 报告描述符解析、设备分组、驱动匹配、输入报告解释、事件分发，以及 hidinput、hidraw、hiddev 等上层消费路径的连接。它本身不是 USB、I2C、Bluetooth 这类传输驱动，而是位于这些传输驱动之上的通用 HID 核心。 介绍drivers/hid/hid-core.c 在 Linux HID 栈中的位置非常明确：它属于 HID bus 的公共核心层，不直接负责总线收发，也不直接等同于输入子系统驱动。它的职责是把“某个传输层送上来的 HID 设备”和“上层具体的 HID 驱动、input 接口、hidraw 接口、hiddev 接口”连接起来。 从当前主线实现看，HID 子系统被组织成一种总线模型。传输驱动负责设备发现、底层收发、设备启动与停止；hid-core.c ...
