TPC116S8 八通道 12 位 DAC SPI 驱动设计与避坑-平芜编程栈

简介：这份驱动程序包面向嵌入式开发工程师、STM32学习者及需要调试tpc116s8设备的用户，提供一套可直接参考的完整驱动工程源码，重点解决设备在嵌入式环境下的识别、串口通信与外设控制问题。包内共126个文件，以C源文件、H头文件、汇编启动文件、Keil工程配置及编译中间产物为主，并包含hex、axf、map、sct等烧录与链接文件，压缩包约2.36MB，目录保留了较完整的工程结构，便于按模块查阅。资源已有1266人学习下载，说明在同类驱动调试中具有一定参考价值。读者可从中获取STM32F10x外设库的工程组织方式、UART等通信接口的初始化与调用思路、可编译的Keil项目配置以及排错线索，适合用于二次开发、课程实验和硬件联调时对照借鉴。

1. 从一块上电乱飘的八通道模拟板说起：TPC116S8 驱动程序要补的三个洞

去年做一块 8 通道模拟量输出板，主控通过 SPI 挂一颗 TPC116S8，要求每路 0～5V 可编程。第一版驱动很快写完，“能出数”，但一到产线就暴雷：上电瞬间八个通道各蹦一个随机电压，老化测试时相邻通道互相带漂移，客户现场偶发错帧。拆开看全是细节——内部基准没等稳定就写数据、LDAC 时序当成普通 GPIO 用、12 位码在 16 位数据域里对齐搞反。这份完整可用的 TPC116S8 驱动程序，就是把这些坑一次性封进初始化序列、帧组装和同步更新接口里。它适合做工业采集卡、模拟量输出模块、传感器校准台的嵌入式开发者，尤其是手里已经有原理图、只差一层靠谱驱动的人。

2. 项目定位与技术选型：24 位 SPI 帧、单向总线和三层驱动结构

2.1 先划清芯片的能力边界

TPC116S8 是一颗 8 通道、12 位分辨率的电压输出型 DAC，对外只有一条写方向的 SPI 链路：SCLK、MOSI、CS，没有 MISO，也没有“读回当前输出码”这种后悔药。这意味着驱动里所有状态都得自己维护一份影子寄存器，任何一次怀疑“写没写进去”，只能靠外部测量或者重新写一遍来验证。

引脚层面，驱动真正要管的不止 SPI 三根线，还有三根容易被新人忽略的控制线：

引脚	作用	驱动里的处理方式
CS	帧同步，低电平期间有效	每帧拉低 → 传 3 字节 → 拉高，中间不能被其他 SPI 设备打断
LDAC	把输入寄存器搬到 DAC 寄存器，低电平触发	常用硬件脉冲实现 8 通道同一时刻更新
CLR	异步清零，把输出拉到清零码对应的电平	上电默认状态必须明确，不能悬空
VREF	基准输入或内部基准输出	决定满量程，内部基准要等建立时间

这三根线的价值在于“时刻一致性”。工业场景里经常要求 8 路同时跳变，如果逐通道写一帧就更新一帧，通道之间会差出几十微秒的偏斜，示波器上一看就是阶梯状的过渡态。所以驱动的接口设计必须能把“写数据”和“更新输出”拆成两步，这是整套代码的地基。

还有一点得说清楚：TPC116S8 是 12 位器件，但它的数据域是 16 位。也就是说你送进去的 3 个字节里，高 4 位是命令、次 4 位是通道地址、剩下 16 位是数据，而真正有效的只有其中 12 位。对齐方式各家用得不一样，常见做法是左对齐（12 位码放在高 12 位，低 4 位补零），也有右对齐的。代码里我把它抽成一个宏，手册确认后改一行就能切换，别硬编码在业务里。

2.2 驱动分层与目录结构

整个驱动按“业务不碰寄存器、寄存器不碰硬件”的思路切成三层：API 层给应用调，核心层管帧和状态机，端口层只负责把字节怼进 SPI。这样换主控时只改端口层一个文件，其他原样搬走。

tpc116s8/ ├── inc/ │ ├── tpc116s8.h # 对外 API：初始化、写码、同步更新 │ └── tpc116s8_port.h # 端口层接口定义，移植时只改这里 ├── src/ │ ├── tpc116s8.c # 帧组装、初始化序列、单点写 │ ├── tpc116s8_stream.c # 多通道周期刷新的状态机 │ └── tpc116s8_calib.c # 两点校准，把工程值换算成码值 ├── port/ │ ├── port_stub.c # 空实现，单元测试和 PC 上跑帧格式用 │ └── port_mcu.c # 具体主控的 SPI/GPIO/延时实现 ├── test/ │ ├── test_frame.c # 只验证 24 位帧拼得对不对 │ └── test_ramp.c # 斜坡输出，接万用表或 ADC 看线性 └── doc/ └── timing.md # CS/LDAC 时序图和实测波形截图说明

这个结构里有两个刻意的安排。一是port_stub.c，它把所有硬件动作变成打印或者空操作，于是帧组装、校准换算这些纯逻辑可以在电脑上编译跑单测，不用每次改一行就烧一次板子。二是test_frame.c单独存在，因为八成以上的“输出不对”最后都追到帧拼错，把这件事做成可断言的用例，比盯着示波器猜快得多。

技术选型上没有太多花活：纯 C99，不用动态内存，不依赖任何 RTOS。理由很实际——这类驱动经常被塞进中断、被塞进定时任务、被塞进别人的裸机主循环，一旦有 malloc 或者 block 语义，移植就会变成扯皮。所有缓冲区在tpc_dev_t里静态开好，函数返回错误码而不是抛异常。

2.3 关键数据结构与三个设计取舍

核心结构体只有两个：设备句柄和流式输出上下文。

/* 端口层：六个回调，把硬件动作全部抽象掉 */ typedef struct { void *ctx; /* 用户上下文，通常是 SPI 句柄 */ int (*spi_xfer)(void *ctx, const uint8_t *tx, uint8_t len); void (*cs)(void *ctx, bool level); void (*ldac)(void *ctx, bool level); void (*clr)(void *ctx, bool level); void (*delay_us)(void *ctx, uint32_t us); void (*delay_ms)(void *ctx, uint32_t ms); } tpc_port_t; /* 设备句柄 */ typedef struct { tpc_port_t port; uint16_t shadow[8]; /* 影子寄存器，记录每个通道最后写下去的码 */ uint16_t clear_code; /* 上电/清零后输出对应的码值 */ uint8_t ref_mode; /* 0 外部基准，1 内部基准 */ bool inited; uint32_t err_cnt; /* 传输失败计数，便于现场定位 */ } tpc_dev_t;

三个取舍值得展开。第一，端口层用函数指针而不是编译期宏。函数指针有一次间接调用开销，但换来的是同一个.o可以在不同主控上复用，也能在 PC 上跑仿真；这类 8 通道 DAC 的刷新率通常在 kHz 量级，一次间接调用完全不构成瓶颈。第二，影子寄存器必须留。芯片没有回读，业务层又经常需要“把某通道在当前值基础上微调”，没有影子就只能自己再存一份，等于把状态散落到各处。第三，错误计数用uint32_t累加而不是置一个标志位，现场排查时“错了 3 次”和“错了 3000 次”是完全不同的两个故障。

3. 核心模块拆解：一帧数据从 API 到 SCLK 的完整链路

3.1 帧组装：命令 4 位、地址 4 位、数据 16 位

24 位帧是整套驱动的核心，拼错了后面全白搭。代码里把它拆成命令枚举、地址常量和数据对齐宏三部分，任何一处改动手册对不上，只动一处。

/* tpc116s8.h 节选 */ #define TPC_CH_NUM 8u #define TPC_CODE_MAX 0x0FFFu /* 12 位满量程 */ #define TPC_ADDR_BROADCAST 0x0Fu /* 广播地址，所有通道 */ /* 高 4 位命令域，具体编码以手册为准，改这里即可 */ typedef enum { TPC_CMD_WRITE_INPUT = 0x0, /* 只写输入寄存器，输出不变 */ TPC_CMD_UPDATE_DAC = 0x1, /* 输入寄存器搬到 DAC 寄存器 */ TPC_CMD_WRITE_UPDATE_ALL = 0x2, /* 写输入寄存器并更新全部通道 */ TPC_CMD_WRITE_UPDATE = 0x3, /* 写输入寄存器并更新本通道 */ TPC_CMD_POWER_DOWN = 0x4, /* 掉电模式 */ TPC_CMD_LOAD_CLEAR_CODE = 0x5, /* 设置清零后的输出码 */ TPC_CMD_LOAD_LDAC_REG = 0x6, /* 配置哪些通道受 LDAC 影响 */ TPC_CMD_SOFT_RESET = 0x7, /* 软件复位 */ TPC_CMD_INTERNAL_REF = 0x8, /* 内部基准使能 */ } tpc_cmd_t; /* 12 位码放进 16 位数据域：左对齐，低 4 位补 0 */ #define TPC_CODE_ALIGN(v) ((uint16_t)(((uint16_t)(v) & TPC_CODE_MAX) << 4)) static uint32_t tpc_build_frame(tpc_cmd_t cmd, uint8_t addr, uint16_t code) { uint32_t f = 0; f |= ((uint32_t)(cmd & 0x0Fu) << 20); /* bit23..20 命令 */ f |= ((uint32_t)(addr & 0x0Fu) << 16); /* bit19..16 通道地址 */ f |= (uint32_t)TPC_CODE_ALIGN(code); /* bit15..0 数据 */ return f; }

参数说明直白：cmd决定这一帧是“只写”“写并更新”还是“配置类”，addr是 0～7 的通道号或0x0F广播，code是 0～4095 的原始码值。TPC_CODE_ALIGN里的<< 4就是左对齐的关键，如果手册写的是右对齐，把它改成不移位、或者换成>> 0即可，只改这一行，全工程生效。

提示：code超范围时要夹紧而不是靠掩码静默截断。掩码会让 5000 变成 904，输出看着“有值但不对”，这种玄学问题最难查。

真正发出去的时候按字节拆：

static int tpc_xfer(tpc_dev_t *dev, uint32_t frame) { uint8_t buf[3]; int ret; buf[0] = (uint8_t)(frame >> 16); buf[1] = (uint8_t)(frame >> 8); buf[2] = (uint8_t)(frame & 0xFFu); dev->port.cs(dev->port.ctx, false); /* 片选拉低，帧开始 */ ret = dev->port.spi_xfer(dev->port.ctx, buf, 3); /* 一次事务内发满 3 字节 */ dev->port.cs(dev->port.ctx, true); /* 无论成败都释放总线 */ if (ret != 0) { dev->err_cnt++; return -1; } return 0; }

这里唯一允许出错的地方是spi_xfer的返回值。注意 CS 拉高放在判断之前，无论传输是否失败都要执行，否则总线被占住，后面所有帧全废。3 字节必须落在同一个 CS 有效窗口里，中间插入任何其他 SPI 设备访问都会把帧切断，DAC 收到的是两个残帧，输出表现就是“偶尔跳到一个奇怪的电压”。

3.2 写输入寄存器与同步更新：LDAC 的两种用法

驱动对外暴露三个写接口，分别对应三种时序需求：

int tpc_write_input(tpc_dev_t *dev, uint8_t ch, uint16_t code); /* 只写不更新 */ int tpc_write_update(tpc_dev_t *dev, uint8_t ch, uint16_t code); /* 写并立即更新本通道 */ int tpc_update_all(tpc_dev_t *dev); /* 硬件 LDAC 同步更新 */

tpc_write_input用TPC_CMD_WRITE_INPUT把码送进输入寄存器，DAC 寄存器不动，输出保持原值。tpc_write_update用TPC_CMD_WRITE_UPDATE一步到位，适合单点调试或者对同步无要求的场合。tpc_update_all则是先用前者把 8 个通道的输入寄存器全部填好，再发一个硬件 LDAC 脉冲：

int tpc_update_all(tpc_dev_t *dev) { if (!dev->inited) { return -1; } dev->port.ldac(dev->port.ctx, false); /* 拉低触发 */ dev->port.delay_us(dev->port.ctx, 2); /* 满足最小脉宽，具体值查手册 */ dev->port.ldac(dev->port.ctx, true); /* 释放 */ return 0; }

两种更新方式的差别直接体现在波形上：

方式	命令	8 通道更新时刻偏差	适用场景
逐通道写并更新	`TPC_CMD_WRITE_UPDATE`	每通道一帧，偏差约 1 帧 SPI 时间	单点调试、慢速设定值
全部写完后 LDAC	`TPC_CMD_WRITE_INPUT`+ LDAC 脉冲	硬件同时触发，纳秒级	多通道同步输出、波形发生

做多轴联动或者相位敏感的场合，必须走第二条路。我见过一个项目用第一种方式做三路正弦输出，示波器上看相位差一直在飘，查了两天才发现是更新时刻不同步，不是算法问题。

3.3 初始化序列：顺序错了后面全是玄学

初始化是整个驱动最容易翻车的地方，因为它不可重入、不可回滚，顺序错了只能断电重来。代码里固定成六步：

int tpc116s8_init(tpc_dev_t *dev, const tpc_port_t *port, uint8_t use_internal_ref) { dev->port = *port; dev->err_cnt = 0; dev->clear_code = 0x0000; dev->ref_mode = use_internal_ref; /* 1. 释放异步清零脚，让它进入正常工作态 */ dev->port.clr(dev->port.ctx, true); dev->port.delay_us(dev->port.ctx, 10); /* 2. 软件复位，把内部寄存器拉到确定的初始状态 */ if (tpc_xfer(dev, tpc_build_frame(TPC_CMD_SOFT_RESET, 0, 0)) != 0) { return -1; } dev->port.delay_us(dev->port.ctx, 100); /* 复位后留出恢复时间 */ /* 3. 设置清零码：CLR 触发后输出 0V 还是中间电平，由业务决定 */ tpc_xfer(dev, tpc_build_frame(TPC_CMD_LOAD_CLEAR_CODE, 0, dev->clear_code)); /* 4. 使能内部基准（若硬件用外部基准则跳过） */ if (dev->ref_mode) { tpc_xfer(dev, tpc_build_frame(TPC_CMD_INTERNAL_REF, 0, 0x0001)); dev->port.delay_ms(dev->port.ctx, 5); /* 等基准建立，时间查手册 */ } /* 5. 所有通道写 0，保证上电从已知电平起步 */ for (uint8_t ch = 0; ch < TPC_CH_NUM; ch++) { if (tpc_write_update(dev, ch, 0) != 0) { return -2; } dev->shadow[ch] = 0; } /* 6. 标记就绪，之后所有 API 才允许操作硬件 */ dev->inited = true; return 0; }

第 3 步的清零码容易被跳过，但它决定了 CLR 引脚被拉低时输出是 0V、中间电平还是满量程。工业设备上电通常希望是 0V，那就设 0x000；有些场合希望安全位置在中间，就设 0x800。第 4 步的延时不能省，内部基准从使能到稳定需要时间，这段时间内写进去的码对应的输出电压会偏低，表现出来就是“第一批数据不准，后面又对了”。

3.4 多通道周期刷新：状态机而不是中断里硬怼

需要连续输出波形的场景，不能在定时器中断里直接调 SPI 传输——一次 3 字节的传输在低速 SPI 上可能几百微秒，中断里干这个会把系统时序全打乱。驱动里用的是一个非阻塞状态机，每次poll只推进一帧：

typedef struct { tpc_dev_t *dev; uint16_t next[TPC_CH_NUM]; /* 待输出的新值 */ uint8_t idx; /* 当前推进到第几个通道 */ bool dirty; /* 有未下发的数据 */ } tpc_stream_t; /* 在主循环或低优先级任务里调用，每次最多发一帧 */ void tpc_stream_poll(tpc_stream_t *s) { if (!s->dirty) { return; } uint8_t ch = s->idx; /* 先写输入寄存器，8 个通道全部写完再统一 LDAC */ if (tpc_write_input(s->dev, ch, s->next[ch]) != 0) { s->dirty = false; /* 传输异常直接放弃本轮，避免卡死 */ return; } s->idx++; if (s->idx >= TPC_CH_NUM) { s->idx = 0; tpc_update_all(s->dev); /* 一轮结束，硬件同步更新 */ s->dirty = false; } }

这样一轮 8 通道的刷新被摊到 8 次poll调用里，每次只有一次 3 字节 SPI 事务，主循环的响应时间可控。上层只管把新采样点写进next[]并把dirty置真，不用关心总线忙不忙。如果主控支持 DMA，把spi_xfer换成异步版本、在完成回调里推进idx就行，状态机逻辑一行不用改。

4. 编译与落地：六个移植回调把驱动挂进现有工程

4.1 移植层：把硬件动作收敛到六个函数

移植这件事被很多人做成“改一堆 ifdef”，其实只要端口层设计对了，新主控只需要实现六个函数，核心代码一个字不动。

/* port_mcu.c：以一个常见 32 位 MCU 为例，函数体按你的 SDK 替换 */ #include "tpc116s8_port.h" static int mcu_spi_xfer(void *ctx, const uint8_t *tx, uint8_t len) { /* tx 只有发送，没有接收；阻塞式发送，超时返回非 0 */ return bsp_spi_write_bytes((bsp_spi_t *)ctx, tx, len); } static void mcu_cs(void *ctx, bool level) { bsp_gpio_write(PIN_DAC_CS, level ? 1 : 0); } static void mcu_ldac(void *ctx, bool level) { bsp_gpio_write(PIN_DAC_LDAC, level ? 1 : 0); } static void mcu_clr(void *ctx, bool level) { bsp_gpio_write(PIN_DAC_CLR, level ? 1 : 0); } static void mcu_delay_us(void *ctx, uint32_t us) { bsp_delay_us(us); } static void mcu_delay_ms(void *ctx, uint32_t ms) { bsp_delay_ms(ms); } const tpc_port_t g_tpc_port = { .ctx = &g_spi1, .spi_xfer = mcu_spi_xfer, .cs = mcu_cs, .ldac = mcu_ldac, .clr = mcu_clr, .delay_us = mcu_delay_us, .delay_ms = mcu_delay_ms, };

六个回调里，spi_xfer和三个 GPIO 是必须的，两个延时函数看着可有可无，其实是踩坑重灾区。很多 SDK 的delay_us在中断关闭或者高优先级任务里精度极差，而初始化序列里的基准建立时间、LDAC 脉宽都依赖它。如果实测发现初始化偶发失败，先怀疑延时函数，换成靠硬件定时器计数的版本。

SPI 参数上，模式一般是模式 1 或模式 2（空闲电平与采样沿），具体看手册时序图；速率不要一上来就拉满，先用 1MHz 跑通再往上提。CS 建议软件控制而不是硬件 NSS，因为硬件 NSS 在多从机或者 DMA 场景下时序不好控，容易出现“帧中间 CS 被抬高”的错帧。

4.2 编译、上电自检与三条验证手法

工程可以挂 CMake，也可以直接把这几个.c丢进现有工程编译，没有外部依赖。

# 在 PC 上先跑帧格式单测，端口用 stub，不接触硬件 gcc -std=c99 -Iinc src/tpc116s8.c port/port_stub.c test/test_frame.c -o test_frame ./test_frame # 交叉编译进目标工程（示例） arm-none-eabi-gcc -std=c99 -mcpu=cortex-m4 -Iinc -c src/tpc116s8.c -o tpc116s8.o

帧格式单测断言很简单：tpc_build_frame(TPC_CMD_WRITE_UPDATE, 3, 0x800)应该得到0x338000——高 4 位命令 3、次 4 位地址 3、数据 0x800 左移 4 位成 0x8000。这条断言过不了，后面全不用看。

硬件层面，因为芯片没有回读通道，验证只能靠外部手段。我一般按这三步走：

第一步，万用表单点验证。写 0x000 量 0V，写 0xFFF 量接近满量程，写 0x800 量大约一半。三个点对得上，说明帧格式、对齐、基准三件事基本正确。如果写 0xFFF 量到 0V 或者量到某个与预期无关的固定值，八成是数据对齐反了或者命令码用错了。

第二步，线性扫描拟合。从 0 到 4095 每隔 64 个码写一次，用外部 ADC 或高精度表记录，做一次最小二乘拟合，看斜率和截距。斜率偏离理论值说明基准或增益有问题，截距不为零说明零点偏移，这两个数正好可以喂给校准模块。

第三步，示波器看阶跃。让某个通道在 0x200 和 0xE00 之间来回跳，看上升沿有没有过冲、台阶中间有没有毛刺。毛刺通常来自 LDAC 与 SPI 的时序重叠，或者 CS 释放太早。

注意：把自检做成上电必跑的一段代码，失败时把err_cnt和失败步骤号存到非易失区。现场返修时这两个数字能省掉半天排查。

5. 避坑与排查：五条现场翻车记录，从上电毛刺到错帧

5.1 上电与基准相关的三个坑

坑一：上电瞬间八个通道各蹦一个随机电压。现象是设备一上电，输出端先出现几十到几百毫秒的不确定电平，然后才稳定到设定值，继电器或者执行机构会误动作。原因是 CLR 引脚在 MCU 初始化完成前处于悬空或者弱下拉状态，DAC 把它当成随机电平；同时 DAC 内部寄存器上电复位值不一定是零码，输出处于未知状态。解决办法是 CLR 硬件上拉到 VDD 保证常态不触发，同时初始化序列第一件事就是软复位加全通道写零，把确定状态尽早建立起来。如果业务要求上电必须 0V，输出端再加一级 RC 和钳位。

坑二：内部基准刚使能就写数据，输出偏低。现象是初始化后第一批写入的码对应的电压比理论值低 5%～10%，等几秒后再写就正常了。原因是内部基准从使能到稳定需要建立时间，这段窗口内 DAC 的参考电压还没到标称值，码值对应的输出自然偏低。解决办法是把基准使能放到初始化序列靠前的位置，后面跟一个手册标明的建立延时，再做全通道清零。延时不要用for循环凑，用定时器计数的delay_ms。

坑三：换了板子输出整体偏移，同一份固件表现不一样。现象是同一套代码在不同批次的板子上满量程差几十毫伏，或者零点不为零。原因是部分板子用外部基准、部分用内部基准，而ref_mode参数写死在某处；或者外部基准的精度和温漂本身就有差异。解决办法是把基准模式做成配置项而不是常量，初始化时打印或记录实际使用的模式；量产阶段用两点校准把每块板的斜率和截距存进非易失区，由tpc116s8_calib.c在换算时补偿。

5.2 时序与帧格式相关的两个坑

坑四：只有第一个通道能改，其余通道跟着第一个通道动。现象是调tpc_write_update(dev, 3, x)时通道 3 变了，但通道 1、2 也跟着变成一样的值，或者写哪个通道都是通道 0 在动。原因通常有两个：一是地址域填了广播地址0x0F，所有通道一起收；二是命令用了TPC_CMD_WRITE_UPDATE_ALL，这个命令的语义是“写输入寄存器并更新全部通道”，不是“只更新本通道”。解决办法是把“写哪个通道”和“更新哪些通道”在接口层彻底分开：单通道用TPC_CMD_WRITE_UPDATE，同步场景用TPC_CMD_WRITE_INPUT配合tpc_update_all。代码 review 时专门检查命令码和地址是否成对出现。

坑五：SPI 提到 10MHz 以上开始偶发错帧，输出随机跳到某个中间值。现象是低速一切正常，提高 SPI 时钟后，连续刷新时偶尔有一帧被“吃掉”或者错位，表现为输出突然跳一下又回来。原因一般是 CS 的建立/保持时间不够，或者两次传输之间 CS 没有真正拉高，DAC 把相邻两帧连起来当成一帧解析；用 DMA 时如果 CS 由硬件 NSS 控制，还可能出现 DMA 传输未完成 CS 就动作的情况。解决办法是先降速确认问题消失，再逐级提高找到边界；CS 改成软件控制并在拉高后加一两个微秒的间隔；DMA 模式下用传输完成回调去拉 CS，而不是在启动 DMA 的地方就拉。

6. 二次开发：在驱动之上加一层波形与校准引擎

驱动跑通之后，真正决定这套代码好不好用的是上面那层。我自己在这颗芯片上做过两件事，加起来不到两百行，但复用率极高。

第一件是波形引擎。核心是一个相位累加器加一张正弦表，每个 tick 只算一个点，塞进tpc_stream_t的next[]里：

typedef struct { const uint16_t *table; /* 预生成的正弦码表，长度 256 */ uint16_t len; uint32_t phase; /* 相位累加器，高 8 位做索引 */ uint32_t step; /* 频率控制字 = f_out * 2^32 / f_tick */ uint16_t amp; /* 幅度，单位为码 */ uint16_t offset; /* 直流偏置，单位为码 */ } tpc_wave_t; uint16_t tpc_wave_next(tpc_wave_t *w) { uint16_t idx = (uint16_t)(w->phase >> 24) % w->len; int32_t v = ((int32_t)w->table[idx] * w->amp) >> 12; /* 缩放 */ w->phase += w->step; v += w->offset; if (v < 0) { v = 0; } if (v > TPC_CODE_MAX) { v = TPC_CODE_MAX; } return (uint16_t)v; }

step决定频率，amp和offset决定幅值和偏置，改这三个参数就能在现场调输出，不用重新生成码表。注意幅值缩放那块用>> 12而不是除法，定点运算在中断里更稳。

第二件是两点校准。每块板子在出厂时测两个点：码 0x200 处的实际电压、码 0xE00 处的实际电压，反推出斜率和截距，存进参数区：

参数	含义	典型存储位置
`gain_num / gain_den`	理想码值与实测码值的比例	参数区，按板序列号索引
`offset_code`	零点补偿码值	参数区
`ref_mode`	内部/外部基准	配置区，同一批次可共用
`clear_code`	CLR 触发后的输出码	配置区