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. 工作队列...
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 ...
mmci
[toc] MMCI（ARM PrimeCell PL18x 主机控制器驱动）：全面了解与深度解析文件路径 / 技术中文名 / 功能概述 文件路径：drivers/mmc/host/mmci.c 技术中文名：MMCI（ARM PrimeCell PL180/PL181 及衍生控制器的 MMC/SD/SDIO Host 驱动） 功能概述：该文件是 Linux MMC host 层驱动实现，负责把 MMC core 发下来的命令与数据请求，转换成 MMCI/SDMMC 控制器寄存器操作，覆盖命令发送、响应接收、数据通路控制、PIO 与 DMA 传输、中断处理、时钟与电源控制，以及不同硬件变体的差异适配。 介绍drivers/mmc/host/mmci.c 属于 Linux MMC 子系统里的 Host Controller Driver。它不负责块层调度，也不负责文件系统，而是直接驱动一类具体的 MMC/SD/SDIO 控制器 IP。 从主线实现看，这个文件不是“单一芯片专用驱动”，而是一个覆盖面...
