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. 工作队列...
嵌入式通信中的适用场景
@[toc] RPC 是什么：原理、边界与工业/嵌入式通信中的适用场景 摘要： RPC（Remote ProcedureCall，远程过程调用）把跨节点通信抽象成“调用远端函数”，解决的是接口抽象、参数序列化、请求/响应匹配、跨语言代码生成和工具化问题。它不解决物理层、链路层、总线仲裁、实时调度和广播多回应聚合问题。因此，RPC更适合点对点、低频、结构化的控制/配置/调试接口；不适合高频实时PDO、广播控制、硬实时闭环和多主多从共享总线仲裁。工业和嵌入式系统中，更稳妥的做法是把通信拆成实时数据面、诊断配置面和工具调试面：实时数据面使用原生CAN/PDO；诊断配置面使用 UDS/ISO-TP、CANopen SDO 或Modbus；工具调试面再考虑 eRPC/gRPC 这类 RPC。 一、RPC 是什么：诞生背景与核心抽象RPC的直译是“远程过程调用”。它试图解决一个长期存在的软件工程问题：当一个程序需要使用另一台机器、另一个进程、另一个CPU 核或另一个 MCU 上的能力时，能否像调用本地函数一样调用远端...
autogen_parameter_manager：面向固件产品参数的生成式管理软件包
autogen_parameter_manager：面向固件产品参数的生成式管理软件包 仓库地址: https://github.com/wdfk-prog/parameters@[toc] 推荐判断在嵌入式产品中，参数管理通常会从几个配置变量开始。早期代码里直接定义全局变量，或者在某个模块中保存默认值，短期内成本很低。项目继续推进后，参数会进入更多流程：生产标定需要写入校准值，现场调试需要临时修改阈值，上位机需要读取和展示配置，售后脚本需要批量检查状态，固件升级还要考虑旧版本已经保存的数据是否仍然可用。 到这个阶段，真正需要维护的已经不是单个变量，而是一组产品参数的长期接口。每个参数都可能同时包含外部 ID、类型、默认值、最小值、最大值、单位、说明、读写属性、持久化标记和版本兼容关系。只要这些信息分散在协议代码、shell 命令、业务模块和存储代码中，后续迭代就容易出现规则不一致。 autogen_parameter_manager 适合用于这类固件项目。它把参数表作为事实源，生成固件侧需要的参数定义、ID 映射、静态布局和摘要信息；运行时再基于这些生成数据提供类型化访...
嵌入式新项目与重构中使用 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 中实际出现了什么； 改动前后的契约是否一致； 新增路径是否覆盖失败和回滚场景； 删...
