做温度采集这个活儿，最怕的不是读不到数，而是读到的数自己都不敢信。我之前给一台分光光度计做环境温度补偿板，最初用的是一颗常见的单总线温度传感器，标称精度±0.5℃。数据倒是跑起来了，但光学模块那边要求环境温度误差必须压在±0.15℃以内，这一下就把整个方案卡住了。后来换了TI的TMP117，再接上瑞萨的RA8D2（我手里的是R7KA8D2KFLCAC）做采集、显示和上报的主控，整个精度和响应水平直接换了一档。TMP117这颗16位数字温度传感器负责把温度变成可靠的数字，RA8D2用480MHz的Cortex-M85内核去跑驱动、滤波、协议解析和HMI刷新，组合起来做一套温度数据采集分析终端，冗余多得让人舒服。
这篇文章把从选型到硬件搭建、驱动开发、标定补偿，再到上位机联调的完整链路整理出来，重点讲那些“手册上写得很简单、实际却反复折磨人”的细节。部分工程细节我按最常见的实践方案展开，不是为了凑字数，而是因为这些东西如果等踩坑了再查，代价要高得多。
1. 选型决策：当温度精度要冲到±0.1℃，传感器和主控得这么配
1.1 我为什么放弃DS18B20，选了TMP117
单总线温度传感器在嵌入式项目里几乎是默认选择，驱动简单、成本低、一颗芯片一个引脚就能挂一大串。但精度问题在医疗冷链、实验室仪器、温度补偿这类场景里是无解的死穴。DS18B20的出厂误差在-10℃到+85℃范围内大概在±0.5℃量级，个别批次甚至更大，而且这个误差是器件级的，没法靠软件完全修正。
TMP117是TI出的16位数字温度传感器，最吸引人的指标是-20℃到50℃范围内精度±0.1℃，分辨率0.0078125℃。温度数据通过I2C读取，本身带EEPROM可以保存报警阈值和配置，还有一个ALERT/THERM告警引脚，可以做硬件级别的超温中断。
我自己的判断标准很简单：如果这个系统会把温度数据拿去算公式、做补偿、做趋势判断，那就不能靠±0.5℃的传感器。光学模块折射率随温度变化的系数，经常是每0.1℃就能造成可观测的输出漂移，这时候TMP117的意义不是“测得准一点”，而是让整个系统能真正闭环。
1.2 RA8D2在这套方案里的位置
很多人做温度采集觉得随便一颗MCU就够了，为什么非得上RA8D2这种性能明显过剩的片子？这得分应用场景。普通温度巡检，51或者M0级别确实够。但我做的这套终端要同时干好几件事：实时读取TMP117、做滤波和异常判断、刷新一个带图形的LCD界面、通过以太网或RS485把数据传上去，还要在本地记录历史曲线。这些任务叠在一起，Cortex-M85这颗480MHz的主控就非常有价值。
RA8D2属于瑞萨RA8系列，内部集成FPU和DSP指令集，做浮点温度计算、滑动滤波都很快。更重要的是它的外设非常全：多路I2C/I3C、SCI串口、USB、以太网MAC、CAN FD，还有图形LCD控制器和2D加速器。也就是说，从温度采集到本地显示、远程上报，这一条链路可以用一颗芯片走完，不需要在板子上堆第二颗MCU或者加一颗GUI芯片。整套系统的BOM更简单，电源设计压力也小得多。
TrustZone安全特性在这个项目里也算加分项，温度数据如果涉及审计、追溯，那放到安全区里运行校验逻辑、普通逻辑放在非安全区，这块芯片天然支持，比外部加密芯片方案稳妥。
1.3 这套组合的适用边界
任何选型都有边界。TMP117的低功耗特性很好，待机模式电流可以压到很低，所以它放在电池供电的传感器节点里完全没问题。但RA8D2是高主频全功能MCU，运行功耗不是nA级待机能比的，更适合有稳定电源的工业仪表、实验室设备、药房冷链监控终端这类产品。如果是纯纽扣电池供电、几个月不换电池的小节点，那主控应该换更低功耗的Cortex-M23/M33系列，传感器依然可以保留TMP117。把传感器和主控的边界分开看，这套方案就能很好地复用到不同产品里。
2. 硬件搭建：TMP117最小系统、地址规划与PCB布局的取舍
2.1 TMP117引脚与最小电路
TMP117的引脚不算多，但每个引脚的状态都会影响行为。常规引脚包括电源VDD、地GND、I2C的SDA和SCL、地址配置引脚ADDR0、ADDR1，以及告警输出ALERT/THERM。还有个比较隐蔽的点：这颗芯片的VDD电压范围是1.7V到5.5V，所以3.3V和5V系统都能直接接，逻辑电平也会跟着供电走，和RA8D2的3.3V IO对接非常顺。
最小电路就三个东西：电源去耦电容、I2C上拉电阻、地址引脚配置。
- 去耦电容放0.1μF，必须贴着VDD引脚放，走线尽量短，这是所有模拟精度器件的通用纪律。
- I2C上拉电阻：400kbps总线上用2.2kΩ到4.7kΩ比较稳，100kbps低速模式可以放宽到10kΩ。取值太大会导致上升沿变缓，线一长就容易出通信错帧；太小又会增加功耗、推高芯片工作温度，温度精度讲究的时候就别选1kΩ以下。
- ADDR0和ADDR1：这两个引脚决定I2C地址，可以接GND、VDD、SDA、SCL，组合出多种地址。我实际用得最多的就是双接GND，得到默认地址0x48；如果总线上要挂多个TMP117，再按手册里的表格去组合其他地址。
2.2 多传感器地址规划与总线冲突
温度采集终端往往不会只装一个传感器。比如冷链箱体里要测内部空气温度、箱壁温度、环境温度，三路传感器是常态。三个TMP117挂同一条I2C总线，关键是地址不能重复。利用ADDR0和ADDR1的不同接法就能错开地址，不用去外接地址开关。
我在设计时习惯留一组拨码开关给每路传感器的地址引脚，这样生产阶段不需要改固件，拨一拨就能匹配安装位置。需要注意，I2C地址是7位形式，TMP117的地址范围在高位段，比如0x48起始的那一段，规划地址时要避开总线上其他芯片，比如EEPROM、RTC、IO扩展器的地址。画板之前把总线上所有器件的地址列成表格扫一遍，能省下上电后排查“为什么只有一颗芯片不应答”的大量时间。
2.3 PCB布局的取舍：先保住测量点的热平衡
温度传感器的PCB布局和普通数字器件不一样，核心矛盾不在信号完整性，而在热完整性。TMP117虽然出厂校准过了，但那是在芯片自身温度等于介质温度的前提下成立的。如果芯片旁边躺着一颗大功率LDO或者主控芯片，PCB铜箔会把热量源源不断传过去，测到的温度会比实际环境高好几度。
这里有三条我实测有效的经验：
- TMP117要尽量靠近被测对象，比如贴在导热块或者被测金属面上；如果在板子的角落里测空气温度，周围不要放任何发热器件。
- 传感器区域的铺铜要克制。地铜箔是导热最快的通路，我在温度采样点附近的PCB上会做隔热处理，甚至会在TMP117和主控之间留一条空槽，减少热传导。
- 主控、电源、通信芯片尽量放在板子另一端，如果空间不允许，至少保证TMP117下方不要有大面积铜皮直接连到功率地。
还有一点容易被忽略：机壳内的空气流动。TMP117靠自身封装感知温度，如果它被罩在一个闷热的小空间里，测出来的就是局部微气候而不是环境温度。做温度采集测试时，把板子放进实际的整机外壳里跑数据，会比在开放桌面测到的结果更有参考意义。
2.4 RA8D2侧的外设与供电设计
RA8D2这种级别的MCU，供电架构比小单片机复杂一点，通常需要多路电压，核心电压和IO电压是分开的。实际的参考设计里会看到PMIC或者多路DCDC/LDO方案。我这次用的是比较省心的方式：外部送来5V，板上用一颗多路输出电源芯片生成3.3V和内核电压，模拟和数字供电尽量分开走。温度传感器的电源我会单独加一个RC滤波，也就是在TMP117的VDD前面串个小电阻再并个电容，把I2C通信和数字开关带来的纹波挡在传感器外面。
RA8D2的I2C外设在FSP里叫IIC通道，不同通道在不同引脚上有映射，选引脚时要避开和调试串口、下载口冲突的引脚。因为TMP117通信速率不高，走线长度短，I2C布线不需要什么特殊阻抗控制，但SCL和SDA最好保持相近长度，避免两条线之间形成大的环路面积。
3. 驱动核心：TMP117寄存器操作与RA8D2的FSP初始化流程
3.1 温度数据寄存器：0x0078125的计算逻辑
TMP117的寄存器布局很规整，核心就这几块：
| 寄存器地址 | 作用 |
|---|---|
| 0x00 | 温度数据寄存器，16位，14位有效数据 |
| 0x01 | 配置寄存器：转换模式、转换周期、平均次数、告警极性 |
| 0x02/0x03 | 高温/低温告警阈值 |
| 0x04/0x05 | EEPROM解锁/锁定控制 |
| 0x0F | 设备ID，上电后读到0x0117 |
温度数据寄存器是最常用的，读出来是一个16位有符号数，低2位固定为0，实际的有效分辨率是14位。换算公式非常简单：
temperature_C = (int16_t)raw_value * 0.0078125;那个0.0078125就是1/128，也就是LSB代表7.8125m℃。比如读到0x3C00，换算过来是120℃，这个量程覆盖工业场景绰绰有余。负温度是二进制补码表示，所以记得先把原始读取值强制转换成int16_t再乘系数，否则直接拿无符号数计算会在零下温度时得到一个完全错误的大正数。这是新手最容易踩的坑。为保证读的稳定性，读取时最好连续读两个字节，先读高字节再读低字节；更完整的做法是先写寄存器地址0x00，再发起重复起始条件读取数据，这一套流程在I2C驱动里是标准操作。
3.2 配置寄存器与转换模式的工程选择
配置寄存器决定芯片怎么跑。TMP117支持连续转换、单次转换、待机等模式。转换周期和平均次数也有多档可选。连续转换模式下，芯片会周期性刷新温度寄存器，CPU随时去读都是最新值，简单省事，适合单片机资源紧张的轮询式采集。注意连续转换会一直耗电，TMP117本身功耗很低，但如果系统对功耗有极致要求，就要用单次转换。
单次转换模式的逻辑是：先配置为单次模式，然后对配置寄存器做一次写操作来触发转换，转换完成后芯片自动进入待机。转换完成后读取结果，数据是转换结束时的快照，不会读到“转换到一半”的无效值。这样既省电又避免读到新旧数据混叠的麻烦。
平均次数也是取舍点。平均次数越多，等效噪声越低，但单次结果更新时间越长。对0.1℃精度的目标来说，8次平均通常就能获得很平稳的读数。我实际项目里用的是8次平均、1秒周期连续转换，稳定性和响应速度都比较居中。
3.3 RA8D2侧FSP工程的初始化要点
RA8D2用瑞萨的e2 studio开发，外设初始化靠FSP配置工具自动生成代码。新建工程时选对具体芯片型号R7KA8D2KFLCAC，之后在FSP里添加I2C Master栈，选好通道号和引脚映射，设置通信速率，比如400kbps，然后生成代码。FSP的抽象层API会统一封装成R_IIC_MASTER_Open、R_IIC_MASTER_Write、R_IIC_MASTER_Read这样的接口，不再需要直接操作寄存器。
我建议把TMP117的驱动单独放一个文件，不要让应用层直接调用FSP的I2C接口。驱动内部封装两个函数：tmp117_init()负责复位、检查设备ID、写配置；tmp117_read_temp()负责触发读取并返回浮点温度值。这样后面换传感器、换I2C通道、加锁机制，都不会波及上层业务代码。
上电初始化时先读一次设备ID，判断是不是0x0117。这个步骤不到一毫秒，但能在生产测试时快速暴露接线错误、地址配置错误和芯片焊接不良，非常值得写进出厂自检流程。
3.4 用DMA让采集不阻塞CPU
当系统同时要做界面刷新和网络通信时，每次都让CPU阻塞在I2C读上就有点浪费了。RA8D2的DMA控制器可以在FSP里和I2C通道联动，配置I2C接收使用DMA搬运，接收完成后通过回调函数通知应用层。
实际调度可以这样设计：一个定时器每500ms触发一次，在回调里发起一次读取请求；DMA把TMP117的温度寄存器数据搬进内存缓冲区；传输完成中断里置一个标志位；主循环或者RTOS任务检测到标志位后做计算和显示。整个过程CPU只在开始和结束的瞬间介入，I2C总线上的字节搬运全部由DMA完成。温度采集这里数据量小，DMA的优势不是吞吐量，而是让主控在几十到几百微秒的通信过程中能去干优先级更高的事。
4. 让数据真正可信：自发热控制、两点标定与误差拟合
4.1 TMP117出厂校准不意味着板级精度不用管
TMP117出厂校准确实把传感器本身的误差压到了±0.1℃，但PCB装配之后，焊锡、铜箔、外壳、周边热源都会引入额外的系统误差。这个误差通常是固定的偏移，和真值有一定关系。换句话说，芯片准不代表整机准。
批量生产时更明显。同一批板子，有的测出来偏高0.03℃，有的偏低0.05℃，这属于正常现象。要在产品里做到高精度，上机标定是不能跳过的环节。
4.2 自发热：0.1℃级别误差的头号隐形杀手
任何有源器件工作时都会自发热，TMP117也不例外。它的功耗很低，但正常I2C通信、连续转换时芯片温度还是会比环境温度高一点点。如果环境静止无风，这个偏差可能到0.05℃量级，对±0.1℃目标来说已经不能忽略。
控制自发热的做法：
- 通信环节：I2C总线上拉电阻不要选太小，SCL频率够用就行，不要为了跑分把速率拉到1MHz。
- 转换环节：不需要连续数据时切到单次转换模式，转换完自动待机，芯片平均功耗下降，自发热随之减小。
- 数据环节：连续转换模式下不要频繁去读，读操作本身也会在总线上产生功耗。
- 布局环节：TMP117周围留出空气流通空间，不要在传感器正上方盖导热泡棉。
还有一个工程技巧：在软件里做差分估计。让系统在待机和连续工作两种状态下各测一次温度，差值就是整机的自热贡献，可以在采集算法里做一个缓慢的修正项。这个技巧对长期运行的仪表很实用。
4.3 冰水浴和恒温槽的两点标定实操
标定的目标是把系统误差拟合成一条直线，一般用两点法就够。
第一点用冰水混合物：取纯净水做的冰块，敲碎后放入保温杯，加少量水，让冰水混合物充分搅拌并静置十分钟，这时候温度非常接近0℃。把TMP117探头放进去，注意不能碰杯壁和杯底，等读数稳定后记录偏差。这个偏差主要就是系统偏移。
第二点用恒温槽或者精密水浴，温度设定在25℃或50℃。恒温槽精度高，有条件直接用；没有的话，用一只经过计量校准的高精度水银温度计或者铂电阻温度计作为参考，放在同一介质里对比读数。
两点标定得到测量值T_read和参考值T_ref两组数据，拟合公式：
T_real = T_read + offset + gain * T_readoffset是截距修正，gain是斜率修正。用两点数据解二元一次方程就行了，代码实现很简单。拟合参数生产时写进EEPROM或者固件参数区，每台设备独立校准。
标定之后的效果，我实际测的一组数据：未标定前两台板子读数差0.12℃，标定后放同一个恒温环境，两台读数差缩小到0.02℃以内。这个投入产出比非常高。
4.4 标定后的稳定性验证方法
标定完不能直接交付，得做稳定性验证。我常用的方法是常温环境中连续采集12到24小时，记录温度值，然后算平均值、标准差、峰峰值。TMP117配合RA8D2，在8次平均、1秒周期的设置下，连续采集的波动通常能控制在±0.03℃以内。如果峰峰值超过±0.1℃，那不是传感器问题，是环境在波动或者热源在影响，得回去查电路和结构。
做验证时注意把数据打上时间戳连续存储，不要只看上位机实时曲线。事后用脚本分析标准差，才能看到一个完整的温度漂移过程。
5. 数据从传感器到上位机：RA8D2的采集调度与协议设计
5.1 一个完整温度采集终端的任务架构
RA8D2的资源充裕，我不会把所有事情塞进一个裸机大循环，而是用RTOS来组织任务。FreeRTOS加三个任务就行：
- 采集任务：按设定周期通过驱动读取所有TMP117，做滤波和越限判断，然后发给显示和通信任务。周期可以取500ms或1秒。
- 显示/存储任务：接收最新温度值，刷新LCD界面，同时追加写入历史数据，我用的是SD卡，按天生成CSV文件。
- 通信任务：处理以太网或RS485请求，上报当前温度、历史数据、报警状态。
I2C总线是共享资源，多个任务不能同时发起通信，所以需要在驱动层加互斥锁。FSP的I2C操作本来就是同步阻塞接口，在RTOS里调用时挂上mutex，谁拿到锁谁访问总线，避免两个任务交替读写TMP117导致的数据错乱。
5.2 数据处理：滑动平均与异常值剔除
传感器数据不能直接拿来显示和存储，至少要过一遍滤波。温度量本身是慢变量，滑动平均窗口5到15就很合适。窗口太大会让报警响应变得迟钝，窗口太小滤波效果不明显。
我用的一个简单可靠的滤波器：
#define TEMP_FILTER_WINDOW 8 static float temp_buffer[TEMP_FILTER_WINDOW]; static uint8_t temp_index = 0; float temperature_filter(float new_value) { float sum = 0.0f; temp_buffer[temp_index] = new_value; temp_index = (temp_index + 1) % TEMP_FILTER_WINDOW; for (int i = 0; i < TEMP_FILTER_WINDOW; i++) { sum += temp_buffer[i]; } return sum / TEMP_FILTER_WINDOW; }在此基础上还可以加一个简单的异常值剔除：如果新值和上一个滤波值差超过2℃，先不直接采用，再连续读两次确认，确认依然超差才认为真实跳变。这样能滤掉I2C总线偶发错误造成的毛刺，又不会把快速的真实升温误杀掉。
5.3 上位机协议设计：简单、可靠、可调试
通信协议我推荐用Modbus RTU或者自定义的带CRC帧格式。温度采集终端要对接的第三方系统五花八门，Modbus RTU在工业现场几乎就是通用语言，RA8D2跑Modbus从站非常轻松。寄存器定义可以这样规划：保持寄存器区放当前温度、最高温度、最低温度，输入寄存器区放历史缓冲区，线圈区放报警状态。
如果自己定义协议，帧结构至少要有包头、长度、功能码、数据、CRC16。CRC16的校验值必须是真实计算的，能拦截绝大多数总线字节错乱问题。我踩过焊接虚连的板子，总线数据偶发翻转，没有CRC的帧解析出完全离谱的-40℃。加上CRC后，错误帧直接丢弃，数据可靠性上了一个台阶。
串口调试阶段有个技巧：RA8D2的调试串口和通信串口分开。调试串口打印驱动状态、寄存器读取结果和标定参数，通信串口跑正式协议。这样两者互不干扰，排查问题时能快速定位是采集链路的问题还是协议链路的问题。
5.4 上位机分析：趋势曲线与报警联动
温度数据到了上位机，核心价值就两个：看趋势和出报警。接入端做一个简单的Python脚本，从串口或者以太网把CSV数据拉出来画温度趋势曲线，叠加高低温报警阈值线，就能直接看到整个温度传感器的长期稳定性。RA8D2这边只需要稳定输出协议帧，剩下的分析交给上位机，分工非常清晰。
6. 现场踩坑实录：让温度数据变“废”的几个常见错误
6.1 总线上找不到TMP117：地址引脚浮空
第一次打样回来，I2C扫描一直找不到0x48设备。对照原理图反复看，最后发现ADDR0和ADDR1引脚没有明确接高或接低，直接悬空了。TMP117靠这两个引脚的电位决定地址，浮空状态既不是稳定高电平也不是稳定低电平，芯片上电时采到的值就不可靠。处理办法很简单：这两个引脚必须有明确电位，不用的时候直接接到GND。这也提醒所有用TMP117的朋友，画原理图时别嫌麻烦，地址引脚不允许悬空。
6.2 上电后第一次读温度是0℃
这个现象很有迷惑性，看了半天以为是芯片坏了。其实是上电后立即去读温度寄存器，芯片还没来得及完成第一次转换，温度寄存器里的内容是上电默认值。解决办法是在初始化流程里读设备ID之后，根据选择的转换周期等一下，或者干脆丢弃前面2到3次读取结果。这也是为什么驱动初始化函数里最好不要立即返回当前温度，而是先跑一个预热读取流程。
6.3 I2C偶发错帧导致温度毛刺
系统跑了一段时间，发现日志里偶尔出现一个和前后值完全对不上的温度，比如25℃的环境突然跳出一笔124℃。排查下来不是传感器问题，而是I2C总线上偶发的位错误，用CRC对协议帧做了保护之后，这些错误帧都被丢弃了。驱动层面还可以加一个合理性检查，当温度值超出传感器物理量程时直接报错。这个策略看起来笨，但非常有效。
6.4 EEPROM写配置时把芯片锁死了
TMP117的配置可以写进EEPROM，掉电不丢失，但写EEPROM有严格时序，先解锁、再写、再锁定，过程中不能断电。我有一次在实验板上写EEPROM时没注意解锁寄存器，写完之后再读配置还是旧值，一度以为芯片坏了。后来按手册里的完整时序重新走了一遍，写入就正常了。对于不需要掉电保存配置的应用，直接RAM配置就行，没必要碰EEPROM，省去很多麻烦。
6.5 整机自热导致的固定偏高
整机组装完成后，温度读数比环境温度稳定偏高0.08℃左右。这不是标定能完全解决的，因为标定环境是开放桌面，整机内部通风差，而且主控和电源的发热被外壳捂住了。解决办法是在软件里做动态热补偿：设备刚上电时主控发热小，偏差小；运行一段时间后热平衡建立，偏差变大并趋于稳定。通过采集温度的同时监测主控工作时间，可以拟合出一条补偿曲线，再把系统误差压下来。这个补偿策略在长期运行的仪表设备里效果很明显。
7. 直接能用的参数速查和最后几点建议
7.1 TMP117关键参数速查
| 项目 | 参数值 |
|---|---|
| 测温范围 | -55℃到+150℃ |
| 高精度温度范围 | -20℃到+50℃内±0.1℃ |
| 分辨率 | 0.0078125℃（16位，14位有效） |
| I2C工作模式 | 100kbps/400kbps，高达1MHz |
| 默认I2C地址 | 0x48（由ADDR0/ADDR1组合决定） |
| 上电默认状态 | 连续转换模式，温度寄存器持续刷新 |
| 关键寄存器 | 0x00温度，0x01配置，0x0F设备ID（0x0117） |
| 低功耗模式 | 单次转换/待机模式 |
| 供电范围 | 1.7V到5.5V |
7.2 RA8D2这套板子的核心配置速查
| 项目 | 配置 |
|---|---|
| 内核 | Arm Cortex-M85，480MHz，带FPU/DSP |
| 板载资源 | 2MB Flash、1MB SRAM，外设丰富 |
| I2C通道 | 按FSP配置选择，接TMP117的SCL/SDA |
| 开发环境 | e2 studio + FSP |
| I2C驱动接口 | R_IIC_MASTER_Open/Write/Read |
| 系统组织 | FreeRTOS，采集任务/显示任务/通信任务 |
| 通信协议 | Modbus RTU或自定义CRC帧 |
7.3 给想抄作业的人一个最小落地路径
如果你是第一次做TMP117加RA8D2的温度采集，是不是非要一步到位上RTOS、DMA、上位机全套？不是。我建议按这个顺序来：
- 先买官方的RA8评估板和TMP117评估模块，在FSP工程里跑通读设备ID和读温度。
- 用串口把温度值打印出来，验证换算公式和温度稳定性，这一步先确认传感器和主控通信没有问题。
- 然后把TMP117放到实际测温环境里，做两点标定，把offset和gain存到参数区。
- 最后根据产品需求决定是否加RTOS、DMA、LCD和网络。
最后一点心得是：温度采集系统做得好不好，不是看软件用了多高级的算法，而是看每一步有没有引入新的误差来源。TMP117把传感器误差压到了±0.1℃以内，但如果PCB布局把热源耦合进去、地址引脚悬空导致通信混乱、或者标定时参考源本身就不准，那前面省下来的精度全都会在整机上还回去。先把信号链路里最基础的“干净、稳定、可验证”做到位，0.1℃级别的温度分析系统其实是水到渠成的事。
