[toc]
- 输入引脚 (DIR) 选择与旋转方向有关的输出极性。如果 DIR 接地，则输出值随顺时针方向旋转而增加。如果 DIR 连接到 VDD，输出值会随着逆时针旋转而增加。
- 最大角度可编程 18° 至 360°
- 12 位 DAC 输出分辨率
- 模拟输出与 VDD 或 PWM 编码数字输出成比例
- vcc 3.3v
- PGO 编程选项（内部上拉，连接到 GND = 编程选项 B）
- DIR 数字输入方向极性（GND = 值顺时针增加，VDD = 值逆时针增加）
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 wdfk-prog的个人博客！
- 微信
- 支付寶
相关推荐
2026-07-31
杂谈学习笔记系列
杂谈学习笔记系列 1. AS5600 12 位可编程非接触式电位器 (个人博客链接) (CSDN链接) 2. autogen_parameter_manager：面向固件产品参数的生成式管理软件包 (个人博客链接) (CSDN链接) 3. C++ virtual 关键字的沉思：为何“万物皆虚”是反模式？ (个人博客链接) (CSDN链接) 4. Chrome书签图标“失踪”了？一招“同步大法”让它们全部回来！ (个人博客链接) (CSDN链接) 5. GCC 的 -O0、-Og 与发布版调试说明 (个人博客链接) (CSDN链接) 6. Multi-Pass Review 还不够：为什么还需要专项 Profile 和 Fresh Diff Scope (个人博客链接) (CSDN链接) 7. NVIDIA驱动更新“翻车”？解决RTX 2060在Bilibili客户端无法加载4K视频的终极指南 (个人博客链接) (CSDN链接) 8. PotPlayer采集结束后崩溃？罪魁祸首竟是你的安装路径！ (个人博客链接) (CSDN链接) 9. Rime输入法跨平台配置与同步教程：以雾凇拼...
2026-07-25
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，仍然会停进系统库； 无法同步目标板系统库到宿主机，不知道该继续调试还是直接绕过。 这类问题说明：动态库符号加载成功，只解决了“某个库能否源码级调试”的问题，并不等于整个进程中的所有执行路径都具备源码、函数边界和行号信息。 本文重点讨论以下场景： 已确认业务程序和目标动态库可调试； 仍...
2026-07-25
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 -->...
2026-06-24
RPC 是什么：原理、边界与工业/嵌入式通信中的适用场景
@[toc] RPC 是什么：原理、边界与工业/嵌入式通信中的适用场景 摘要： RPC（Remote ProcedureCall，远程过程调用）把跨节点通信抽象成“调用远端函数”，解决的是接口抽象、参数序列化、请求/响应匹配、跨语言代码生成和工具化问题。它不解决物理层、链路层、总线仲裁、实时调度和广播多回应聚合问题。因此，RPC更适合点对点、低频、结构化的控制/配置/调试接口；不适合高频实时PDO、广播控制、硬实时闭环和多主多从共享总线仲裁。工业和嵌入式系统中，更稳妥的做法是把通信拆成实时数据面、诊断配置面和工具调试面：实时数据面使用原生CAN/PDO；诊断配置面使用 UDS/ISO-TP、CANopen SDO 或Modbus；工具调试面再考虑 eRPC/gRPC 这类 RPC。 一、RPC 是什么：诞生背景与核心抽象RPC的直译是“远程过程调用”。它试图解决一个长期存在的软件工程问题：当一个程序需要使用另一台机器、另一个进程、另一个CPU 核或另一个 MCU 上的能力时，能否像调用本地函数一样调用远端...
2026-06-23
autogen_parameter_manager：面向固件产品参数的生成式管理软件包
autogen_parameter_manager：面向固件产品参数的生成式管理软件包 仓库地址: https://github.com/wdfk-prog/parameters@[toc] 推荐判断在嵌入式产品中，参数管理通常会从几个配置变量开始。早期代码里直接定义全局变量，或者在某个模块中保存默认值，短期内成本很低。项目继续推进后，参数会进入更多流程：生产标定需要写入校准值，现场调试需要临时修改阈值，上位机需要读取和展示配置，售后脚本需要批量检查状态，固件升级还要考虑旧版本已经保存的数据是否仍然可用。 到这个阶段，真正需要维护的已经不是单个变量，而是一组产品参数的长期接口。每个参数都可能同时包含外部 ID、类型、默认值、最小值、最大值、单位、说明、读写属性、持久化标记和版本兼容关系。只要这些信息分散在协议代码、shell 命令、业务模块和存储代码中，后续迭代就容易出现规则不一致。 autogen_parameter_manager 适合用于这类固件项目。它把参数表作为事实源，生成固件侧需要的参数定义、ID 映射、静态布局和摘要信息；运行时再基于这些生成数据提供类型化访...
2026-06-17
嵌入式新项目与重构中使用 AI 辅助实现的真正风险：不是 AI 越界，而是工程师逐渐把方向盘交出去
[TOC] 嵌入式新项目与重构中使用 AI 辅助实现的真正风险：不是 AI 越界，而是工程师逐渐把方向盘交出去 面向：嵌入式 C/C++、MCU、RTOS、驱动框架、BSP 适配、硬件抽象层、底层库重构。核心观点：在 AI 辅助新项目或大规模重构中，最危险的不是一开始没有写边界，而是多轮执行后工程师疲劳、焦虑或不耐烦，主动放开边界，让 AI 以“更通用、更完整、更兼容”为名接管需求解释和架构扩张。 结论在嵌入式代码的新项目和重构中，AI 带来的主要风险并不是“它会不会生成一段错误代码”。错误代码反而容易被编译器、静态检查、单元测试、硬件验证或工程师经验发现。更隐蔽、更容易造成长期损失的风险是：工程师一开始知道自己要做什么，也写了目标、边界和约束，但在多轮 AI 实现、AI 审核、AI 修改之后，逐渐把这些边界放开了。 这种放开往往不是一次性发生的。它通常以非常合理的形式出现： “这是新项目，可以不兼容旧接口。” “既然以后可能支持更多芯片，那就先兼容一下。” “AI 说这个特殊功能不支持会有问题，那就加上。” “这轮先让 AI 改，改完再审。” “既然另一个...
评论
