[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-05-20
联网搜索会污染大模型判断吗？——面向日常开发场景的工程化分析
@[toc] 联网搜索会污染大模型判断吗？——面向日常开发场景的工程化分析 结论会。 但这里的“污染”不是说模型一联网就会把自己训练坏，也不是说联网搜索一定有害。更准确地说： 联网搜索会把外部信息带入当前上下文；如果没有边界控制，模型可能把外部资料、外部项目、外部假设、外部版本、甚至外部网页中的隐藏指令当成当前任务依据。 在日常开发中，这种问题很常见。你本来只是让模型基于当前项目修一个 Bug、改一个接口、补一段文档、优化一段代码，但联网以后，模型可能开始参考： 别的项目的实现方式； 新版本框架的 API； 与当前技术栈不一致的最佳实践； 过期或不适用的博客； Stack Overflow 上的片段； AI 生成的网页内容； 第三方文档中的隐藏提示词； 当前项目根本没有采用的架构模式。 结果就是：模型回答看起来更“有资料依据”，但可能更偏离当前项目事实。 所以，日常开发中使用联网搜索，关键不是“开还是不开”，而是： 1234什么时候可以联网？联网只解决什么问题？外部资料能不能进入最终代码？当前项目事实和外部资料冲突时听谁的？ 1. 先区分三种“污染”讨论联网搜索污...
2026-04-25
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...
2026-04-25
为什么需要一个 Multi-Pass Review Skill：让大模型代码审核从“会说”变成“可控”
@[toc] 为什么需要一个 Multi-Pass Review Skill：让大模型代码审核从“会说”变成“可控” 开篇：大模型已经能审代码，但还不能无约束地审代码大模型进入软件工程之后，最容易被低估的能力之一，是代码审核。 它能读 diff，能指出可疑逻辑，能解释风险，能补充测试建议，也能把复杂变更整理成清晰的审查报告。对于开发者来说，这种能力非常有吸引力：过去需要同事花时间帮忙看的改动，现在可以先交给模型过一遍；过去需要反复检查的错误路径、参数契约和边界条件，现在模型能快速给出一组候选问题。 但是，只要真正把大模型放进代码审核流程里，就会遇到一个很现实的问题： 大模型能发现问题，但它的发现过程不稳定。 它有时能指出非常关键的 bug；有时会漏掉明显风险；有时会把不存在的问题讲得很有说服力；有时会在没有证据的情况下假设某个调用方、配置项、运行环境或历史背景存在。 这不是简单的“模型不够聪明”。这是一类结构性问题。 因为代码审核不是问答题，而是工程判断。它要求模型同时处理： diff 中实际出现了什么； 改动前后的契约是否一致； 新增路径是否覆盖失败和回滚场景； 删...
2026-04-07
解决 Linux 使用符号链接的 Git 仓库在 Windows 下无法创建符号链接的问题
@[toc] 解决 Linux 使用符号链接的 Git 仓库在 Windows 下无法创建符号链接的问题本文说明：当一个在 Linux 下正常使用 符号链接（symlink） 的 Git 仓库，被拉到 Windows 上后，出现 无法创建符号链接、symlink 被检出成普通文本文件、编译时报 expected identifier or '(' before '.' token 等问题时，应该如何定位和解决。 适用场景： 仓库中有大量 *.c / *.h / 资源文件通过符号链接复用 在 Linux 或 macOS 上工作正常 到 Windows 上后，git clone、git checkout、git reset --hard、构建或 IDE 索引阶段出现异常 先看典型现象这类问题在 Windows 上通常表现为两组症状。 现象 1：Git 无法恢复符号链接例如执行检出、重置、清理后，Git 报错： 1error: unable to create symlink <link-path>: Permi...
2026-04-05
GCC 的 `-O0`、`-Og` 与发布版调试说明
@[toc] GCC 的 -O0、-Og 与发布版调试说明 结论 -O0：基本关闭大多数优化，调试时更接近源码书写顺序。 -Og：不是完全不优化，而是“为了调试体验而保留一部分优化”。 因为 -Og 仍然会做一部分优化，所以它不能按 -O0 的方式理解；单步、变量位置、控制流都可能和 -O0 不同。 如果发布版本使用 -Os，那么定位发布版问题时，通常更适合使用 -Os -g -gdwarf-2，而不是切回 -Og 或 -O0。 -g 的作用是生成调试信息。 -gdwarf-2 的作用是强制调试信息使用 DWARF2 格式，常用于兼容较旧的 GDB、IDE 或嵌入式调试器。 -O0 和 -Og 的核心区别-O0-O0 是 GCC 的默认优化级别。它会关闭大多数优化阶段，目标是让： 编译结果尽量直接 机器指令和源码的对应关系更直观 单步调试更容易按源码顺序观察 因此，-O0 更适合这些场景： 你要确认某一行到底有没有执行 你要观察最原始的控制流 你要尽量减少“编译器改写代码形态”带来的干扰 但 -O0 也有明显代价： 代码通常更大、更慢 时序行为更容易偏离发布版 ...
2026-03-11
黄金比例乘法哈希与哈希表大小设计原理
[toc] 黄金比例乘法哈希与哈希表大小设计原理 本文说明一种常见的静态哈希表设计：黄金比例乘法哈希（Multiplicative Hashing） + 2 的幂桶表结构。该方案来源于 Knuth 在《The Art of Computer Programming》中提出的哈希理论，在系统软件与嵌入式环境中被广泛采用。 示例代码通过编译期计算哈希表大小，并使用黄金比例相关常数实现均匀分布的哈希函数。 使用黄金比例常数实现乘法哈希哈希常数定义如下： 1#define PAR_ID_HASH_GOLDEN_RATIO_32 (0x61C88647u) 该常数来源于黄金比例相关公式： 1A = (√5 − 1) / 2 乘法哈希公式： 1h(k) = floor(m * frac(k * A)) 其中： 符号 含义 k key A 常数 m 哈希表大小 在 32 位整数实现中，公式通常转化为： 12hash = key * constantindex = hash >> shift 或： 1index = hash & mask...
评论
