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. 工作队列...
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 也有明显代价： 代码通常更大、更慢 时序行为更容易偏离发布版 ...
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 项目定位很明确：不是平台示例，而是通用驱动骨架从仓库主页给出的描述来看，...
