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. 工作队列...
资源受限系统中的分层低功耗与低延迟唤醒架构设计
嵌入式面试真题第 17 题：资源受限系统中的分层低功耗与低延迟唤醒架构设计 问题在电池供电、能量采集供电或热设计受限的嵌入式设备中，系统通常同时存在多级 CPU/SoC 低功耗状态、多个可独立关断的电源域，以及时钟、存储、传感器、显示、音频、无线通信和外部协处理器等设备。不同休眠状态的静态功耗、进入时间、退出时间、上下文保留能力、可用唤醒源和恢复复杂度差异很大：浅睡眠退出快但待机功耗较高，深睡眠功耗低但可能关闭 PLL、主 SRAM、总线、外设或整个数字域，唤醒后甚至需要从复位入口重新启动。 业务侧又可能同时提出多种约束：按键、触摸、旋钮、门磁、佩戴检测等人机事件要求快速反馈；采样、控制、告警和协议时隙要求确定性响应；网络、音频、显示和传感器只需在需要时恢复；后台日志、统计、同步和自检可以延后。系统还可能频繁出现短空闲、突发交互、定时任务、通信重传、传感器中断和误触发。如果每次空闲都进入最深休眠，恢复成本、唤醒抖动和设备状态错乱可能抵消节能收益；如果长期停留在浅睡眠，又无法满足续航目标。 你会如何设计一套通用的低功耗与唤醒管理框架，在不绑定某一款 MCU、某一种外设...
嵌入式设备休眠电流异常的通用定位与低功耗治理
嵌入式面试真题第 16 题：嵌入式设备休眠电流异常的通用定位与低功耗治理 问题在可穿戴设备、无线传感器、资产追踪器、智能门锁、便携医疗设备、TWS/骨传导耳机、遥控器、仪表终端、数据采集节点等电池供电系统中，产品通常要求设备在待机、休眠或运输模式下进入微安级甚至更低的功耗状态。 现在某台样机在功能上没有明显异常，但静态电流或长时间平均电流明显高于预算。例如，设计目标是几十微安，实测却达到数百微安甚至 1mA～数毫安。系统可能包含 MCU/SoC、RTOS、多个传感器、Codec、Flash、无线芯片、充电与电量计、LDO/DC-DC、负载开关、调试接口以及多个独立电源域。 你会如何建立一套通用、可复用的休眠电流异常定位方法？要求同时覆盖： 如何确认测量结果可信，并区分稳定漏电、周期唤醒和量程伪差； 如何通过最小固件、功耗状态机和二分法划分硬件问题与软件问题； 如何系统检查 GPIO 反向供电、上下拉冲突、外部漏流电阻、模拟输入、调试接口和未断电外设； 如何检查 MCU/SoC 的时钟树、电源域、RAM 保持、唤醒源、RTOS Tick...
不可恢复异常后的通用崩溃快照、调用栈保存与离线分析架构
嵌入式面试真题第 15 题：不可恢复异常后的通用崩溃快照、调用栈保存与离线分析架构 问题在量产嵌入式设备中，系统可能在任意业务状态、任意线程、任意中断嵌套层级和任意外设工作阶段发生不可恢复异常，例如 Arm Cortex-M 的 HardFault、MemManage、BusFault、UsageFault、SecureFault，RISC-V 的同步异常或 NMI，Xtensa 的 panic，RTOS assert，栈溢出，内存破坏，非法指令，访问越界，双重释放，DMA 越界，Flash/cache 异常，锁死后的看门狗复位，以及电压跌落前的紧急复位。 发生异常时，调度器、线程栈、堆、文件系统、日志系统、Flash 驱动甚至时钟和缓存状态都可能已经不可信。设备又可能位于用户现场，无法连接调试器，研发只能在返修、远程上报或下次启动后分析有限数据。 你会如何设计一套通用的嵌入式 Crash Snapshot/Core Dump 机制，在异常入口的极短时间内，安全、确定且可验证地保存 CPU 上下文、故障寄存器、当前调用栈、关键线程状态、最近事件和固件身份，...
防范业务逻辑死锁的系统健康监督与看门狗设计
嵌入式面试真题第 14 题：防范业务逻辑死锁的系统健康监督与看门狗设计 问题在多任务嵌入式系统、RTOS 固件、边缘网关、工业控制器、车载控制单元、消费电子设备或其他长期无人值守的软件系统中，通常会配置硬件看门狗，以便系统发生严重异常时自动复位。 传统实现往往由一个独立 Watchdog Task、Idle Hook、主循环或高优先级定时任务周期性喂狗。只要这个喂狗节点还能获得 CPU 时间，硬件看门狗就不会超时。然而，系统可能已经出现以下“进程还活着、业务却不再工作”的假活状态： 两个或多个任务形成循环等待，业务路径死锁。 高优先级任务持续运行，低优先级关键任务长期饥饿。 任务不断重试或相互唤醒，但业务状态不再前进，形成活锁。 消息队列、缓冲区或对象池耗尽，生产者和消费者互相等待。 状态机卡在某个中间状态，周期函数仍在调用，但事务永远无法完成。 外设、总线、文件系统、网络栈或协处理器请求悬挂，任务仍在等待或轮询。 某个 CPU 核、调度 tick、关键中断或时间基准失效，而其他核仍能继续喂狗。 看门狗任务本身优先级过高、依赖过少，反而绕过了真正的业务健康状态。 面对这种...
单硬件 Timer 下的高精度多路软件定时器架构设计
嵌入式面试真题第 13 题：单硬件 Timer 下的高精度多路软件定时器架构设计 问题在资源受限的实时系统、嵌入式设备、工业控制器、音视频终端、通信协议栈或边缘计算节点中，硬件可能只允许软件独占一个可编程高精度 Timer，或者虽然芯片内部存在多个 Timer，但其他通道已经被 PWM、输入捕获、编码器、操作系统 Tick、协议时基等功能占用。 与此同时，系统内部往往存在数量不定、周期跨度很大、实时等级不同的软件时间事件，例如：协议超时、传感器采样、控制环触发、音频帧节拍、设备状态机延时、重传定时、去抖、看门狗喂狗窗口、异步操作截止时间、短脉冲控制、统计采样和低功耗唤醒等。部分事件要求微秒级时间基准，部分事件只要求毫秒级；部分事件只需记录“已到期”，部分事件需要尽快执行；还有少数事件可能具有硬实时属性。 如果每个模块各自占用硬件 Timer，硬件资源很快就会耗尽；如果全部依赖 RTOS Tick，分辨率、抖动和长周期漂移又可能无法满足要求；如果直接在 Timer ISR 中遍历全部定时器并执行回调，则一次集中到期、复杂回调或异常路径就可能拉长中断时间，阻塞更高优先级的数据采集...
资源受限长期运行系统的确定性内存管理与内存池架构设计
嵌入式面试真题第 12 题：资源受限长期运行系统的确定性内存管理与内存池架构设计 问题在资源受限或对实时性、可靠性有严格要求的系统中，运行期通常同时存在多种内存需求：任务和协议对象的创建销毁、通信报文收发、音视频或传感器数据流、日志与诊断记录、文件系统缓存、DMA 缓冲、临时算法工作区，以及不同模块之间的零拷贝传递。 如果所有需求都直接依赖通用 malloc/free，系统可能在短期测试中表现正常，但在长时间运行、突发流量、异常重连、并发超时、模块反复启停或错误恢复后，出现外部碎片、内存泄漏、分配延迟抖动、优先级反转、关键路径资源被非关键模块耗尽等问题。即使“剩余总内存”看起来仍然充足，也可能因为缺少满足尺寸和对齐要求的连续块而分配失败。 请设计一套适用于裸机、RTOS、嵌入式 Linux 用户态组件以及其他受限运行环境的通用内存管理架构。要求说明： 如何从系统需求和对象生命周期出发选择静态分配、固定块池、分级尺寸池、专用对象池、环形缓冲、Arena/Region、Buddy、TLSF 或普通堆。 如何从架构上避免外部碎片，而不是只在崩溃后扩大堆空间。 如何处理并...
用 POSIX Signal 唤醒 epoll 事件循环：原理、逐行解析与实践
用 POSIX Signal 唤醒 epoll 事件循环：原理、逐行解析与实践 本文面向已经掌握 C 语言、线程和文件描述符基础，但对 POSIX Signal 与事件轮询协作机制还不熟悉的开发者。 核心结论：这里的 signal 不是业务数据，也不是 I/O 事件本身，而是一个“唤醒通知”。它用于中断阻塞中的 epoll_pwait()，让轮询线程及时重新检查停止标志、任务队列或监听集合。 @[toc] 1. 先建立整体认识一个事件轮询线程通常会长时间阻塞： 1n = epoll_wait(epfd, events, maxevents, -1); 最后一个参数为 -1 时，线程会一直等待，直到某个文件描述符就绪。问题是，另一个线程可能需要它立即醒来，例如： 请求事件循环停止； 投递了新的异步任务； 修改了共享状态； 要求重新计算下一次超时时间； 调整了监听集合，但当前没有就绪事件。 因此，事件循环需要一条独立于普通 I/O 的“敲门通道”。这段实现选择 POSIX Signal 作为敲门机制。 123456789控制线程 ...
linux glibc 中 errno 的原理、线程隔离与实现路径
Linux/glibc 中 errno 的原理、线程隔离与实现路径@[toc] 本文面向已经接触 C、Linux 系统调用、pthread 或 RTOS，但对错误码如何产生、传递和隔离仍有疑问的开发者。文章从用户态接口、Linux 内核、C 运行库和 RTOS 四个层次，逐步说明 errno 的宏展开、线程局部存储、系统调用错误转换，以及不同操作系统的错误返回模型。 结论先行1errsv = errno; 这行代码不会在执行时向 Linux 内核查询最新错误码。 在 glibc 环境中，errno 通常是一个宏： 1#define errno (*__errno_location()) 因此，代码近似展开为： 1errsv = *__errno_location(); __errno_location() 返回当前线程专属的 errno 存储地址，解引用后得到该线程当前保存的错误码。 这个错误码通常已经由下列某一方写入： glibc 的系统调用包装层； 某个纯用户态库函数； 应用程序自身； 某个将其他错误模型转换为 errno 模型的兼容层。 所以最准...
