wdfk-prog的个人博客

Lely CANopen Future/Promise 机制原理与源码详解 @[toc] 1. 先给结论：Lely Future 到底是什么Lely 的 Future/Promise 不是一个“阻塞等待结果”的线程同步工具，而是一个和 executor、task、event loop 深度结合的一次性异步完成通知与结果共享机制。 可以先记住以下五句话： ev_promise_t 是异步结果的生产端，负责把共享状态从未完成推进到完成； ev_future_t 是观察端，负责检查结果是否完成、读取结果、登记完成后的任务； Future 本身不会执行 I/O，也不会主动运行回调；真正执行回调的是 task 所属的 executor； ev_future_submit() 不阻塞，而是把 task 暂存在 Future 内部队列，Future ready 后再提交给 executor； Promise 和 Future 不是两个独立对象，它们共享同一块内存、同一个引用计数和同一个生命周期。 官方 C 接口头文件直接强调：与 C++11 的 Futur...

Lely CANopen ev_loop 详解 @[toc] 1. 先区分三个容易混淆的“停止”状态loop.c 中至少存在三类停止或完成状态： 状态 所属范围 作用 loop->stopped 每个 ev_loop_t 整个事件循环是否处于 stopped 状态；ev_loop_stop() 会影响所有正在运行该 loop 的线程。 ev_loop_thrd.stopped 每个线程 中断该线程当前最内层的一次 run/wait 调用；返回后通常会清零，以便下次重新运行。 ctx->ready 每个等待 context 表示正在等待的 future 已经 ready，应结束本次等待。 不能把它们当作同一个状态： 12345678loop->stopped= loop 级停止thread-local stopped= 线程级、单次运行中断ctx->ready= 本次等待目标已经完成 ev_loop_ctx_wait_one() 的主循环实际同时检查这些条件： 12345loop 没有全局停止并且当前线程没有被 kill并且fu...

Lely canopenio_poll 机制原理与完整运行流程详解 @[toc] 1. 先给结论Lely 的 io_poll 是一个基于 Linux epoll 的 I/O 事件分发器。它不解析 CANopen，也不主动读取 SocketCAN；它只负责： 把需要关注的文件描述符 fd 登记到 Linux epoll； 阻塞等待这些 fd 出现可读、可写、异常或断开事件； 根据内核返回的 fd，在红黑树中找到对应的 io_poll_watch； 调用 watch->func(watch, events)； 因为所有登记都附加了 EPOLLONESHOT，每次通知后当前一次监听失效； 调用方若要继续接收后续事件，必须再次调用 io_poll_watch() 恢复下一次监听。 最重要的完整周期是： 1234567891011121314151617181920212223创建 Poll ↓初始化 io_poll_watch ↓io_poll_watch(events != 0) ↓首次登记：EPOLL_CTL_ADD ↓ev_poll_wait() ...

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 的实现原理与运行流程 @[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 远程调试中的系统库边界、跳过策略与反汇编排查@[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 调试动态库源码断点灰色：问题分析与解决方案 @[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 上下文、故障寄存器、当前调用栈、关键线程状态、最近事件和固件身份，...