加载中...

杂谈学习笔记系列

发表于2026-07-31|更新于2026-07-31|杂谈

|总字数:1.1k|阅读时长:3分钟|浏览量:|评论数:

杂谈学习笔记系列

文章作者: Liya Huang

文章链接: https://wdfk-prog.space/posts/95103a74/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 wdfk-prog的个人博客！

赞助

微信
支付寶

相关推荐

VS Code + GDB 远程调试中的系统库边界、跳过策略与反汇编排查

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 调试动态库源码断点灰色：问题分析与解决方案

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 -->...

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 改，改完再审。” “既然另一个...

联网搜索会污染大模型判断吗？——面向日常开发场景的工程化分析

@[toc] 联网搜索会污染大模型判断吗？——面向日常开发场景的工程化分析结论会。但这里的“污染”不是说模型一联网就会把自己训练坏，也不是说联网搜索一定有害。更准确地说：联网搜索会把外部信息带入当前上下文；如果没有边界控制，模型可能把外部资料、外部项目、外部假设、外部版本、甚至外部网页中的隐藏指令当成当前任务依据。在日常开发中，这种问题很常见。你本来只是让模型基于当前项目修一个 Bug、改一个接口、补一段文档、优化一段代码，但联网以后，模型可能开始参考：别的项目的实现方式；新版本框架的 API；与当前技术栈不一致的最佳实践；过期或不适用的博客； Stack Overflow 上的片段； AI 生成的网页内容；第三方文档中的隐藏提示词；当前项目根本没有采用的架构模式。结果就是：模型回答看起来更“有资料依据”，但可能更偏离当前项目事实。所以，日常开发中使用联网搜索，关键不是“开还是不开”，而是： 1234什么时候可以联网？联网只解决什么问题？外部资料能不能进入最终代码？当前项目事实和外部资料冲突时听谁的？ 1. 先区分三种“污染”讨论联网搜索污...

评论

数据加载中