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. 工作队列...
不可恢复异常后的通用崩溃快照、调用栈保存与离线分析架构
嵌入式面试真题第 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 模型的兼容层。 所以最准...
Lely `dcf-tools` 与 `master
Lely dcf-tools 与 master.yml 配置教程：从 EDS 生成可用的主站 DCF @[toc] 适用版本：原生 Lely CANopen 2.4.0 dcfgen。本文使用上游 master/options/<slave> 结构，不适用于 ROS 2 或其他 downstream 项目自定义的 defaults/nodes YAML 格式。 本文解决什么问题Lely 主站通常不是直接读取从机 EDS 后运行，而是先在开发机上通过 dcfgen 合并主站策略、从机 EDS 和 PDO/SDO 配置，生成 master.dcf 以及按需生成的 concise DCF 二进制文件。 本文给出一条可复现的配置路径： 在 Ubuntu 开发机安装与目标 Lely 源码匹配的 dcf-tools； 准备从机 EDS 和 master.yml； 逐项理解 options、master 和从机 section； 生成并检查 master.dcf； 使用一份完整的 demo.yml 作为字段字典，其中非必需字段全部保留为注释。 本文示例环境： ...
Lely canopen：用 EDS 和 `master
Lely canopen：用 EDS 和 master.yml 生成 CANopen 主站 DCF 本文以 Lely CANopen 2.4.0、Ubuntu 20.04 和 CANopenNode 从站为例，演示如何在开发机上安装 dcf-tools，编写原生 Lely master.yml，并从 EDS 生成可供主站程序使用的 master.dcf。 本文要解决的问题在嵌入式 CANopen 项目中，经常会同时存在两套运行环境： 目标板运行交叉编译后的 Lely C/C++ 库； 开发机运行 Python 版 dcf-tools，用于检查 EDS/DCF 和生成主站配置。 这两部分相互配合，但不需要安装到同一个系统，也不要求使用同一种架构。目标板可以继续使用 --disable-python --disable-cython 构建 Lely；dcf-tools 只安装在 Ubuntu 开发机上即可。 完成本文后，你将得到： 123456789config/├── project.eds # 原始从站 EDS├──...
