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. 工作队列...
Lely CANopen ：IO 服务 io_ctx
Lely CANopen ：I/O 服务 io_ctx @[toc] 摘要在 Lely CANopen 应用中，lely::io::Context 往往是最先创建、最后销毁的对象之一。它看起来只是一个很薄的 C++ 包装类，但其底层 io_ctx_t 承担了一个关键职责： 维护一组已注册的 Lely I/O 服务，并在进程 fork() 或系统退出时，按确定顺序向这些服务分发维护事件。 ctx.c 本身并不执行 CANopen 协议，也不负责运行事件循环。它更像一个轻量级的“服务生命周期协调器”： 通过双向链表登记 Timer、CAN 网络接口及其他底层 I/O 服务； 通过服务虚表调用各组件自己的 notify_fork 和 shutdown 回调； 在 fork() 前后按不同方向遍历服务； 在 shutdown 时按注册顺序的逆序关闭服务； 通过服务内部的 _shutdown 标志保证每个服务最多关闭一次； 通过 C++ 的 move-only 包装实现单个底层 Context 的唯一所有权； 允许同一进程创建多个彼此独立的 Cont...
Lely CANopen Timer 的实现原理与运行流程
Lely CANopen: Timer 的实现原理与运行流程 @[toc] 一句话结论Lely 的 lely::io::Timer 不是一个独立线程，也不是一个直接执行回调的传统软件定时器。它本质上是一个异步事件适配器： 123456789Linux timerfd 负责计时 ↓io_poll 负责监听 timerfd 的可读事件 ↓内部 wait_task 负责读取到期计数 ↓ev_exec 负责调度完成任务 ↓io_timer_wait 对应的回调最终被执行 创建 Timer、设置到期时间和提交等待操作是三个不同动作： 123创建 Timer：建立 timerfd 并注册到 io_poll设置时间：调用 timerfd_settime()，决定何时到期提交等待：把 io_timer_wait 放入 wait_queue，决定到期后通知谁 从 CANopen 主站视角看，还要再增加两层调度： 123456789BasicMaster / Node ↓ 传入专用 io::TimerBase&io...
VS Code + GDB 远程调试中的系统库边界、跳过策略与反汇编排查
VS Code + GDB 远程调试中的系统库边界、跳过策略与反汇编排查@[toc] 在嵌入式 Linux 远程调试中，经常会出现一种容易误判的情况： 业务程序已经使用 Debug 参数构建； 依赖的第三方动态库已经能够加载符号； info sharedlibrary 中目标库已经显示 Syms Read = Yes； 断点可以命中 main() 或业务入口； 但继续调试时仍然可能遇到： 在某一行按 F11 后，VS Code 直接变成“运行中”； std::string、容器、内存分配等语句无法稳定单步； 点击暂停后只看到一个地址和 ??； step、next、finish 报 Cannot find bounds of current function； 明明已经配置了 skip，仍然会停进系统库； 无法同步目标板系统库到宿主机，不知道该继续调试还是直接绕过。 这类问题说明：动态库符号加载成功，只解决了“某个库能否源码级调试”的问题，并不等于整个进程中的所有执行路径都具备源码、函数边界和行号信息。 本文重点讨论以下场景： 已确认业务程序和目标动态库可调试； 仍...
VS Code Remote GDB 调试动态库源码断点灰色：问题分析与解决方案
VS Code Remote GDB 调试动态库源码断点灰色：问题分析与解决方案 @[toc] 1. 问题概述在嵌入式 Linux 交叉调试中，主程序源码断点能够正常命中，但第三方动态库源码中的断点一直显示为灰色空心状态。GDB 中对应断点显示为： 1<PENDING> 这表示 GDB 已接受断点请求，但尚未将源码行解析为实际运行地址。 动态库源码断点同时依赖以下条件： 动态库包含 DWARF 调试信息； 动态库未被剥离； 构建输出、GDB sysroot 和目标设备中的动态库完全一致； GDB 能找到正确的本地动态库副本； GDB 已读取该动态库的完整调试符号； DWARF 中记录的源码路径能够映射到当前工作区； 调试会话建立时机与共享库加载时机匹配。 2. 调试链路12345678flowchart LR A[源码目录] --> B[构建输出动态库] B --> C[GDB sysroot 动态库] B --> D[目标设备动态库] C --> E[交叉 GDB 读取 DWARF] D -->...
资源受限系统中的分层低功耗与低延迟唤醒架构设计
嵌入式面试真题第 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、关键中断或时间基准失效，而其他核仍能继续喂狗。 看门狗任务本身优先级过高、依赖过少，反而绕过了真正的业务健康状态。 面对这种...
