企业官网建设流程全解析

做嵌入式或者HVAC控制器的朋友应该都有同感：测温这件事看起来简单，做好一点都不简单。我上一个项目里刚好要把板卡自身热管理和风管温度采集合并到同一套硬件上，最开始用NTC热敏电阻做方案，结果在校准和防干扰上耗费了大量的时间。后来换成PJ85718DM与STM32F042C6这套组合，本地温度和远程温度用一个传感器同时搞定，I2C直接读数字量，整条链路一下子清爽多了。

PJ85718DM是一颗I2C接口的集成数字温度传感器，它最实用的地方在于同时支持本地测温（感知芯片自身周边环境温度）和远程测温（通过外部探头监测远端温度点），非常适合嵌入式主板热监测和HVAC系统送风/回风温度采集这类场景。搭配STM32F042C6这颗小封装的Cortex-M0内核MCU，成本、功耗、外设资源都刚好够用。这篇文章把我从选型到固件的一整套流程写下来，包括我踩过的坑和调试时的排查思路，给正准备做类似温度监测项目的朋友一个可复用的参考。

1. 方案背景：为什么一块芯片要干两件事

1.1 嵌入式与HVAC的温度监测需求对比

先聊透需求，不然方案做出来容易四不像。

嵌入式设备里，温度监测通常分两块：一块是板卡自身的热管理，比如处理器旁边、电源模块附近需要看温度，用来做风扇调速或者降频保护；另一块是环境侧，比如机箱进风口温度、服务器机房冷通道温度，距离主控板有一定距离。传统做法是主板上贴一个测温点，远端再拉一个测温点，两颗器件占用面积，通信接口还不统一，软件里得维护两套处理逻辑。

HVAC场景就更典型了。控制箱里的控制器需要采集风管送风温度、回风温度、有时候还要采集室外温度，通过温度差值来调节风机转速和水阀开度。这些温度点通常离控制器有一段线缆距离，而且控制箱里往往强电、弱电共存，干扰环境比纯嵌入式设备恶劣得多。

这两个场景的共同点是：需要多个温度点、温度点之间物理上有距离、数据最终都要数字化上报到上层。PJ85718DM一个芯片提供本地和远程两个通道，本地通道管板卡自身温度或控制箱内温度，远程通道通过探头引到远端测量点，正好一个芯片当两个用。

1.2 为什么不用NTC热敏电阻和单点数字传感器

如果你只在实验室里调试过几块板子，可能体会不到NTC方案在大批量产品里的痛。我项目里最初用的就是NTC，问题一大堆。

NTC的阻值和温度是非线性关系，虽然有B值公式可以计算，但实际工程里为了精度还是得做查表或者多项式拟合。更麻烦的是，NTC的B值在批次之间存在离散性，同一型号不同批次的器件，换算出来的温度可能差好几度，批量生产时几乎无法避免逐板校准。而且NTC是模拟信号，远端测量时线缆电阻会直接串联进分压电路，长线压降带来的误差很难修正，线缆一旦受到电机、变频器干扰，采样值就跟着抖。

单点数字温度传感器虽然省掉了查表和校准，但一个传感器只能测一个位置。要测本地和远程两个点就得装两颗，I2C地址资源占两个，PCB面积翻倍，成本也翻倍。更重要的是，两颗芯片在物理上是两个独立的测温点，软件里没法保证两个数据在同一时间戳上采样，对需要计算温差的应用来说是个隐患。

PJ85718DM的优势就在这：出厂校准好的数字输出、一颗芯片双通道、同一时刻可连续读取本地和远程温度，软件处理简单，生产工序也省了一大截。另外它还带可配置的报警阈值输出，后面我会专门讲。

1.3 STM32F042C6的选型逻辑

很多人一看到温度采集就下意识选STM32F103或者F407，其实这个项目完全不需要那么高的性能。PJ85718DM的I2C速率最高也就400kHz，每秒读十次都用不到1%的CPU占用，用一颗Cortex-M0内核的芯片绰绰有余。

STM32F042C6是LQFP48封装，Cortex-M0内核，主频48MHz，片上带一组硬件I2C、一组USART和USB控制器。最关键的是它供电3.3V，和PJ85718DM同一个电源轨，不需要做电平转换。内部HSI振荡器在大多数温度采集场景下精度足够，可以省掉外部晶振，成本又省一笔。

有人会问，软件模拟I2C不行吗？能行，但我不推荐。软件模拟I2C在单字节读写时问题不大，一旦涉及到连续读取、异常总线恢复、以及以后可能要加低功耗模式，软件的时序控制就会变得非常别扭。STM32F042C6的硬件I2C外设配置好之后，读写操作交给外设完成，CPU可以去做别的事，这才是工程做法。

2. 硬件设计：一个I2C拓扑接好本地与远程

2.1 最小系统与I2C总线连接

先把最小系统搭起来。STM32F042C6可以直接用内部HSI时钟，上电后系统时钟走8MHz，想要跑到48MHz需要配置PLL。外部晶振可以不加，温度采集对时钟精度要求不高，HSI的误差在正常工作温度范围内对通信和测温几乎没有影响。

PJ85718DM的VDD接3.3V，VDD对地放0.1uF陶瓷电容，有条件的话再并联一个10uF电解电容，吸收低频纹波。SDA和SCL各接一个上拉电阻到3.3V。I2C总线是开漏结构，这两个上拉电阻是必需的，不是选配。

我用的上拉电阻是4.7k，实测400kHz速率下波形干净。如果你的SDA/SCL走线很长，或者总线上挂了多个设备，可以把上拉降到2.2k；如果总线非常短，只有这一颗传感器，10k也能稳定工作。注意不要用1k以下的强上拉，边沿会变得太陡，长走线时反而容易产生振铃和过冲。

PJ85718DM有两个地址引脚A0和A1，通过高低电平组合可以配置出4个不同的I2C地址。在一条总线上最多可以挂4颗同型号芯片，每颗同时测本地和远程，也就是8个温度点，覆盖一个典型的HVAC控制箱绰绰有余。地址配置如下：

2.2 远程温度探头的接法与抗干扰设计

远程通道是PJ85718DM最值的部分，但也是最容易出问题的部分。它的远程测温原理是通过外接温敏器件随温度变化引起的电气特性变化来反推温度，HVAC风管场景一般用探头形式的外部感温元件，探头封装在不锈钢套管或者塑料护套里，通过屏蔽线引回控制器。

嵌入式场景则灵活得多。比如我想测一块扩展板卡上的功率管温度，就把远端探头通过软排线引到功率管散热片旁边，用导热胶固定。本地通道照常监测主控板环境温度，一个芯片两处监测点，结构很清晰。

远程探头布线有几个原则，都是实际调试中总结出来的：

• 引线尽量短。非要用长线时，用双绞线或者屏蔽线，屏蔽层在控制器侧单端接地，千万不要两端都接地，否则会形成地环路，低频干扰反而更大。
• 走线远离继电器、变频器驱动线、开关电源电感这些强干扰源，实在绕不开就垂直交叉，避免平行近距离走线。
• 探头固定要牢靠。HVAC风管里风速大，探头如果只是松垮地塞在风管里，读数会随风速波动。
• 如果探头引线特别长，可以在控制器端采样引脚对地并联一个0.1uF电容，吸收高频耦合噪声。

我实际遇到过一次很典型的干扰问题：控制箱里有一个大功率继电器，每次吸合瞬间远程温度读数就跳一下，一度让我怀疑是探头坏了。后来用示波器抓远程通道的引脚波形，发现继电器动作时有一串毛刺叠加在信号上。处理方式就是把探头线换成了屏蔽双绞线，并且在采样端加了RC滤波，问题立刻消失。

2.3 供电、去耦和电平匹配

传感器电源建议串联一个10Ω左右的小电阻再进VDD，和VDD对地的电容组成简单的低通滤波，把电源里的高频纹波滤掉一部分。如果你把传感器直接挂在开关电源纹波比较大的电源轨上，会发现远程通道和本地通道的读数都偏大或者抖动，这是因为纹波通过芯片内部参考电压直接影响ADC转换结果。

STM32F042C6的VDDA引脚同样需要滤波。官方手册要求VDDA和VDD之间接磁珠和电容，实际项目里如果PCB空间紧张，用10Ω电阻加0.1uF电容也能工作，但ADC精度和内部参考稳定性会略受影响，温度采集对精度要求很高的话还是建议按官方推荐来。

因为PJ85718DM和STM32F042C6都是3.3V供电，I2C电平天然匹配，不需要电平转换芯片。这是一个很大的省心点。如果哪个模块是5V供电，就必须在I2C线上做电平转换，而不是简单的电阻分压，否则会把3.3V器件引脚打坏。

3. 固件实现：从I2C初始化到温度出炉

3.1 硬件I2C初始化要点

STM32F042C6的硬件I2C外设初始化并不复杂，HAL库提供了现成的结构体配置。一个容易出错的点是Timing参数，这个参数直接决定I2C时钟频率，很多初学者在这里栽过跟头。

I2C_HandleTypeDef hi2c1; void MX_I2C1_Init(void) { hi2c1.Instance = I2C1; hi2c1.Init.Timing = 0x2000090E; hi2c1.Init.AddressingMode = I2C_ADDRESSINGMODE_7BIT; hi2c1.Init.DualAddressMode = I2C_DUALADDRESS_DISABLE; hi2c1.Init.OwnAddress1 = 0; hi2c1.Init.OwnAddress2 = 0; hi2c1.Init.GeneralCallMode = I2C_GENERALCALL_DISABLE; hi2c1.Init.NoStretchMode = I2C_NOSTRETCH_DISABLE; if (HAL_I2C_Init(&hi2c1) != HAL_OK) { Error_Handler(); } }

Timing参数怎么看？这个值其实由四组字段拼成：PRESC决定I2C时钟预分频，SCLDEL和SDADEL控制数据建立时间和保持时间，SCLH和SCLL控制时钟高电平和低电平时间。I2C时钟源为48MHz时，参考配置是PRESC=4、SCLDEL=4、SDADEL=2、SCLH=6、SCLL=8，算出来的SCL频率接近400kHz。实际开发中直接用STM32CubeMX的I2C Timing计算工具生成即可，但理解参数含义对后续排查总线问题很有帮助。

3.2 温度寄存器读取与数据解析

PJ85718DM的温度数据以12位二进制补码形式存放在两个寄存器里，高字节在前，低字节在后。12位数据分布在寄存器的高12位，低4位是保留位或者状态位。读出来之后要把两个字节组合成一个16位数，再右移4位，符号扩展之后乘以分辨率0.0625°C，就得到实际温度值。

#define PJ85718DM_ADDR 0x48 #define REG_TEMP_MSB 0x00 #define REG_TEMP_LSB 0x01 #define REG_REMOTE_MSB 0x02 #define REG_REMOTE_LSB 0x03 float read_temp(uint8_t msb_reg) { uint8_t reg = msb_reg; uint8_t buf[2] = {0, 0}; int16_t raw; HAL_I2C_Master_Transmit(&hi2c1, PJ85718DM_ADDR << 1, &reg, 1, 100); HAL_I2C_Master_Receive(&hi2c1, PJ85718DM_ADDR << 1, buf, 2, 100); raw = (int16_t)((buf[0] << 8) | buf[1]) >> 4; return raw * 0.0625f; }

为什么组合后要右移4位而不是直接换算？因为两个字节一共16位，但有效温度数据只在高12位。右移4位之后，既完成了位对齐，又借助有符号右移实现了符号扩展。比如读回MSB=0x1A，LSB=0x50，组合成0x1A50，右移4位得到0x1A5，十进制421，乘以0.0625就是26.3125°C。如果是负温度，读回MSB=0xF2，LSB=0x00，右移4位得到0xF20，这在16位有符号语境下是-224，乘以0.0625就是-14°C。

12位分辨率听起来很高，但要注意分辨率和精度是两个概念。分辨率表示数字量能变化的最小台阶，也就是0.0625°C；精度则取决于芯片内部的校准和ADC本身的线性度。PJ85718DM这类集成温度传感器的典型精度在正负0.5到1°C之间，对HVAC控制来说足够了，但如果你指望它测出来能当计量标准用，那是想多了。

3.3 本地和远程读数的一致性处理

本地温度和远程温度分别在连续的寄存器地址里，读的时候最好一次性连续读出4个字节，然后在本地换算。如果分开单字节读取，中间万一碰巧遇到ADC转换边界，可能会读出本地温度是上一时刻、远程温度是下一时刻的拼接数据，计算温差时会出现一个奇怪的毛刺。

连续读取的方式也很简单，HAL库的I2C_Master_Receive接口可以一次读多个字节：

uint8_t buf[4]; uint8_t reg = 0x00; HAL_I2C_Master_Transmit(&hi2c1, PJ85718DM_ADDR << 1, &reg, 1, 100); HAL_I2C_Master_Receive(&hi2c1, PJ85718DM_ADDR << 1, buf, 4, 100); int16_t local_raw = (int16_t)((buf[0] << 8) | buf[1]) >> 4; int16_t remote_raw = (int16_t)((buf[2] << 8) | buf[3]) >> 4; float t_local = local_raw * 0.0625f; float t_remote = remote_raw * 0.0625f;

读取频率方面，HVAC场景1秒采集一次足够，温度变化本身是慢变量，没必要把I2C总线跑得很满。嵌入式风扇调速可以适当加快到100~200毫秒一次，但要注意芯片内部的转换时间，读得太快读到的可能还是上一次转换的结果。稳妥做法是每次读取前加一个小的延时，或者直接在上一次转换完成后立即发起新一轮读取。

3.4 报警阈值配置：让传感器自己干活

这是很多人忽略的功能。PJ85718DM自带温度阈值比较，可以设置高阈值和高阈值滞回，温度超过阈值时ALERT引脚输出有效电平。这个功能放在HVAC场景里太实用了，比如回风温度超过45°C需要触发排风，过去要在MCU里循环比较，现在配置好阈值寄存器之后，MCU完全不用管，甚至可以在低功耗模式下等着ALERT引脚唤醒。

阈值寄存器的数据格式和温度寄存器一样，也是12位分辨率，写入之前先把温度值除以0.0625换算成原始计数值，再按高低字节分别写入：

#define REG_CONFIG 0x04 #define REG_HIGH_MSB 0x05 #define REG_HIGH_LSB 0x06 void set_high_threshold(float temp_celsius) { int16_t raw = (int16_t)(temp_celsius / 0.0625f); uint8_t buf[3]; uint8_t cfg = 0; HAL_I2C_Mem_Read(&hi2c1, PJ85718DM_ADDR << 1, REG_CONFIG, 1, &cfg, 1, 100); cfg |= 0x04; HAL_I2C_Mem_Write(&hi2c1, PJ85718DM_ADDR << 1, REG_CONFIG, 1, &cfg, 1, 100); buf[0] = (raw >> 8) & 0xFF; buf[1] = raw & 0xFF; HAL_I2C_Mem_Write(&hi2c1, PJ85718DM_ADDR << 1, REG_HIGH_MSB, 1, &buf[0], 1, 100); HAL_I2C_Mem_Write(&hi2c1, PJ85718DM_ADDR << 1, REG_HIGH_LSB, 1, &buf[1], 1, 100); }

ALERT引脚输出模式有比较模式和中断模式两种。比较模式下温度回落到滞回阈值以下之后，ALERT自动解除；中断模式下必须通过读取寄存器来清除标志。HVAC应用一般用比较模式就够了，省得主机反复去清理状态。

3.5 上报协议：把温度送到上位机手里

温度采集完之后，总得有个出口。STM32F042C6的USART1接一个RS485收发芯片，走Modbus RTU协议或者自定义走协议都可以。HVAC行业里Modbus RTU是事实标准，上位机、触摸屏、组态软件都支持，推荐优先考虑。

Modbus RTU读温度分布的核心就是功能码03，主机发送读保持寄存器请求，从机回复寄存器数据。温度信息可以组织成两个寄存器，分别存放本地温度和远程温度，单位0.1°C，用有符号整数的形式表示。帧格式如下：

如果不想用Modbus，自定义协议更简单，帧头加长度加数据加CRC就够了。下面是一个简化的上报代码，温度值保留一位小数，通过串口发出：

void send_temperature_report(void) { uint8_t report[6]; report[0] = 0xAA; report[1] = 0x55; int16_t t_local = (int16_t)(read_temp(REG_TEMP_MSB) * 10); int16_t t_remote = (int16_t)(read_temp(REG_REMOTE_MSB) * 10); report[2] = t_local >> 8; report[3] = t_local & 0xFF; report[4] = t_remote >> 8; report[5] = t_remote & 0xFF; HAL_UART_Transmit(&huart1, report, 6, 100); }

串口波特率我习惯用115200或者9600，HVAC控制箱内部通信对实时性要求不高，9600也够用。要注意的一点是RS485空闲时必须处于接收状态，发送完成后要切换回接收，这个切换时序要处理好，不然总线上会出现一两个字符的回环，主机那边解析就会出错。

4. 调试实录与问题排查速查

4.1 I2C卡死：总线被拉低怎么恢复

I2C总线在工程里最容易遇到的一个问题是总线卡死，现象是程序跑着跑着，SDA线一直被拉低，MCU报总线错误，从此一切读写都失败。我自己调试的时候也遇到过几次，几乎都是从机在传输中间被复位或者干扰打断，I2C状态机停在半路，SDA还维持着输出低电平。

这种问题靠断电重启能解决，但不治本。软件上可以做一个总线恢复流程：把I2C外设禁用，将SCL和SDA引脚重新配置为开漏GPIO，手动翻转SCL九个时钟周期，同时把SDA释放到高电平。这个操作能够让卡死的从机状态机复位。代码实现大概是下面这个样子：

void recover_i2c_bus(void) { GPIO_InitTypeDef GPIO_InitStruct = {0}; __HAL_I2C_DISABLE(&hi2c1); GPIO_InitStruct.Pin = I2C1_SCL_PIN | I2C1_SDA_PIN; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD; GPIO_InitStruct.Pull = GPIO_PULLUP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; HAL_GPIO_Init(I2C1_SCL_PORT, &GPIO_InitStruct); for (int i = 0; i < 9; i++) { HAL_GPIO_WritePin(I2C1_SCL_PORT, I2C1_SCL_PIN, GPIO_PIN_RESET); delay_us(5); HAL_GPIO_WritePin(I2C1_SCL_PORT, I2C1_SCL_PIN, GPIO_PIN_SET); delay_us(5); } HAL_GPIO_WritePin(I2C1_SDA_PORT, I2C1_SDA_PIN, GPIO_PIN_SET); }

这个恢复流程我在几块板子上都试过，只要上拉电阻没接错，九根时钟基本上都能把总线救回来。但要注意，恢复流程对硬件原因导致的总线故障无效，如果你的上拉电阻开路或者MCU引脚损坏，再怎么翻转时钟都没用。

4.2 远程温度读数跳变：探头和干扰的纠缠

远程温度读数偶尔跳个1到2°C，是最难排查的问题之一，因为它可能同时由好几个原因叠加。我的排查思路是按顺序来：

首先检查探头线接触。接线端子氧化、插头松动是最常见的原因。HVAC现场安装时，探头线可能被拉扯过，看似插好了其实内部已经接触不良，这种故障用万用表量电阻往往量不出来，因为静态接触是好的，震动一下才断开。

其次检查采集频率。如果读得太快，芯片内部ADC还没完成转换，读出来的可能是不完整的值，这时候跳变是规律性的。解决方法是给读取周期加限制，至少等待一个转换周期再读。

然后考虑电磁干扰。继电器吸合、变频器启动都会产生强烈的电磁干扰，如果探头线屏蔽不好，干扰会直接耦合进采样信号。前面说的RC滤波和双绞线就是干这个用的。

软件上可以加滑动平均滤波，连续采4到8次去掉最大值最小值再取平均，能过滤掉大部分随机跳变。

#define FILTER_LEN 8 float filter_temperature(float new_value) { static float buf[FILTER_LEN]; static uint8_t idx = 0; float sum = 0; buf[idx] = new_value; idx = (idx + 1) % FILTER_LEN; for (uint8_t i = 0; i < FILTER_LEN; i++) sum += buf[i]; return sum / FILTER_LEN; }

4.3 地址冲突和多板级联

一个控制箱里如果放了好几块采集板，每块板上PJ85718DM的A0和A1都默认接地，那I2C总线肯定全乱了。解决办法也很简单，就是按我们最早说的地址表，把A0、A1接成不同的组合，每块板上分配一个独立地址。

需要注意的是，地址引脚不能悬空。悬空电平不确定，有些板子读出来是0x48，有些又是0x49，生产的时候一批板子地址乱七八糟，排查起来相当头疼。A0和A1一定要明确接地或者接VDD。

如果4个地址还不够用，那就得分I2C总线。STM32F042C6只有一组硬件I2C，但你可以通过I2C MUX芯片来扩展多组总线，每组分给不同的地址组。这个方案我实际用过，配置起来稍复杂，但功能稳定，适合点数多的场景。上电的时候可以写一个总线扫描函数，在0x48到0x4B范围内逐个探测地址，看哪些地址有设备应答，这能很快确认地址有没有配错。

4.4 读出全0xFF或全0：从硬件到软件逐个查

全0xFF的典型场景是主机在跟一个不存在的从机通信。总线上只有上拉电阻，主机发送地址后没有设备应答，读回来的字节自然全是1。这时候检查三件事：地址对不对、A0/A1配置对不对、芯片供电有没有起来。

全0的情况通常是SDA线被某个设备拉住了。用万用表量一下SDA和SCL的空闲电平，正常都应该接近3.3V。如果SDA只有零点几伏，说明总线上有设备在占用总线，或者某个引脚短路到地。先把所有从机拔掉，单独量总线电压，如果恢复高电平，就一个个挂回从机排查。

还有一个小概率是芯片本身坏了。PJ85718DM这类小封装传感器比较容易在焊接过程中受伤，尤其是手工焊接时温度过高或者时间过长。如果硬件检查全都正常但芯片就是不工作，换一颗新的试试，经常当场解决。

4.5 温度读数和真实值有稳定偏差

如果读数不跳变，但整体比实测温度高或者低一个固定值，这种情况一般不是芯片的问题，而是安装和环境的问题。

拿本地通道来说，芯片放在PCB上，如果附近有LDO、功率电阻这类发热源，本地温度读出来自然会偏高，这是正常的物理现象，不是故障。设计板卡的时候要把传感器尽量放在远离主要发热源的位置，或者接受这个偏差后在软件里做补偿。

远程通道出现稳定的正偏差，最常见的原因是探头没有跟被测物体充分接触。探头绑在风管外面跟插到风管里面读数可以差好几度，如果只是为了测量空气温度，探头必须裸露在空气中并且通风良好。如果探头要贴物体表面测温度，必须用导热胶固定，而不是简单地用胶带缠一下。

电源纹波导致的读数整体偏移我前面提过，也可以作为一个排查方向。给传感器VDD单独加一组LC滤波，如果读数恢复正常，那就可以确定是电源的问题。我在一个项目中遇到过本地通道读数整体偏高约1°C的情况，当时测量电源纹波将近100mV，滤波电容补上去之后读数降到了预期范围。

4.6 一个小工具：I2C地址扫描

最后分享一个调试小技巧。系统里挂了多个传感器和从机的时候，写一个I2C地址扫描函数非常有用。原理就是依次向每个地址发送一个单字节写请求，如果收到ACK，说明这个地址上有设备存在。

void scan_i2c_addresses(void) { for (uint8_t addr = 0x08; addr < 0x78; addr++) { if (HAL_I2C_IsDeviceReady(&hi2c1, addr << 1, 1, 10) == HAL_OK) { printf("Found I2C device at 0x%02X\r\n", addr); } } }

这个扫描函数在板卡初次上电调试的时候尤其有用，可以快速确认传感器是否被正确枚举、地址是否冲突。生产环境里也可以保留，配合上位机做产线自检。

我个人实际操作下来的体会是，这套PJ85718DM加STM32F042C6的方案，最大的价值不是省了一颗传感器，而是把温度采集这件事从“模拟世界的精细活”变成了“数字世界的搬运活”。芯片出厂校准帮你省掉了产线的标定工序，双通道帮你省掉了PCB面积和软件分支，I2C数字化输出让你可以用一套统一的协议栈去处理所有温度点。HVAC和嵌入式场景里，温度监测很少是主角，但如果这个配角不稳定，整个系统的控制逻辑都会跟着遭殃。

最后再分享一个小技巧：批量生产的时候，每一片PCB板上都要给传感器留出可以软件校准的温度补偿点，虽然PJ85718DM出厂已经校准过，但PCB布局、探头安装方式都会引入系统性的偏差。预留一个补偿偏移量存储在MCU的Flash里，老化测试时标定一次，比在几十块板子上逐个焊电阻调精度要省事得多。