wdfk-prog的个人博客

autogen_parameter_manager：面向固件产品参数的生成式管理软件包 仓库地址: https://github.com/wdfk-prog/parameters@[toc] 推荐判断在嵌入式产品中，参数管理通常会从几个配置变量开始。早期代码里直接定义全局变量，或者在某个模块中保存默认值，短期内成本很低。项目继续推进后，参数会进入更多流程：生产标定需要写入校准值，现场调试需要临时修改阈值，上位机需要读取和展示配置，售后脚本需要批量检查状态，固件升级还要考虑旧版本已经保存的数据是否仍然可用。 到这个阶段，真正需要维护的已经不是单个变量，而是一组产品参数的长期接口。每个参数都可能同时包含外部 ID、类型、默认值、最小值、最大值、单位、说明、读写属性、持久化标记和版本兼容关系。只要这些信息分散在协议代码、shell 命令、业务模块和存储代码中，后续迭代就容易出现规则不一致。 autogen_parameter_manager 适合用于这类固件项目。它把参数表作为事实源，生成固件侧需要的参数定义、ID 映射、静态布局和摘要信息；运行时再基于这些生成数据提供类型化访...

[TOC] 嵌入式新项目与重构中使用 AI 辅助实现的真正风险：不是 AI 越界，而是工程师逐渐把方向盘交出去 面向：嵌入式 C/C++、MCU、RTOS、驱动框架、BSP 适配、硬件抽象层、底层库重构。核心观点：在 AI 辅助新项目或大规模重构中，最危险的不是一开始没有写边界，而是多轮执行后工程师疲劳、焦虑或不耐烦，主动放开边界，让 AI 以“更通用、更完整、更兼容”为名接管需求解释和架构扩张。 结论在嵌入式代码的新项目和重构中，AI 带来的主要风险并不是“它会不会生成一段错误代码”。错误代码反而容易被编译器、静态检查、单元测试、硬件验证或工程师经验发现。更隐蔽、更容易造成长期损失的风险是：工程师一开始知道自己要做什么，也写了目标、边界和约束，但在多轮 AI 实现、AI 审核、AI 修改之后，逐渐把这些边界放开了。 这种放开往往不是一次性发生的。它通常以非常合理的形式出现： “这是新项目，可以不兼容旧接口。” “既然以后可能支持更多芯片，那就先兼容一下。” “AI 说这个特殊功能不支持会有问题，那就加上。” “这轮先让 AI 改，改完再审。” “既然另一个...

@[toc] 面向 MCU 与 RTOS 的 Newlib、Newlib-nano、--specs=nano.specs 与 _REENT_SMALL 说明 适用对象：使用 GCC/Arm GNU Toolchain、RT-Thread、FreeRTOS、Zephyr 或类似 MCU RTOS 的嵌入式 C/C++ 工程。重点问题：newlib 是什么、为什么 MCU 工程会链接它、newlib-nano 如何减少体积、--specs=nano.specs 和 _REENT_SMALL 的作用与风险，以及如何不选用 newlib 而改为工程自实现或替换部分函数。 1. 结论先行在 MCU/RTOS 工程里，newlib 可以理解为 GCC 裸机/嵌入式工具链常用的 C 标准库实现。它提供 memcpy、memset、strlen、printf、snprintf、malloc、free、errno、time、strtok 等标准 C 或类 POSIX 接口，但它并不知道你的硬件上有什么 UART、文件系统、heap、线程或设备驱动。...

@[toc] 联网搜索会污染大模型判断吗？——面向日常开发场景的工程化分析 结论会。 但这里的“污染”不是说模型一联网就会把自己训练坏，也不是说联网搜索一定有害。更准确地说： 联网搜索会把外部信息带入当前上下文；如果没有边界控制，模型可能把外部资料、外部项目、外部假设、外部版本、甚至外部网页中的隐藏指令当成当前任务依据。 在日常开发中，这种问题很常见。你本来只是让模型基于当前项目修一个 Bug、改一个接口、补一段文档、优化一段代码，但联网以后，模型可能开始参考： 别的项目的实现方式； 新版本框架的 API； 与当前技术栈不一致的最佳实践； 过期或不适用的博客； Stack Overflow 上的片段； AI 生成的网页内容； 第三方文档中的隐藏提示词； 当前项目根本没有采用的架构模式。 结果就是：模型回答看起来更“有资料依据”，但可能更偏离当前项目事实。 所以，日常开发中使用联网搜索，关键不是“开还是不开”，而是： 1234什么时候可以联网？联网只解决什么问题？外部资料能不能进入最终代码？当前项目事实和外部资料冲突时听谁的？ 1. 先区分三种“污染”讨论联网搜索污...

@[toc] GitHub 开源项目可以用哪些免费的 AI 代码审核工具？CodeRabbit、Qodo OSS、LlamaPReview 怎么选 AI 代码审核工具正在进入开源项目的日常维护流程。它们不应该替代 maintainer 的最终判断，但可以承担一部分重复性初审工作，例如总结 PR、提示潜在问题、指出缺少测试或文档的地方，并帮助贡献者更快理解修改影响。 如果你的仓库是 GitHub public 开源仓库，可以优先关注这些免费或开源友好的 AI 审核工具： CodeRabbit Qodo OSS / Qodo Merge LlamaPReview PR-Agent，适合愿意自托管或自己配置模型的团队 本文重点比较前三个 GitHub 上更容易直接开通的方案。 先理解“免费”的几种含义GitHub Marketplace 上的“免费”并不完全一样，常见有三类： 类型 含义 使用建议 Open Source Free public 开源仓库免费，私有仓库通常收费 最适合开源项目 Free Tier 有免费额度，超过后限流或收费 可以用...

@[toc] Multi-Pass Review 还不够：为什么还需要专项 Profile 和 Fresh Diff Scope 开篇：多轮审核解决的是“不稳定”，但还没有完全解决“看不全”在大模型代码审核场景中，Multi-Pass Review 是一个很重要的进步。 它不再把代码审核交给一次临场回答，而是通过多轮独立审查、结构化输出和聚合规则，把大模型的审核行为变得更稳定、更可复查、更接近工程流程。 但是，只做到 Multi-Pass 仍然不够。 因为 Multi-Pass 主要解决的是“单次判断不稳定”的问题，而代码审核中还有另外两个更隐蔽的问题： 领域覆盖不完整：模型虽然看了多轮，但每轮可能都在用相同的通用视角看问题，导致领域特定风险长期漏检。 审查范围不新鲜：复审时如果沿用旧 packet、旧结论或旧问题清单，模型可能只验证历史问题，而没有重新审查当前 diff 的完整状态。 这两个问题如果不解决，Multi-Pass Review 很容易变成“重复三次通用审核”。它比单轮回答稳定，但还不是一个足够强的工程化代码审核 Skill。 因此，在 Multi-Pass...

@[toc] 为什么需要一个 Multi-Pass Review Skill：让大模型代码审核从“会说”变成“可控” 开篇：大模型已经能审代码，但还不能无约束地审代码大模型进入软件工程之后，最容易被低估的能力之一，是代码审核。 它能读 diff，能指出可疑逻辑，能解释风险，能补充测试建议，也能把复杂变更整理成清晰的审查报告。对于开发者来说，这种能力非常有吸引力：过去需要同事花时间帮忙看的改动，现在可以先交给模型过一遍；过去需要反复检查的错误路径、参数契约和边界条件，现在模型能快速给出一组候选问题。 但是，只要真正把大模型放进代码审核流程里，就会遇到一个很现实的问题： 大模型能发现问题，但它的发现过程不稳定。 它有时能指出非常关键的 bug；有时会漏掉明显风险；有时会把不存在的问题讲得很有说服力；有时会在没有证据的情况下假设某个调用方、配置项、运行环境或历史背景存在。 这不是简单的“模型不够聪明”。这是一类结构性问题。 因为代码审核不是问答题，而是工程判断。它要求模型同时处理： diff 中实际出现了什么； 改动前后的契约是否一致； 新增路径是否覆盖失败和回滚场景； 删...

@[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...

@[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 也有明显代价： 代码通常更大、更慢 时序行为更容易偏离发布版 ...

@[toc] MCU内核电压不稳导致程序跑飞的现象、原因与影响 一、问题概述本次异常的本质不是单纯的软件逻辑错误，而是内核供电不稳定引发的系统级异常。当芯片内部核心电压不能被稳定维持时，CPU、总线、外设控制逻辑都会受到影响，最终表现为程序执行异常，也就是现场常说的“跑飞”。 这类问题通常具有较强的迷惑性：表面看像是线程异常、定时器异常、偶发 HardFault，甚至像软件定时或中断处理有问题；但实际根因在于供电相关电路未按规格书要求正确连接，导致内核工作电压不稳定。 二、典型现象内核电压不稳时，系统通常不会一上电立即完全失效，而是表现出一定的随机性和偶发性，常见现象包括： 1. 运行一段时间后随机异常系统上电后可以启动，基本功能初期也可能正常，但运行一段时间后会突然出现异常，表现为： 程序卡死 线程调度异常 某些任务不再按预期运行 定时行为紊乱 2. 异常位置不固定问题出现时，表面上的故障点往往并不一致，例如： 有时记录在线程上下文 有时表现为中断处理异常 有时进入 HardFault 有时停在某个看似无关的函数或流程中 这类“落点不固定”的问题，正是供电不稳的典型特...