搞嵌入式这几年我前前后后用过不少温湿度传感器但 DHT11 一直是我心里比较特殊的一个。倒不是说它精度有多高、性能有多强而是在它身上能把“单总线通信”这件事讲得特别透。单总线通信听起来很底层其实理解起来不复杂就是把时钟线和数据线合并成一条线靠严格的时序来区分“0”和“1”。很多做物联网产品、智能家居、环境监测的朋友第一个接触的器件往往就是 DHT11 温湿度传感器再加上 STM32、51 单片机或者 ESP32 这类主控就能快速做出一个能上报温湿度的节点。这篇内容我会把 DHT11 的原理、单总线协议、代码实现从头到尾拆开揉碎重点放在“为什么时序这么重要”和“代码里每个延时都在干什么”这两件事上。无论你是刚入门的学生还是已经在做项目的工程师我都建议把目光从“能跑起来”移到“能看懂时序”上。因为单总线这玩意儿只要时序对了后面所有传感器都一通百通。1. 项目概述与整体设计思路拆解1.1 DHT11 到底是什么单总线又是什么DHT11 是一款数字温湿度传感器内部集成了一个电阻式湿度元件和一个 NTC 测温元件通过一个 8 位 MCU 完成采样和输出。它和主控之间只有一根数据线这根线既承担主机向传感器发送触发信号的任务也承担传感器向主机回传数据的工作。正因为收发共用一根线通信必须靠严格的电平时序来区分方向和数据内容。这里要特别说一句DHT11 的“单总线”和 DS18B20 那种 Maxim 1-Wire 协议并不是一回事。DHT11 使用的是厂商自定义的单总线时序没有设备地址、没有 ROM 指令、不支持多设备挂接每次通信就是主机发一个起始信号然后 DHT11 回传 40 bit 数据。很多初学者拿 DS18B20 的协议栈去读 DHT11结果读出来全是乱的问题就出在这里。单总线通信的难点不在于协议本身有多复杂而在于它对时序精度的要求。DHT11 对电平持续时间的容忍范围相对宽一些数据位“0”的高电平时间大约 26~28 微秒数据位“1”的高电平时间大约 70 微秒只要主控延时函数偏差不是特别离谱都可以正确读到数据。这给我们这些做工程的人留了很大的余地也是为什么我在教学和快速原型阶段特别喜欢用它。1.2 为什么选择 DHT11 来学习单总线通信市面上常见的数字传感器有 I2C、SPI、UART、单总线等几种接口方式。I2C 和 SPI 都有独立的时钟线通信由主控统一控制协议栈成熟固件库一大堆其实不太容易理解底层时序。单总线就不一样了没有时钟线只有一个 GPIO收和发全靠延时函数的准确性。用 DHT11 学习单总线的第一个好处是“慢”。它完整读一次需要至少 18 毫秒的起始信号数据位也只有 40 个整体节奏比那些高速总线慢得多用逻辑分析仪看波形时能看得非常清楚。第二个好处是“便宜”几块钱一片就算调试时接反、烧坏也不心疼。第三个好处是“反馈直观”读到的温度和湿度可以直接通过串口打印出来代码对不对一测就知道。我在很多实训项目里都让学生先做 DHT11再做 DS18B20。因为 DHT11 能把单总线通信的核心思想讲透到了 DS18B20 这种带设备寻址、带 ROM 指令、带 CRC 校验的器件时就能专注于“协议封装”而不会被时序卡住。整个学习路径的坡度非常舒服。1.3 整体方案设计与数据流我常用的方案是“主控 GPIO 上拉电阻 DHT11”三件套。主控用 STM32F103 或者 STM32F407 都可以代码逻辑完全一样如果手头只有 51 单片机也没有问题因为 DHT11 的时序要求没那么苛刻51 的时钟一样能跑。整体数据流大致是主控将 GPIO 配置为推挽输出拉低数据线至少 18 毫秒然后再拉高释放总线。这个过程叫起始信号。主控把 GPIO 切换成输入模式开始等待 DHT11 的响应。DHT11 检测到起始信号后先拉低 80 微秒再拉高 80 微秒表示“我准备好了”。随后 DHT11 连续输出 40 个数据位每位的低电平时间相同高电平时间不同主控通过测量高电平时间判断“0”还是“1”。主机读取完 40 bit 后校验和验证通过把数据拆成湿度整数、湿度小数、温度整数、温度小数四个字节。这里有个很容易踩的坑很多人把 GPIO 配成推挽输出就直接去读输入电平结果发现自己发的电平把自己的读取操作干扰了。规范做法是发完起始信号后把 GPIO 方向切换成输入模式或者用开漏输出加外部上拉电阻。我一般直接在代码里做方向切换这样最简单也最通用。2. 器件原理与单总线协议核心细节解析2.1 DHT11 内部结构与引脚定义DHT11 最常见的封装是 4 引脚单排直插但其实第 3 脚是空脚真正用到的只有 4 个VCC、DATA、NC、GND。市面上也有 3 引脚的贴片模块通常把信号引到单独一根引脚上方便连接。内部结构上DHT11 把湿敏电阻、NTC 热敏电阻和一个 8 位单片机封装在一起。湿度通过湿敏电容的容值变化反映温度通过 NTC 的阻值变化反映内部 MCU 负责采集和模数转换再把结果按协议格式输出。正因为封装里集成了一块 MCUDHT11 才能做到“单线输出数字信号”否则就只是一个模拟量传感器。供电方面DHT11 的典型工作电压是 3.3V~5.5V。这里有一个很多新手容易忽略的点如果是 5V 供电数据线输出高电平也是 5V而 STM32 的 GPIO 耐压一般不能直接吃 5V。所以接 3.3V 的主控时我建议直接给 DHT11 也供 3.3V 电虽然官方手册给的测量精度在 5V 下最理想但实际上 3.3V 供电完全够用。如果必须用 5V 供电数据线上要加电平转换不能直接怼到 3.3V 的 MCU 引脚上。2.2 40 位数据格式与校验规则DHT11 一次完整传输一共输出 40 个 bit也就是 5 个字节顺序固定为字节序号含义示例值1湿度整数部分0x24代表 36%RH2湿度小数部分0x003温度整数部分0x1C代表 28℃4温度小数部分0x005校验和0x24 0x00 0x1C 0x00 的末 8 位校验规则很简单把前四个字节相加取低 8 位如果和第五个字节相等说明数据有效。比如上面这个例子0x24 0x00 0x1C 0x00 0x40那么校验字节就应该是 0x40。如果校验失败我建议直接丢弃本次数据不要拿着错误数据去做后续处理。需要说明的是DHT11 的湿度分辨率是 1%RH温度分辨率是 1℃小数位在多数版本里固定为 0所以很多人说“DHT11 的精度不高”是事实。它的定位就是廉价、易用、够看趋势不适合做高精度计量。如果你需要更高的测量精度可以直接考虑 DHT22也叫 AM2302通信时序和 DHT11 完全兼容只是数据格式不同后续我会顺带提一下。2.3 完整时序拆解起始、响应与数据位DHT11 的时序是整个项目的灵魂。我习惯用“电平宽度”来理解它而不是背一堆数值。整段通信可以拆成四个阶段第一阶段是主机发送起始信号。主控把数据线拉低持续至少 18 毫秒典型值是 20 毫秒左右。很多代码里写成delay_ms(20)目的就是让 DHT11 识别到主机的请求。拉低结束后主控再拉高总线并等待大约 20~40 微秒然后切换成输入模式。这个拉高时间不能太长太长的话 DHT11 会认为通信异常。第二阶段是 DHT11 的响应信号。DHT11 检测到起始信号后会把总线拉低 80 微秒然后再拉高 80 微秒。主机在这段时间里会读到一次低电平再读到一次高电平。判断读到的电平是否符合预期能初步判断传感器是否正常。第三阶段是数据位输出。DHT11 输出每一位时都是先拉低 50 微秒然后再拉高。区别在于拉高的持续时长如果高电平持续 26~28 微秒表示这一位是“0”如果高电平持续约 70 微秒表示这一位是“1”。主控要做的就是循环读取 40 次每次先等待数据线变高再测量高电平持续了多久根据时长判定当前位是 0 还是 1。第四阶段是结束。DHT11 发送完 40 位数据后会释放总线数据线由上拉电阻拉高回到空闲状态。之后主机如果还想再读至少需要间隔 1 到 2 秒让传感器完成下一次采样。DHT11 本身的采样周期大约是 1 秒频繁读取只会得到上一次的缓存数据甚至会读失败。2.4 上拉电阻与电平匹配的选型要点单总线在空闲状态是高电平靠什么拉高要么靠主控内部上拉要么靠外部上拉电阻。DHT11 模块上一般已经焊了 10k 欧姆或 4.7k 欧姆的上拉电阻所以直接用模块会省很多事。如果自己画板子或者用裸传感器我建议外部加一个 5.1k 到 10k 欧姆的上拉电阻接在数据线和 VCC 之间。线缆比较长的时候分布电容会变大可以适当减小上拉电阻到 2.2k 或 3.3k这样上升沿会更陡。但我实测过超过 5 米的普通杜邦线即使减小上拉电阻也容易出现误码所以长距离传输时最好别硬扛改用 RS485 或者干脆换成带总线接口的传感器。电平匹配是个非常重要但常被忽略的点。DHT11 数据线的高电平等于供电电压如果你用 5V 给 DHT11 供电那么信号线的高电平就是 5V。对 5V 的 51 单片机来说问题不大但对 3.3V 的 STM32、ESP32 来说直接读取 5V 信号悬。虽然很多 STM32 引脚标称“5V 容忍”但我不建议长期这么干。最靠谱的方式就是统一用 3.3V 供电千万别省这一步。3. 驱动代码实现与关键步骤复现3.1 环境准备与 GPIO 初始化我以 STM32F103 HAL 库为例子因为这是目前学习单片机最主流的环境。如果用的是 51、Arduino、ESP-IDF核心逻辑完全一样只是寄存器操作方式不同。先把 GPIO 初始化写清楚#define DHT11_GPIO_PORT GPIOA #define DHT11_GPIO_PIN GPIO_PIN_1 #define DHT11_GPIO_CLK_ENABLE() __HAL_RCC_GPIOA_CLK_ENABLE() void DHT11_CtrlOutput(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_GPIO_PIN; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_PULLUP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(DHT11_GPIO_PORT, GPIO_InitStruct); } void DHT11_CtrlInput(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; GPIO_InitStruct.Pin DHT11_GPIO_PIN; GPIO_InitStruct.Mode GPIO_MODE_INPUT; GPIO_InitStruct.Pull GPIO_PULLUP; HAL_GPIO_Init(DHT11_GPIO_PORT, GPIO_InitStruct); }这里我通过DHT11_CtrlOutput()和DHT11_CtrlInput()快速切换引脚方向。相比开漏输出加外部上拉的方式这种“推挽输出 切输入模式”的方式在代码上更直观也不依赖外部上拉电阻。每块模块都带了上拉电阻所以用内部上拉其实就够但为了更可靠我经常在代码里把内部上拉也打开外部电阻和内部上拉并联之后等效上拉会更强一点时序反而更稳定。3.2 微秒级延时DWT 实现方式写 DHT11 驱动时最忌讳用HAL_Delay()这种毫秒级延时去凑微秒。DHT11 的数据位“0”和“1”之差也就是几十微秒如果用轮询系统滴答来实现微秒延时精度完全没法保证。我在 ARM Cortex-M 平台上的做法是直接用 DWT 计数器这是内核里自带的一个调试计数器不需要额外占用定时器。static void DWT_Delay_Init(void) { CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; } static void DWT_Delay_us(uint32_t us) { uint32_t start DWT-CYCCNT; uint32_t ticks us * (SystemCoreClock / 1000000); while ((DWT-CYCCNT - start) ticks); }SystemCoreClock是当前系统主频。如果主频是 72MHz那么 1 微秒就是 72 个时钟周期。DWT 计数器会记录从启动到现在的周期数通过差值计算延时非常精确而且不干扰主流程。这个函数是所有单总线驱动的地基延时准了后面读到的每一位才准。如果你的平台不支持 DWT还有一个替代方案定时器延时。开一个 1MHz 的定时器计数器每 1 微秒加一然后在轮询里等待目标值。效果一样只是要多占用一个定时器外设。我测试过在 51 单片机上直接用_nop_()组合也能读 DHT11但那样做可移植性差、可读性差只适合临时验证不适合做产品代码。3.3 起始信号与响应检测代码接下来是核心读取过程。我先写一个“读一个字节”的辅助函数这样后面的主流程会非常清晰。static uint8_t DHT11_ReadByte(void) { uint8_t data 0; for (int i 0; i 8; i) { while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_RESET); DWT_Delay_us(40); if (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { data (data 1) | 0x01; } else { data (data 1); } while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET); } return data; }这个函数的思路是从低位开始还是从高位开始不对从代码上看是data data 1也就是先接收的位会逐步移到最高位所以 DHT11 发来的第一位是字节的最高位。DHT11 先发湿度整数部分的最高位因此这个顺序是正确的。逐行解释一下while (data 0)等待数据线拉低对应数据位的 50 微秒低电平阶段。等到低电平结束、数据线拉高之后延时 40 微秒。如果 40 微秒后数据线仍然是高电平说明这个位的总高电平长度超过了 40 微秒基本可以判定是“1”如果已经是低电平说明高电平只有 26~28 微秒判定为“0”。最后再等待高电平结束为下一个位做准备。这里 40 微秒这个阈值很关键。我见过有人用 50 微秒做阈值也能跑但边缘情况容易误判。DHT11 数据位“0”的高电平典型值在 26~28 微秒“1”的典型值在 70 微秒取中间偏左的值 40 微秒最安全。主流程如下uint8_t DHT11_ReadData(uint8_t *humidity, uint8_t *temperature) { uint8_t buf[5] {0}; uint8_t crc 0; DHT11_CtrlOutput(); HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_RESET); DWT_Delay_us(20000); HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_SET); DWT_Delay_us(30); DHT11_CtrlInput(); if (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET) { return 1; } while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_RESET); while (HAL_GPIO_ReadPin(DHT11_GPIO_PORT, DHT11_GPIO_PIN) GPIO_PIN_SET); for (int i 0; i 5; i) { buf[i] DHT11_ReadByte(); } DHT11_CtrlOutput(); HAL_GPIO_WritePin(DHT11_GPIO_PORT, DHT11_GPIO_PIN, GPIO_PIN_SET); crc buf[0] buf[1] buf[2] buf[3]; if ((crc 0xFF) ! buf[4]) { return 2; } *humidity buf[0]; *temperature buf[2]; return 0; }启动部分的细节是拉低 20 毫秒释放总线 30 微秒然后切输入。我用 30 微秒而不是更长的等待是因为 DHT11 在主机释放总线后很快就会响应如果等待太长会错过响应信号的下降沿。切到输入模式后数据线被模块上的上拉电阻拉高然后 DHT11 会主动拉低 80 微秒所以代码里先判断一次总线电平如果还是高说明 DHT11 没有响应。响应信号的while等待会有一个潜在问题如果传感器没接好或者损坏电平一直不变化代码会卡死在循环里。工程上做产品时我会加一个超时计数比如用DWT_Delay_us(100)配合循环次数判断。这里为了教学先展示最核心的逻辑实际项目里建议补上超时保护。3.4 数据拼接与校验代码实现读取完成并校验后humidity和temperature就直接指向湿度整数和温度整数。在 main 函数里的调用方式很简单uint8_t humi 0; uint8_t temp 0; uint8_t res 0; DWT_Delay_Init(); DHT11_CtrlOutput(); while (1) { res DHT11_ReadData(humi, temp); if (res 0) { printf(Humi: %d%%RH, Temp: %d C\r\n, humi, temp); } HAL_Delay(2000); }每次读取之间我间隔 2 秒目的是留够 DHT11 的采样时间。DHT11 的最小采样周期是 1 秒间隔 1 秒以上读到的数据才有效。这也是为什么你看到很多人做 DHT11 项目时刷新率都很低这不是能力问题而是传感器本身的特性决定的。4. 实测过程、常见问题与排查技巧实录4.1 常见读数异常症状与原因速查表我在实际项目里帮人排查过很多 DHT11 问题多数症状集中在“读不到数据”“全是 0xFF”“数据偶尔跳变”“温度正常湿度不对”这几类。下面这张表是我长期使用的速查表能解决绝大部分问题症状直接原因排查方向读数全为 0xFF数据线电平一直为高没进入数据位阶段检查接线、供电、引脚是否配置错读数全为 0x00数据位被全部判定为“0”检查微秒延时精度、主频配置、DWT 初始化校验和一直失败时序偏移导致读错位用逻辑分析仪看波形核对每一位长度偶尔成功偶尔失败干扰、线缆过长或供电波动缩短导线、加粗电源线、检查上拉电阻温度正常湿度明显不对DHT11 个体差异或湿敏元件受污染换个模块对比避免在强湿/腐蚀环境使用上电后需要很久才能读到起始信号拉低时间不够检查延时函数确保拉低超过 18ms最典型的问题其实是主频不匹配。很多 HAL 库工程默认把SystemCoreClock设置为 72MHz但如果有人在 CubeMX 里改了主频或者使用了外部晶振启动失败后降到了内部 RC 振荡器SystemCoreClock变量没有同步更新DWT 延时就会出现成倍数的误差读出来的数据自然乱七八糟。我在排查的时候会先打印SystemCoreClock的数值然后接上逻辑分析仪看数据线波形。只要看一眼波形里的起始信号宽度和数据位高电平长度就能判断问题出在哪一层。4.2 用逻辑分析仪调试 DHT11 波形DHT11 调试最有力的工具是逻辑分析仪。市面上几十块钱的 8 通道逻辑分析仪就够用配合 Sigrock 软件或者 PulseView 都能很快看到波形。把通道夹到数据线上设置采样率至少 1MHz触发方式设为下降沿然后手动触发一次读取就能捕获完整的一次通信过程。在波形上你要重点看三段起始信号是不是稳定在 20ms 左右DHT11 的响应信号是否是完整的 80us 低电平 80us 高电平后面每一位的低电平是否一致高电平是否明显分为“短、长”两档。如果高电平长短差异不明显多半是传感器本身有问题或者供电太低如果每一位的高电平长度忽长忽短那就要考虑是不是总线干扰过大。我遇到过一种很隐蔽的情况DHT11 模块上自带上拉电阻但主板 IO 上还接了下拉电阻或者 LED 指示灯导致总线上电时电平被拉低DHT11 根本无法正常工作。这种问题光看代码是看不出来的必须靠波形和原理图双重排查。所以我的经验是模块买回来先别急着接板子直接用逻辑分析仪配合一个独立测试电路验证传感器本身是好是坏能省掉后面大量时间。4.3 线缆、供电与环境干扰的坑DHT11 的通信频率不高但电源噪声和线缆电容会严重影响波形边沿。我给一个客户做环境监测节点时把 DHT11 用 3 米长的双绞线接到主板加 100 毫秒的读取周期结果 30% 的概率校验失败。后来把供电线从数据线附近挪开再把上拉电阻从 10k 改成 3.3k误码率直接降到可以忽略的程度。供电问题也很常见。DHT11 虽然耗电不大但如果和电机、继电器共用电源开关瞬间的电压跌落会让传感器复位或者输出异常。我建议几个做法DHT11 的 VCC 单独走一条较粗的线不要在传感器旁边并联大电流负载主控和传感器共地如果噪声实在压不住就在传感器供电脚旁边加一个 100nF 的去耦电容必要时串一个 10 欧姆的磁珠。环境干扰方面如果传感器会长时间暴露在高温高湿、油烟或者粉尘环境里湿敏元件很可能被污染导致湿度读数偏高甚至一直固定在某个值。这种问题没法靠代码解决只能定期校准或者更换。做工业级产品时我会选择把 DHT11 装在探针式的防护壳里或者干脆改用模拟量输出的湿度传感器配合主控的 ADC 读取抗污染能力会强得多。5. 应用场景与后续扩展方向5.1 DHT11 适合的典型应用场景DHT11 的精度虽然不高但胜在便宜、简单、低功耗非常适合对精度要求不高的温湿度采集场景。我梳理了几个典型的应用智能家居的室内环境监测面板只需要知道当前温度和大致湿度用来控制加湿器、除湿机、空调精度要求并不高。农业大棚的土壤环境辅助监测放在大棚里测空气温湿度用于判断通风时机DHT11 完全够用。实验室或机房的温湿度报警装置设定阈值超限就触发蜂鸣器或者联网告警。嵌入式入门实验和课程设计DHT11 是学习单总线时序、GPIO 操作、定时器应用的最佳载体。在这些场景里DHT11 最大的优势不是性能而是容易调试。代码量少出问题也能快速定位属于“一次调通长期省心”的器件。如果你是在做小批量产品而不是严格计量设备直接焊 DHT11 模块往往比用 DHT22 或者 SHT30 更省成本功能也能满足要求。5.2 与 DHT22、SHT30、DS18B20 的选型对比说到选型很多人会把 DHT11、DHT22、SHT30、DS18B20 放在一起比。我列一张实际选型时常用的对照表方便大家根据自己的场景快速决策传感器接口温度精度湿度精度成本适合场景DHT11单总线±2℃±5%RH最低低成本环境监测、入门学习DHT22单总线±0.5℃±2%RH中家居环境、对湿度有一定要求SHT30I2C±0.3℃±2%RH较高高精度计量、便携设备DS18B201-Wire±0.5℃无湿度中测温专用、多点测温DHT11 和 DHT22 的硬件连接几乎一模一样DHT22 的数据格式是 16 位湿度 16 位温度 8 位校验。如果你已经把 DHT11 驱动调通了升级到 DHT22 只需要改数据解析部分整套时序代码可以直接复用。SHT30 走的是标准 I2C精度更高但驱动代码量明显增加还要考虑 I2C 地址和命令配置。DS18B20 虽然也叫“单总线”但它属于真正的 1-Wire 协议支持设备寻址和多点测量适合做分布式测温。我的建议是如果你只需要“测个大概温湿度”选 DHT11如果你需要湿度数据更有参考价值选 DHT22如果是产品化且对成本不敏感SHT30 是更稳的选择。5.3 长期运行与低功耗设计的一些体会最后分享一点我在实际产品中的经验。DHT11 平时不为零功耗设备设计但如果要做电池供电的采集节点可以通过切断 VCC 来降低功耗。主控 GPIO 直接给 DHT11 VCC 供电读取前拉高、读取后拉低这样待机电流能降到很低。需要注意的是DHT11 上电后需要等待至少 1 秒才能稳定读取所以每次唤醒后要先延时再触发通信。湿度传感器长期通电会加速湿敏元件老化所以我更推荐“按需供电”的方式。一个采集周期大概是上电 1 秒读取 20 毫秒断电 59 秒这样一个电池节点的续航可以做到数月。这个方案我在低功耗温湿度记录仪上实际跑过数据稳定性没有任何问题。还有一点如果 DHT11 数据线需要走比较长的距离我更愿意在传感器端加一个简单电平隔离把其单总线转成标准的串口或者 RS485再往主控传。这样虽然多了一个芯片成本但抗干扰能力能提升一个档次后期维护也轻松很多。单总线通信这个东西学的时候觉得时序难把握真正理解了以后会发现它其实特别美一条线就能传输完整的数据帧省 IO、省布线特别适合做功能简单的低成本传感节点。DHT11 只是其中一扇门把它的时序摸透了后面再接触各类采用单总线或者类单总线协议的器件都会事半功倍。