u-boot 学习笔记
u-boot 学习笔记 u-boot分类 1.1. api 1.1.1. api.md 1.2. arch 1.2.1. arm 1.2.1.1. arm.md 1.2.1.2. assembly.md 1.2.2. arch.md 1.3. boot 1.3.1. bootm.md 1.3.2. bootretry.md 1.3.3. bootz.md 1.3.4. image.md 1.4. cmd 1.4.1. cmd.md 1.5. common 1.5.1. autoboot.md 1.5.2. board.md 1.5.3. cli.md 1.5.4. command.md 1.5.5. console.md 1.5.6. dmalloc.md 1.5.7. event.md 1.5.8. export.md 1.5.9. log.md 1.5.10. main.md 1.6. dm 1.6.1. adc.md 1.6.2. button.md 1.6.3. clock.md 1.6.4. core.md 1.6.5. dts.md 1....
RT-Thread 学习笔记
RT-Thread 学习笔记 其他资料 1.1. fatfs 1.1.1. fatfs.md 2. ARM指针寄存器.md 3. CAN驱动.md 4. completion.md 5. condvar.md 6. dataqueue.md 7. DFS.md 8. fal.md 9. fatfs.md 10. FINSH模块.md 11. I2C驱动.md 12. IDLE线程.md 13. IPC.md 14. littlefs.md 15. map文件分析.md 16. pipe.md 17. PM电源管理.md 18. readme.md 19. ringblock.md 20. ringbuffer.md 21. romfs.md 22. RTC.md 23. RT-LINK.md 24. RTT系统初始化.md 25. SDMMC.md 26. SIGNAL.md 27. SPI驱动.md 28. tmpfs.md 29. ULOG.md 30. USB.md 31. waitqueue.md 32. 串口驱动.md 33. 调度.md 34. 工作队列...
嵌入式新项目与重构中使用 AI 辅助实现的真正风险：不是 AI 越界，而是工程师逐渐把方向盘交出去
[TOC] 嵌入式新项目与重构中使用 AI 辅助实现的真正风险：不是 AI 越界，而是工程师逐渐把方向盘交出去 面向：嵌入式 C/C++、MCU、RTOS、驱动框架、BSP 适配、硬件抽象层、底层库重构。核心观点：在 AI 辅助新项目或大规模重构中，最危险的不是一开始没有写边界，而是多轮执行后工程师疲劳、焦虑或不耐烦，主动放开边界，让 AI 以“更通用、更完整、更兼容”为名接管需求解释和架构扩张。 结论在嵌入式代码的新项目和重构中，AI 带来的主要风险并不是“它会不会生成一段错误代码”。错误代码反而容易被编译器、静态检查、单元测试、硬件验证或工程师经验发现。更隐蔽、更容易造成长期损失的风险是：工程师一开始知道自己要做什么，也写了目标、边界和约束，但在多轮 AI 实现、AI 审核、AI 修改之后，逐渐把这些边界放开了。 这种放开往往不是一次性发生的。它通常以非常合理的形式出现： “这是新项目，可以不兼容旧接口。” “既然以后可能支持更多芯片，那就先兼容一下。” “AI 说这个特殊功能不支持会有问题，那就加上。” “这轮先让 AI 改，改完再审。” “既然另一个...
面向 MCU 与 RTOS 的 Newlib、Newlib-nano、`--specs=nano
@[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. 先区分三种“污染”讨论联网搜索污...
GitHub 开源项目可以用哪些免费的 AI 代码审核工具？CodeRabbit、Qodo OSS、LlamaPReview 怎么选
@[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 有免费额度，超过后限流或收费 可以用...
Multi-Pass Review 还不够：为什么还需要专项 Profile 和 Fresh Diff Scope
@[toc] Multi-Pass Review 还不够：为什么还需要专项 Profile 和 Fresh Diff Scope 开篇：多轮审核解决的是“不稳定”，但还没有完全解决“看不全”在大模型代码审核场景中，Multi-Pass Review 是一个很重要的进步。 它不再把代码审核交给一次临场回答，而是通过多轮独立审查、结构化输出和聚合规则，把大模型的审核行为变得更稳定、更可复查、更接近工程流程。 但是，只做到 Multi-Pass 仍然不够。 因为 Multi-Pass 主要解决的是“单次判断不稳定”的问题，而代码审核中还有另外两个更隐蔽的问题： 领域覆盖不完整：模型虽然看了多轮，但每轮可能都在用相同的通用视角看问题，导致领域特定风险长期漏检。 审查范围不新鲜：复审时如果沿用旧 packet、旧结论或旧问题清单，模型可能只验证历史问题，而没有重新审查当前 diff 的完整状态。 这两个问题如果不解决，Multi-Pass Review 很容易变成“重复三次通用审核”。它比单轮回答稳定，但还不是一个足够强的工程化代码审核 Skill。 因此，在 Multi-Pass...
为什么需要一个 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 也有明显代价： 代码通常更大、更慢 时序行为更容易偏离发布版 ...
