UART传输时间精确计算：从波特率到帧结构的微秒级解析

1. 为什么“UART传输时间”不是查表就能解决的问题？

很多人第一次算UART时间，是打开Excel，输入“115200”，然后用1除以波特率，得到约8.68微秒——接着就以为一个比特的时间搞定了。我当年也是这么干的，直到在调试一个温湿度传感器时，发现上位机收到的数据总是错一位，反复检查代码、接线、电平都没问题，最后盯着示波器上一帧完整的UART波形看了整整两小时，才意识到：波特率只定义了单个比特的宽度，而一帧数据的总耗时，是由起始位、数据位、校验位、停止位共同决定的物理时序，它必须按位累加，不能靠“平均值”蒙混过关。

这恰恰是绝大多数教程和文档回避的细节：它们告诉你“115200bps表示每秒传115200个比特”，却从不强调“这个‘比特’指的是线路上传输的原始电平跳变单元，不是你程序里读到的那个字节”。当你把一个uint8_t变量通过UART发出去，它不会自动变成8个比特；它必须被封装进一帧符合UART协议的信号序列里——这个序列里，真正承载你数据的只有中间那几个“数据位”，前后全是开销。

比如标题里提到的“8N1”，这是工业现场最常用的配置，意思是：1个起始位（低电平）+ 8个数据位（LSB先发）+ 无校验位 + 1个停止位（高电平）。加起来一共10个比特。所以，哪怕你只发一个字节0x55，线路上实际要跑10个比特，耗时就是10 × (1 / 115200) ≈ 86.8微秒。但如果你换成“7位数据模式”，比如某些老式PLC或仪表协议要求的7E1（7数据位+偶校验+1停止位），那整帧就是1+7+1+1=10比特，看起来一样？错。校验位的计算逻辑会改变每一位的电平，更重要的是——7位模式下，你发送的字节高1位被截断了，接收端如果还按8位解析，就会整体偏移，数据全乱。

这就是为什么“UART传输时间怎么算”从来不是个纯数学题，而是一个嵌入式系统工程师每天都要面对的物理层契约问题：你写的每一行HAL_UART_Transmit()，背后都对应着示波器上一段精确到微秒的电平序列。它决定了你的中断响应能不能跟上、DMA缓冲区会不会溢出、两个设备之间能不能握手成功。我见过太多项目卡在“通信偶尔丢包”上，最后发现根本不是软件bug，而是工程师在设计协议时，连一帧到底占多少微秒都没算清楚，导致超时阈值设得比实际传输时间还短。

所以，这篇文章不讲概念复述，也不列一堆公式完事。我会带着你，从示波器捕获的真实波形出发，手把手拆解每一帧的构成，告诉你为什么“8N1”和“7位数据模式”在时间维度上看似接近，实则暗藏陷阱；为什么FT231X这类USB转串口芯片的驱动安装顺利，不代表你的应用层时序就一定稳；以及，在Linux内核驱动或Verilog RTL实现中，那些被封装起来的“自动处理”，底层到底是怎么靠精确计数器咬住每一个比特边沿的。

提示：本文所有计算均基于标准UART异步通信模型，不涉及同步UART、LIN总线或自定义编码。所有时间值保留小数点后两位，单位统一为微秒（μs），便于与示波器读数直接比对。

2. 从示波器波形反推：一帧UART信号的原子级构成

要真正理解UART传输时间，最好的老师不是数据手册，而是示波器。我手头有一块STM32F407开发板，连接CH340 USB转串口模块，用100MHz带宽示波器探头抓取TX引脚波形，发送单字节0x00（全0）和0xFF（全1），对比观察。你会发现，无论发什么数据，起始位和停止位的宽度永远固定，而数据位部分的高低电平组合，完全由你发送的字节内容决定。这正是异步通信的精髓：没有共享时钟，全靠双方约定好的波特率和帧结构来对齐。

我们以最典型的“8N1”配置为例，逐位拆解一帧完整信号（以发送0x55即二进制01010101为例）：

2.1 起始位：低电平的“发令枪”，强制同步的唯一锚点

• 电平状态：持续一个比特时间的低电平（逻辑0）
• 作用：告诉接收端“新一帧开始了”，是整个异步通信的唯一硬同步信号。接收端检测到下降沿后，立即启动内部采样计数器。
• 时间计算：严格等于1 / 波特率
  对于115200bps：1 / 115200 ≈ 8.68 μs
• 关键细节：起始位必须是干净的下降沿，不能有毛刺。如果前一帧的停止位之后有噪声干扰导致误触发，就会产生“假起始位”，后续所有数据全错。这也是为什么UART线上通常要加10kΩ上拉电阻——保证空闲时为高电平（停止位状态），避免浮空引入干扰。

2.2 数据位：真正的信息载体，LSB优先是铁律

• 数量：可配置为5、6、7、8、9位，但8位是绝对主流，硬件支持最完善，软件库默认值。
• 顺序：LSB（最低位）先发。这是UART协议的硬性规定，不可更改。发送0x55（01010101）时，线路上实际出现的顺序是：1,0,1,0,1,0,1,0（注意：这是从左到右的时间顺序，第一个发出的是bit0）。
• 时间计算：每位独立占用1 / 波特率时间
  8位总耗时：8 × (1 / 115200) ≈ 69.44 μs
• 为什么LSB优先？这源于早期电传打字机（Teletype）的设计传统。低位先发，可以让接收端的移位寄存器在接收到最高位（MSB）时，刚好完成全部8位的移入，便于直接送入CPU总线。现代MCU的UART外设寄存器（如STM32的USART_DR）写入一个字节，硬件自动按此顺序串行输出，开发者无需干预。

2.3 校验位：可选的“数据指纹”，但7位模式常绕不开它

• 存在性：可选（None）、奇校验（Odd）、偶校验（Even）、标志校验（Mark/Space）。标题中的“8N1”明确为“N”即None，但“7位数据模式”往往搭配校验位使用，如7E1、7O1。
• 计算逻辑：以偶校验（7E1）为例，发送端统计7个数据位中“1”的个数，若为奇数，则校验位设为1，使总“1”的个数为偶数；若为偶数，则校验位为0。接收端做同样统计，若结果非偶数，则报“校验错误”。
• 时间计算：占用1个比特时间，1 / 115200 ≈ 8.68 μs
• 7位模式下的真实代价：很多人以为“7位数据”能省时间，其实不然。7E1帧结构为：1（起）+7（数）+1（校）+1（停）=10比特，总时间≈86.8μs，与8N1相同。但信息密度下降：你用10比特只传了7位有效数据，效率从80%（8/10）降到70%（7/10）。更麻烦的是，如果你的应用协议规定必须用7位，而你的MCU UART外设只支持8位数据位（如大部分Cortex-M系列），你就得手动拆包——把8位寄存器里的高1位屏蔽掉，再拼成7位发送，这会引入额外的CPU开销和时序不确定性。

2.4 停止位：高电平的“句号”，为下一帧预留安全间隔

• 电平状态：持续一个或多个比特时间的高电平（逻辑1）
• 数量：通常为1位，也可设为1.5位（用于旧式RS-232）或2位（提高容错性，尤其在低速或长距离时）。
• 时间计算：1位停止位 =1 / 115200 ≈ 8.68 μs
• 核心作用：不仅是标识本帧结束，更是为接收端提供“喘息时间”。接收端在采样完最后一个数据位（或校验位）后，需要时间将数据移入接收缓冲区、更新状态寄存器、触发中断。如果停止位太短，而下一个起始位紧跟着到来，就可能造成“帧错误（Framing Error）”。这也是为什么在高波特率（如921600）下，强烈建议使用1位停止位——因为2位停止位会让每帧多耗8.68μs，在连续发送大量数据时，累积延迟显著。

现在，我们把所有部分加起来，得到一帧的总时间：

注意：这个86.80μs是理论最小值。实际中，由于晶体振荡器精度（通常±1%~±2%）、信号上升/下降时间（受PCB走线、终端电阻影响）、以及MCU内部时钟分频误差，真实波特率会有微小偏差。例如，用8MHz晶振分频生成115200bps，理论误差可能达-3.2%，这意味着实际比特时间为9.0μs而非8.68μs，整帧时间变为90.0μs。这就是为什么两个设备通信前，必须确认彼此的时钟源精度是否匹配，否则即使配置完全一致，也会因累积误差导致采样点漂移。

3. “7位数据模式”不是功能开关，而是协议级妥协与工程权衡

标题里把“115200、8N1”和“7位数据模式”并列，很容易让人误解为“只是改个寄存器配置就行”。但我在给一家工业网关做Modbus RTU协议适配时，被这个“7位”坑了整整三天。客户提供的老式电表，其Modbus从机固件只认7E1，而我们的主控芯片（NXP i.MX RT1064）的LPUART外设，在数据位配置寄存器中，根本没有7位选项——它只支持8或9位。这逼着我深入到寄存器层面，手动模拟7位行为。这件事让我彻底明白：“7位数据模式”从来不是一个孤立的技术点，它是历史遗留、硬件限制、协议强制三者交织的产物。

3.1 为什么会有7位？历史包袱与物理限制的双重烙印

• 电传打字机时代（1950s-1970s）：最早的TTY设备使用5位Baudot码，后来升级到7位ASCII码（128个字符足够英文和控制符）。当时存储和带宽极其昂贵，能省1位就省1位。7位+1位校验+1位停止位（7E1），成了成本与可靠性平衡的经典方案。
• 早期MCU资源限制：8051等经典8位单片机，其UART模块的移位寄存器深度常为8位，但为了兼容老协议，会通过软件方式“截断”最高位。这在资源紧张的嵌入式系统中很常见。
• 特定行业协议固化：如电力行业的DL/T645电表协议、某些PLC的私有指令集，明确规定使用7数据位。这不是技术先进与否的问题，而是“存量设备太多，改协议成本远高于维持现状”。

3.2 硬件层面的真相：多数现代UART外设根本不原生支持7位

翻阅ST、NXP、TI等主流厂商的最新MCU参考手册，你会发现一个事实：几乎所有的新型ARM Cortex-M系列MCU（如STM32H7、i.MX RT1170、MSP432P401R）的UART外设，其数据位配置寄存器（如USART_CR1: M[1:0]）只提供两种选择：0b00=8位，0b01=9位。7位不在选项中。这不是疏忽，而是权衡后的设计决策——硬件支持8/9位已覆盖99%的应用，为小众的7位增加额外的逻辑门和寄存器位，会提高芯片面积和功耗，得不偿失。

那么，如何实现7位？只有两条路：

1. 软件模拟（Bit-Banging）：放弃硬件UART，用GPIO和精准延时（如SysTick或DWT周期计数器）手动翻转电平，逐位生成起始、数据、停止信号。优点是完全可控；缺点是CPU占用率100%，无法处理其他任务，且波特率稳定性差。
2. 硬件UART+软件预处理（推荐）：利用硬件UART的8位模式，但在发送前，将待发的8位字节的最高位（bit7）清零，使其自然成为7位数据；接收时，将硬件读到的8位字节的bit7忽略，只取低7位。这正是我最终在i.MX RT1064上采用的方案。

3.3 实操案例：在STM32 HAL库中安全实现7E1

假设你要用STM32F407的USART1，以115200bps、7E1模式与老设备通信。HAL库本身不提供7位API，但我们可以“曲线救国”：

// 步骤1：初始化USART为标准8N1（这是HAL唯一支持的） huart1.Instance = USART1; huart1.Init.BaudRate = 115200; huart1.Init.WordLength = UART_WORDLENGTH_8B; // 强制8位 huart1.Init.StopBits = UART_STOPBITS_1; huart1.Init.Parity = UART_PARITY_NONE; // HAL不支持硬件校验位生成！ huart1.Init.Mode = UART_MODE_TX_RX; // ... 其他配置 HAL_UART_Init(&huart1); // 步骤2：发送7E1数据——关键在手动计算偶校验位 uint8_t send_byte_7e1(uint8_t data_7bit) { // data_7bit 是你要发送的7位数据（0x00-0x7F） uint8_t data_8bit = data_7bit & 0x7F; // 确保高1位为0 // 手动计算偶校验位：统计data_7bit中1的个数 uint8_t parity_bit = 0; uint8_t temp = data_7bit; for(int i=0; i<7; i++) { if(temp & 0x01) parity_bit++; temp >>= 1; } parity_bit = (parity_bit % 2) ? 0 : 1; // 偶校验：1的个数为偶数时，校验位=0 // 构造8位发送字节：低7位=数据，bit7=校验位 // 注意：UART硬件会把整个8位当数据发，所以我们把校验位放在最高位 return (parity_bit << 7) | data_7bit; } // 步骤3：调用HAL发送（此时发送的是8位字节，但内容符合7E1逻辑） uint8_t tx_buf[1]; tx_buf[0] = send_byte_7e1(0x55); // 发送7位数据0x55 HAL_UART_Transmit(&huart1, tx_buf, 1, HAL_MAX_DELAY);

接收端同理，需手动校验：

// 接收后，从8位字节中提取7位数据并验证校验 uint8_t rx_byte = /* 从USART_DR读取 */; uint8_t data_7bit = rx_byte & 0x7F; // 取低7位 uint8_t recv_parity = (rx_byte & 0x80) ? 1 : 0; // 取bit7作为接收到的校验位 // 重新计算data_7bit的偶校验 uint8_t calc_parity = 0; uint8_t temp = data_7bit; for(int i=0; i<7; i++) { if(temp & 0x01) calc_parity++; temp >>= 1; } calc_parity = (calc_parity % 2) ? 0 : 1; if(recv_parity != calc_parity) { // 校验失败，丢弃该字节 }

提示：这种方案下，一帧的实际结构是：1（起）+8（含校验的数据）+1（停）=10比特，总时间仍是86.80μs。但逻辑上，它完美模拟了7E1的语义。关键在于，你必须确保通信双方都采用完全相同的校验计算逻辑，否则永远对不上。

4. 从驱动到RTL：FT231X、Linux内核与Verilog如何“看不见”地搞定时间

当我们说“UART传输时间”，往往默认指物理层线路上的电平持续时间。但对应用开发者而言，更常遇到的问题是：“我调用write()函数后，数据多久能真正出现在TX引脚上？”、“为什么read()返回了，但示波器上还没看到波形？”——这中间隔着USB协议栈、驱动、内核缓冲区、硬件FIFO，每一层都在悄悄“吃掉”时间。标题中提到的“ft231x usb uart驱动”，正是这个链条的关键一环。

4.1 FT231X：USB转UART桥接芯片的时序黑箱

FT231X（及其前辈FT232R）是市场上最普及的USB-UART桥接芯片。它的本质是一个“协议翻译器”：一边是高速、包驱动的USB 2.0（480Mbps），另一边是低速、流式的UART（最高仅3Mbps）。它内部有一个关键部件——可配置的硬件FIFO（First-In-First-Out）缓冲区，通常是1024字节。这个FIFO，就是时间延迟的根源。

• 发送路径延迟分析（以Linux主机为例）：
  1. 应用层调用write(fd, buf, len)→ 数据拷贝到内核tty子系统的write_buf缓冲区。
  2. tty层判断数据量，若小于FIFO阈值（默认256字节），可能暂不提交给USB驱动。
  3. 当缓冲区满或超时（USB_SERIAL_TTY_MIN_WRITE_WAIT，通常10ms），ftdi_sio驱动将数据打包成USB OUT事务，发送给FT231X。
  4. FT231X收到USB包后，将其解包，存入内部TX FIFO。
  5. FT231X的UART引擎从FIFO取数据，按设定的波特率（如115200）逐帧发送到TX引脚。

这个过程的总延迟，是各环节之和。其中，USB协议本身的事务调度（每1ms一个帧，每个帧内最多安排一个OUT事务）和FT231X内部FIFO的填充策略，贡献了最大的、不可预测的抖动。实测表明，在Linux下，从write()返回到TX引脚出现第一个下降沿，典型延迟为1~15ms，远大于86.80μs的单帧时间。这就是为什么用FT231X做实时性要求高的闭环控制（如电机PID）会失败——你根本无法精确控制两个命令之间的微秒级间隔。

• 解决方案：在FT231X的EEPROM配置中，启用“FTDI Driver's Latency Timer”并将其设为1ms（默认16ms），并禁用“USB Transfer Size”自动优化，强制小包发送。这能将典型延迟压到1~3ms，虽仍不满足微秒级，但对大多数工业通信已足够。

4.2 Linux内核UART驱动：serial_core.c里的时序守护者

Linux内核的通用串口驱动框架（drivers/tty/serial/serial_core.c）是另一个时间管理大师。它通过一个精巧的“传输完成回调”机制，将硬件中断与软件缓冲区无缝衔接。

• 关键数据结构：struct uart_port中的xmit成员，是一个环形缓冲区（struct circ_buf），大小通常为1024字节。
• 发送流程：
  1. uart_write()将用户数据拷贝到xmit缓冲区。
  2. 如果此时UART硬件空闲（uart_circ_empty(&port->xmit)为假），驱动立即调用uart_start()。
  3. uart_start()启用UART的“发送空中断（TXE）”，并发送缓冲区中的第一个字节。
  4. 每当硬件发送完一个字节，触发TXE中断，中断服务程序（ISR）从xmit中取出下一个字节发送，直到缓冲区为空。
  5. 当xmit为空时，驱动关闭TXE中断，等待下次write()填充。

这个设计的精妙之处在于：它把“发送一个字节”的硬件操作（耗时86.80μs）与“从缓冲区取下一个字节”的软件操作（纳秒级）解耦了。CPU不需要死等，可以去处理其他任务。而整个发送过程的总时间，就是(字节数 × 单帧时间) + 中断响应开销。对于100字节数据，理论最小时间为100 × 86.80μs = 8.68ms，加上几十微秒的中断延迟，实测约8.7ms。

4.3 Verilog RTL实现：在FPGA上亲手“雕刻”时间

如果你想彻底掌控UART时间，FPGA是终极答案。下面是一段极简的、可综合的Verilog UART发送器核心逻辑，它展示了时间是如何被“数字化”地精确咬合的：

// 参数化波特率发生器（以50MHz时钟为例） localparam CLK_FREQ = 50_000_000; localparam BAUD_RATE = 115200; localparam BAUD_CNT = CLK_FREQ / BAUD_RATE; // = 434 reg [11:0] baud_cnt; // 12位计数器，最大4095 > 434 always @(posedge clk) begin if(rst) baud_cnt <= 0; else if(baud_en) begin if(baud_cnt == BAUD_CNT - 1) baud_cnt <= 0; else baud_cnt <= baud_cnt + 1; end end wire baud_tick = (baud_cnt == BAUD_CNT - 1); // 每BAUD_CNT个时钟，产生一个tick // 发送状态机 reg [3:0] tx_state; reg [6:0] bit_cnt; // 7位计数器：起始(0), 数据0-6, 停止(7) reg tx_out; always @(posedge clk) begin if(rst) begin tx_state <= IDLE; bit_cnt <= 0; tx_out <= 1'b1; // 空闲高电平 end else case(tx_state) IDLE: begin if(tx_start) begin // 外部请求发送 tx_state <= START; bit_cnt <= 0; tx_out <= 1'b0; // 发起始位 end end START: begin // 起始位：1 bit if(baud_tick) begin tx_state <= DATA; bit_cnt <= 0; tx_out <= tx_data[0]; // LSB先发 end end DATA: begin // 数据位：7位（7位模式） if(baud_tick) begin bit_cnt <= bit_cnt + 1; if(bit_cnt == 6) begin // 最后一位数据（bit6） tx_state <= STOP; tx_out <= 1'b1; // 准备停止位 end else begin tx_out <= tx_data[bit_cnt + 1]; end end end STOP: begin // 停止位：1 bit if(baud_tick) begin tx_state <= IDLE; tx_out <= 1'b1; end end endcase end

这段代码的核心思想是：用一个高精度的系统时钟（50MHz），通过计数器分频，生成一个与目标波特率严格同步的baud_tick信号。所有状态跳转，都只在baud_tick的上升沿发生。这意味着，从起始位下降沿，到第一个数据位采样点，再到停止位上升沿，每一步都精确锁定在理论时间点上，误差仅为一个系统时钟周期（20ns）。这才是真正的“微秒级确定性”。

注意：实际FPGA工程中，还需添加跨时钟域同步、FIFO接口、奇偶校验逻辑等。但时间精度的根基，永远是这个baud_tick。我曾用此逻辑在Xilinx Artix-7上实现12Mbps UART，示波器测量比特宽度误差小于0.1%，远超任何MCU的硬件UART。

5. 实战避坑指南：那些让UART时间计算失效的“幽灵因素”

就算你把波特率、帧结构、硬件特性全都算得明明白白，现实世界依然会给你上一课。我在调试一个基于FT232R的GPS模块数据采集系统时，发现明明配置是9600bps、8N1，但cat /dev/ttyUSB0出来的NMEA语句却严重错乱。示波器显示波形完美，比特宽度分毫不差。最后排查了两天，才发现罪魁祸首是——USB线缆长度。一根3米长的劣质USB线，引入了超过100ns的信号抖动，恰好让接收端的采样点落在了比特边沿的模糊区。这提醒我们：UART时间计算，必须放在真实的物理环境中验证。

5.1 信号完整性：看不见的“时间膨胀”

• 上升/下降时间（Rise/Fall Time）：理想方波的跳变是瞬时的，但现实中，受限于驱动能力、PCB走线电感、负载电容，信号边沿是斜坡。示波器上测量一个115200bps信号的上升时间，优质线路可能为100ns，而长线+大容性负载可达500ns。这意味着，接收端的“采样点”（通常在比特时间的中间1/3处）如果设置不当，就可能采到不稳定的过渡电平，导致误判。
• 解决方案：在TX端串联一个22~100Ω的源端匹配电阻，可显著改善边沿质量。同时，确保RX端的输入阻抗足够高（>10kΩ），避免过载。

5.2 晶振精度：藏在数据手册角落的“定时炸弹”

几乎所有MCU的数据手册，在“电气特性”章节末尾，都会有一行不起眼的标注：“UART波特率误差，取决于系统时钟源精度”。一个标称±20ppm（0.002%）的温补晶振（TCXO），在-40°C到85°C范围内，实际偏差可能达到±50ppm。对于115200bps，这会导致单比特时间偏差高达±4.3ns，10比特累计偏差±43ns。听起来微不足道？但当两个设备都用±50ppm晶振时，相对误差可达±100ppm，即单比特±8.7ns，10比特±87ns。而UART接收器的采样容限，通常只有±1/2比特时间（即±4.34μs）。一旦累积误差超过此值，就会丢帧。

• 规避策略：在产品定型前，务必用高精度频率计，实测你的MCU在工作温度范围内的实际波特率，并在软件中启用“分数波特率发生器（Fractional BRR）”进行微调。STM32的USART_BRR寄存器，其低4位就是用来补偿小数分频的。

5.3 操作系统与缓冲区：应用层的“时间迷雾”

• Windows COM端口的“虚假就绪”：在Windows下，调用WriteFile()后，函数返回成功，只代表数据已进入系统内核缓冲区，并不表示已发送到硬件。GetCommState()查询的cbOutQue字段，才是当前待发字节数。很多开发者误以为WriteFile()返回就万事大吉，结果在高负载时，缓冲区积压导致严重延迟。
• Linuxtcflush()的陷阱：tcflush(fd, TCIOFLUSH)会清空内核的xmit和recv缓冲区，但它不会清空FT231X芯片内部的硬件FIFO！这意味着，你刚清空了软件缓冲，但芯片还在默默发送之前存进去的数据。真正可靠的清空，必须配合FTDI官方提供的FT_Purge()API，或发送特定的USB控制请求。

5.4 一个终极验证清单：你的UART时间计算是否可靠？

在交付任何UART通信功能前，请对着这份清单逐项打钩：

• [ ] 用示波器捕获真实波形，测量单比特宽度，确认与理论值偏差 < ±1%。
• [ ] 测量一整帧（起始+数据+停止）的总时间，确认与理论值一致（允许±1个比特时间的误差，用于接收端采样容限）。
• [ ] 在通信双方都处于最高负载时，测试连续发送1000帧，确认无丢帧、无校验错误。
• [ ] 更换不同品牌、不同长度的USB转串口线缆（特别是FT232R/FT231X），重复上述测试。
• [ ] 将MCU置于高低温箱中（-20°C和60°C），重复测试，确认晶振漂移未导致通信失败。

我个人在实际操作中的体会是：UART看似简单，却是嵌入式系统中最容易“阴沟里翻船”的模块。它不像SPI那样有明确的时钟线，也不像I2C那样有复杂的仲裁机制，它的脆弱性恰恰藏在“简单”二字背后——因为太简单，所以大家都不愿深究。但正是这些被忽略的微秒级细节，构成了稳定可靠通信的基石。下次当你再看到“115200、8N1”这几个字，别再只把它当成一行配置代码。请把它想象成示波器上一段精确到小数点后两位的波形，一段需要你亲手丈量、验证、守护的时间契约。