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. 先区分三种“污染”讨论联网搜索污...
GitHub 开源项目可以用哪些免费的 AI 代码审核工具？CodeRabbit、Qodo OSS、LlamaPReview 怎么选
@[toc] GitHub 开源项目可以用哪些免费的 AI 代码审核工具？CodeRabbit、Qodo OSS、LlamaPReview 怎么选 AI 代码审核工具正在进入开源项目的日常维护流程。它们不应该替代 maintainer 的最终判断，但可以承担一部分重复性初审工作，例如总结 PR、提示潜在问题、指出缺少测试或文档的地方，并帮助贡献者更快理解修改影响。 如果你的仓库是 GitHub public 开源仓库，可以优先关注这些免费或开源友好的 AI 审核工具： CodeRabbit Qodo OSS / Qodo Merge LlamaPReview PR-Agent，适合愿意自托管或自己配置模型的团队 本文重点比较前三个 GitHub 上更容易直接开通的方案。 先理解“免费”的几种含义GitHub Marketplace 上的“免费”并不完全一样，常见有三类： 类型 含义 使用建议 Open Source Free public 开源仓库免费，私有仓库通常收费 最适合开源项目 Free Tier 有免费额度，超过后限流或收费 可以用...
Multi-Pass Review 还不够：为什么还需要专项 Profile 和 Fresh Diff Scope
@[toc] Multi-Pass Review 还不够：为什么还需要专项 Profile 和 Fresh Diff Scope 开篇：多轮审核解决的是“不稳定”，但还没有完全解决“看不全”在大模型代码审核场景中，Multi-Pass Review 是一个很重要的进步。 它不再把代码审核交给一次临场回答，而是通过多轮独立审查、结构化输出和聚合规则，把大模型的审核行为变得更稳定、更可复查、更接近工程流程。 但是，只做到 Multi-Pass 仍然不够。 因为 Multi-Pass 主要解决的是“单次判断不稳定”的问题，而代码审核中还有另外两个更隐蔽的问题： 领域覆盖不完整：模型虽然看了多轮，但每轮可能都在用相同的通用视角看问题，导致领域特定风险长期漏检。 审查范围不新鲜：复审时如果沿用旧 packet、旧结论或旧问题清单，模型可能只验证历史问题，而没有重新审查当前 diff 的完整状态。 这两个问题如果不解决，Multi-Pass Review 很容易变成“重复三次通用审核”。它比单轮回答稳定，但还不是一个足够强的工程化代码审核 Skill。 因此，在 Multi-Pass...
