CANopen 网络拓扑限制
从 Node-ID 到线长：读懂 CAN/CANopen 网络拓扑限制 @[toc] 结论先行“CANopen 逻辑上限制到 128，物理上一段常见只能挂 64 个节点；1 Mbit/s 可到 25 m，50 kbit/s 可到 1000 m”这段话把两类约束放在了一起：一类是 CANopen 协议层的地址空间，另一类是 CAN 物理层的线缆、终端、收发器负载和传播延迟。两者都影响网络规模，但判断方式完全不同。 CANopen 的 Node-ID 是逻辑地址问题，7 bit 编码提供 0127 的编号空间；普通节点通常使用 1127，0 用于广播或特殊用途。 CAN 的线性拓扑是物理层问题。一个 CAN 总线段应尽量保持主干线连续，两端各 120 Ω 终端，节点通过短支线接入。 线长受位速率限制。速率越高，单个 bit 的时间越短，信号传播、收发器延迟和采样裕量越紧张，所以允许总线越短。 节点数量受收发器和线缆负载限制。协议允许的地址数量不等于一段总线的可靠驱动能力。 中继器可以在低速下扩展网络规模和构造分段/树形结构，但中继器本身也...
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...
RPC 是什么：原理、边界与工业/嵌入式通信中的适用场景
@[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、线程或设备驱动。...
联网搜索会污染大模型判断吗？——面向日常开发场景的工程化分析
@[toc] 联网搜索会污染大模型判断吗？——面向日常开发场景的工程化分析 结论会。 但这里的“污染”不是说模型一联网就会把自己训练坏，也不是说联网搜索一定有害。更准确地说： 联网搜索会把外部信息带入当前上下文；如果没有边界控制，模型可能把外部资料、外部项目、外部假设、外部版本、甚至外部网页中的隐藏指令当成当前任务依据。 在日常开发中，这种问题很常见。你本来只是让模型基于当前项目修一个 Bug、改一个接口、补一段文档、优化一段代码，但联网以后，模型可能开始参考： 别的项目的实现方式； 新版本框架的 API； 与当前技术栈不一致的最佳实践； 过期或不适用的博客； Stack Overflow 上的片段； AI 生成的网页内容； 第三方文档中的隐藏提示词； 当前项目根本没有采用的架构模式。 结果就是：模型回答看起来更“有资料依据”，但可能更偏离当前项目事实。 所以，日常开发中使用联网搜索，关键不是“开还是不开”，而是： 1234什么时候可以联网？联网只解决什么问题？外部资料能不能进入最终代码？当前项目事实和外部资料冲突时听谁的？ 1. 先区分三种“污染”讨论联网搜索污...
