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 交叉构建说明
Lely CANopen 交叉构建说明：为什么执行 make install DESTDIR="${PWD}/stage"，以及 lib/pkgconfig 的作用@[toc] 结论在 Lely CANopen / lely-core 的交叉编译流程中： 12make -j"$(nproc)"make install DESTDIR="${PWD}/stage" 这两条命令不是重复动作。它们分别解决两个问题： make：把源码编译、链接成目标平台可用的库和工具。 make install DESTDIR="${PWD}/stage"：把已构建产物按最终安装目录布局复制到 staging 目录，便于检查、打包、部署和给后续应用交叉编译使用。 本次构建还安装了 lib/pkgconfig/*.pc 文件。它们不是库本体，而是给 pkg-config 查询的构建元数据，用来自动输出依赖 Lely 库时需要的 -I、-L、-l 等编译和链接参数。 先看完整流程123...
Lely CANopen configure 配置项与日志解读
Lely CANopen configure 配置项与日志解读 @[toc] 1. configure 在构建链路中的位置configure 属于 GNU Build System 的配置阶段。它不会直接把 Lely 源码编译成库，而是读取命令行参数、探测工具链和目标系统能力，然后生成 Makefile、config.h、.pc 文件和 libtool 相关脚本。后续 make 才进入编译阶段。 一个典型的交叉编译配置命令可以写成： 1234567../configure \ --host=aarch64-poky-linux \ --prefix=<INSTALL_PREFIX> \ --disable-python \ --disable-cython \ --disable-tests \ --disable-unit-tests 这条命令包含两类信息：一类是“目标平台和安装位置”，另一类是“功能裁剪策略”。前者影响工具链选择和安装目录，后者影响 Python、测试、CANopen 模块、C++ 接口等是否进入构建目标。 2. config...
从 `autoreconf -i` 看懂 Autoconf：以 Lely CANopen 交叉编译为例
从 autoreconf -i 看懂 Autoconf：以 Lely CANopen 交叉编译为例 本文面向第一次接触 Autotools / Autoconf 的读者。目标不是背命令，而是看懂：autoreconf -i 为什么要执行、从哪个文件开始、会生成什么文件、这些文件又怎样参与 Lely CANopen 的交叉编译。 @[toc] 先给结论autoreconf -i 的作用是：根据源码中的 Autotools 描述文件，生成后续构建需要的 configure 脚本、Makefile.in 模板、config.h.in 模板和一批辅助脚本。 它不是编译命令，也不会生成 ARM/aarch64 目标程序。真正编译 Lely 的动作发生在后面的 make 阶段。 完整链路如下： 12345678910111213141516171819202122flowchart TD A[configure.ac<br/>Autoconf 入口] --> B[autoreconf -i] C[Makefile.am<br/&...
Lely CANopen 入门：从协议背景到 i
Lely CANopen 入门：从协议背景到 i.MX8P 交叉编译安装@[toc] 先给结论Lely CANopen 适合做 嵌入式 Linux 侧 CANopen master，尤其适合已经使用 SocketCAN、C++、事件循环或 Yocto SDK 的项目。它不是只能跑在 PC 上的调试工具，而是一套包含 C 核心库、C++ 应用层封装、命令行工具和 DCF/EDS 辅助工具的 CANopen 实现。 如果你的目标是 i.MX8P 这类 ARM64 Linux 板卡，推荐流程是： 在 x86 Ubuntu 主机安装构建依赖和 i.MX8P Yocto SDK。 加载 Yocto SDK 环境脚本，得到 aarch64-poky-linux-* 工具链和目标 sysroot。 从源码构建 Lely CANopen，并通过 --host=aarch64-poky-linux 交叉编译。 用 make install DESTDIR=... 收集头文件、库、工具和示例配置。 打包部署到 i.MX8P。 在 i.MX8P 上启动 vcan0，运行 coctl...
嵌入式通信中的适用场景
@[toc] RPC 是什么：原理、边界与工业/嵌入式通信中的适用场景 摘要： RPC（Remote ProcedureCall，远程过程调用）把跨节点通信抽象成“调用远端函数”，解决的是接口抽象、参数序列化、请求/响应匹配、跨语言代码生成和工具化问题。它不解决物理层、链路层、总线仲裁、实时调度和广播多回应聚合问题。因此，RPC更适合点对点、低频、结构化的控制/配置/调试接口；不适合高频实时PDO、广播控制、硬实时闭环和多主多从共享总线仲裁。工业和嵌入式系统中，更稳妥的做法是把通信拆成实时数据面、诊断配置面和工具调试面：实时数据面使用原生CAN/PDO；诊断配置面使用 UDS/ISO-TP、CANopen SDO 或Modbus；工具调试面再考虑 eRPC/gRPC 这类 RPC。 一、RPC 是什么：诞生背景与核心抽象RPC的直译是“远程过程调用”。它试图解决一个长期存在的软件工程问题：当一个程序需要使用另一台机器、另一个进程、另一个CPU 核或另一个 MCU 上的能力时，能否像调用本地函数一样调用远端...
autogen_parameter_manager：面向固件产品参数的生成式管理软件包
autogen_parameter_manager：面向固件产品参数的生成式管理软件包 仓库地址: https://github.com/wdfk-prog/parameters@[toc] 推荐判断在嵌入式产品中，参数管理通常会从几个配置变量开始。早期代码里直接定义全局变量，或者在某个模块中保存默认值，短期内成本很低。项目继续推进后，参数会进入更多流程：生产标定需要写入校准值，现场调试需要临时修改阈值，上位机需要读取和展示配置，售后脚本需要批量检查状态，固件升级还要考虑旧版本已经保存的数据是否仍然可用。 到这个阶段，真正需要维护的已经不是单个变量，而是一组产品参数的长期接口。每个参数都可能同时包含外部 ID、类型、默认值、最小值、最大值、单位、说明、读写属性、持久化标记和版本兼容关系。只要这些信息分散在协议代码、shell 命令、业务模块和存储代码中，后续迭代就容易出现规则不一致。 autogen_parameter_manager 适合用于这类固件项目。它把参数表作为事实源，生成固件侧需要的参数定义、ID 映射、静态布局和摘要信息；运行时再基于这些生成数据提供类型化访...
嵌入式新项目与重构中使用 AI 辅助实现的真正风险：不是 AI 越界，而是工程师逐渐把方向盘交出去
[TOC] 嵌入式新项目与重构中使用 AI 辅助实现的真正风险：不是 AI 越界，而是工程师逐渐把方向盘交出去 面向：嵌入式 C/C++、MCU、RTOS、驱动框架、BSP 适配、硬件抽象层、底层库重构。核心观点：在 AI 辅助新项目或大规模重构中，最危险的不是一开始没有写边界，而是多轮执行后工程师疲劳、焦虑或不耐烦，主动放开边界，让 AI 以“更通用、更完整、更兼容”为名接管需求解释和架构扩张。 结论在嵌入式代码的新项目和重构中，AI 带来的主要风险并不是“它会不会生成一段错误代码”。错误代码反而容易被编译器、静态检查、单元测试、硬件验证或工程师经验发现。更隐蔽、更容易造成长期损失的风险是：工程师一开始知道自己要做什么，也写了目标、边界和约束，但在多轮 AI 实现、AI 审核、AI 修改之后，逐渐把这些边界放开了。 这种放开往往不是一次性发生的。它通常以非常合理的形式出现： “这是新项目，可以不兼容旧接口。” “既然以后可能支持更多芯片，那就先兼容一下。” “AI 说这个特殊功能不支持会有问题，那就加上。” “这轮先让 AI 改，改完再审。” “既然另一个...
面向 MCU 与 RTOS 的 Newlib、Newlib-nano、`--specs=nano
@[toc] 面向 MCU 与 RTOS 的 Newlib、Newlib-nano、--specs=nano.specs 与 _REENT_SMALL 说明 适用对象：使用 GCC/Arm GNU Toolchain、RT-Thread、FreeRTOS、Zephyr 或类似 MCU RTOS 的嵌入式 C/C++ 工程。重点问题：newlib 是什么、为什么 MCU 工程会链接它、newlib-nano 如何减少体积、--specs=nano.specs 和 _REENT_SMALL 的作用与风险，以及如何不选用 newlib 而改为工程自实现或替换部分函数。 1. 结论先行在 MCU/RTOS 工程里，newlib 可以理解为 GCC 裸机/嵌入式工具链常用的 C 标准库实现。它提供 memcpy、memset、strlen、printf、snprintf、malloc、free、errno、time、strtok 等标准 C 或类 POSIX 接口，但它并不知道你的硬件上有什么 UART、文件系统、heap、线程或设备驱动。...
