Renesas定时器输入捕获全攻略：原理、配置与实测经验

Renesas 定时器输入捕获：从原理到实测的完整笔记

做嵌入式开发这些年，定时器输入捕获是我用得相当频繁的一个外设模块。测频率、测脉宽、解析遥控信号、做编码器测速，都离不开它。很多朋友用 STM32 玩得很熟，一换到 Renesas（瑞萨）MCU 就有点发懵，因为外设库不同、工具链不同、甚至定时器的工作模式命名也差异很大。这篇文章就围绕 Renesas 定时器输入捕获这一主题，把我实际踩过坑、验证过能跑通的思路梳理出来，尽量做到原理与实操兼顾，方便不同基础的读者直接上手。

需要说明的是，Renesas 的 MCU 家族很多，RL78、RX、RA、RZ 等系列各有差异，但定时器输入捕获的设计思路高度一致，无非是“边沿检测 + 计数器值锁存 + 中断/标志位通知”。我会尽量讲普遍规律，再结合常见系列的配置方式给出可直接参考的步骤。如果你用的是 RA 系列，FSP 配置界面会和你以前用标准外设库的体验完全不同，这部分我也会展开细说。

1. 整体设计思路拆解：为什么输入捕获能测频率

1.1 从需求倒推：测频率、测脉宽的本质是什么

先说清楚输入捕获到底解决了什么问题。我们要测量一个外部信号的频率，或者测量一个脉冲的高电平时间，本质上是在干什么？答案是测量“时间”。怎么用单片机测时间？最朴素的办法是计数器不断累加，计数器的时钟周期是已知的，那么两次事件之间的计数值差值乘以时钟周期，就是时间间隔。

输入捕获模块做的事，就是把这个“时间戳”自动记录下来。外部信号出现指定的边沿（上升沿、下降沿或双边沿）时，硬件会把当前计数器的值立刻锁存到捕获寄存器里，同时触发中断或标志位。CPU 不需要在边沿到来的那一刻精准读计数器——它可能正在处理别的任务，或者被更高优先级的中断打断，来不及读。硬件锁存就保证了时间戳不丢失。

拿测频率来说，思路就非常直接：在连续两个上升沿之间，计数器走了多少个 tick，这个 tick 数对应的就是信号的周期。周期取倒数就是频率。这里的关键不是单纯看寄存器读到了什么，而是要知道计数器每 tick 到底对应多长时间。这就需要搞清楚定时器的时钟源、分频系数、计数模式这些前置参数。

1.2 为什么选输入捕获而不是外部中断

有的朋友可能会说，我用外部中断（EXTI）也能测频率——每次边沿进中断，读一下计时器。这个方案在低频信号下可行，但在高频信号下很容易翻车。

外部中断方案的问题在于，中断响应是有延迟的。从硬件检测到边沿，到 CPU 真正执行到读计数器的指令，中间可能隔着几十到几百个 CPU 周期。如果中断里还要做别的事，比如处理协议解析、驱动 LED，那么实际的“读时刻”会比真实的边沿时刻晚一截。更麻烦的是，这段延迟往往是抖动不定的，测量结果就会出现明显的噪声。

输入捕获则把“检测边沿”和“读计数器”这个过程全部交给硬件，CPU 零参与。边沿一到，计数器值瞬间锁存到寄存器，软件只需要在中断里把寄存器读走就行。这样测量精度完全取决于计数时钟的分辨率，而不受中断延迟抖动的影响。对于测量频率和脉宽这种实时性敏感的任务，输入捕获是更合理的选择。

1.3 Renesas 定时器输入捕获的应用场景

具体到 Renesas MCU 上，输入捕获的典型应用我整理了几类，覆盖了工控和消费电子里常见的需求：

• 频率测量：例如测量 PWM 输出频率、传感器输出的脉冲频率，或者电网频率监测，通过捕获连续两个边沿的时间差算周期。
• 脉宽测量：测量高电平时间、低电平时间，常用于解析遥控信号、读取占空比信号。
• 编码器测速：有些系列的支持模块可以直接配合正交编码器，但简单的测速也可以用输入捕获完成——每个脉冲捕获一次，根据脉冲间隔算速度。
• 时间戳记录：比如记录某个事件发生的精确时刻，用于多通道同步测量、故障记录等。

这三种应用场景背后都是同一套外设机制，差异只在于中断里如何计算和处理时间戳。后面我会分别给出具体的处理逻辑。

2. 核心原理与配置要点：Renesas 定时器输入捕获的关键细节

2.1 计数器的时钟、分频与溢出：所有计算的基础

讨论输入捕获之前，必须先把计数器的时钟树理清楚。Renesas 定时器模块通常有一个内部时钟源，经过分频后驱动计数器不断递增或递减。假设输入时钟频率为 PCLK（外设时钟），预分频系数为 P，那么计数器每 tick 的时间就是：

t_tick = P / PCLK

举例来说，如果 PCLK 是 48 MHz，预分频设为 64，那么每个 tick 对应的真实时间是 64 / 48000000 ≈ 1.333 微秒。这个分辨率决定了频率测量的精度能到什么程度。

测量一个 1 kHz 方波信号时，周期是 1 毫秒，相当于 750 个 tick。如果我们用计数器测量两个上升沿之间的 tick 数，测到 750，那么计算出的频率就是 1 / (750 × 1.333 μs) ≈ 1000.1 Hz。误差来源在于边界上的量化误差：真实的边沿时刻不一定正好落在 tick 的整数倍上，最多偏差一个 tick。因此 tick 时间越短，量化误差越小，测量精度越高。

这里有一个容易忽略的问题：计数器溢出。如果信号的周期很长，计数器的位宽有限（16 位计数器的最大值是 65535），那么在两个边沿之间计数器可能已经溢出回零了。如果忽略溢出，计算出的时间间隔就会比实际值小一大截。解决办法是在捕获中断里同时检查溢出中断标志，把溢出的次数记录下来，再用总 tick 数 = 溢出次数 × 计数器周期 + 本次捕获值 - 上次捕获值 来还原真实时间。上面这条公式务必牢记，这是所有低频测频都会遇到的坑。

2.2 边沿检测与捕获源选择：上升沿、下降沿还是双边沿

输入捕获的第一步是告诉硬件“什么样的事件算一次捕获”。Renesas 定时器通常支持上升沿捕获、下降沿捕获，或者双边沿捕获。对于测频率，建议使用同一边沿（比如都是上升沿），这样每次捕获的参考点一致，计算结果就是信号的完整周期。

对于测脉宽，则要用双边沿捕获：在上升沿记录第一次时间戳，在下降沿记录第二次时间戳，两者之差就是高电平宽度。注意，这里涉及到一个常见的配置细节：有些系列的定时器有多个捕获通道，每个通道可以独立选择触发边沿；有些系列则会在同一个通道内通过寄存器配置边沿极性。Renesas 的 GPT（通用 PWM 定时器）和 MTU（多功能定时器脉冲单元）就属于前者，不同通道可以配不同边沿，这给脉宽测量提供了便利——通道 A 捕获上升沿，通道 B 捕获下降沿，或者在同一通道上交替捕获两次边沿。

我个人的习惯是优先使用同一边沿测频率、双边沿测脉宽，原因很简单：双边沿模式下，两次捕获之间的间隔就是高电平宽度或低电平宽度，不需要额外区分上升沿和下降沿再相减。但要注意，如果在中断里同时处理上升沿和下降沿，必须通过标志位确认当前触发的是哪个边沿，否则数据会错位。

2.3 中断设计原则：如何处理“捕获值被覆盖”的问题

输入捕获通常会配套一个捕获中断。捕获事件发生时，硬件把计数器值写入捕获寄存器，同时拉高中断请求。CPU 在中断服务函数里读取捕获值，并将它保存到变量中。

这里非常容易踩的一个坑是：两次捕获事件之间的时间如果小于中断响应时间，第二次捕获值会覆盖第一次捕获值，导致第一次数据丢失。解决思路有两个方向：

• 方向一：提高中断优先级，确保捕获中断尽快执行。适用于捕获频率不算太高的场景。
• 方向二：如果是高频信号，考虑使用 DMA 把捕获值批量搬运到内存，或者改用硬件 FIFO。Renesas 有些系列的定时器支持多事件捕获，把多次捕获结果存在硬件缓冲里，这是高频测量最稳的路径。

从我实际项目的经验来看，频率在几十 kHz 以内的信号，普通中断处理完全够用；到了几百 kHz 甚至 MHz 级别，就要上 DMA 或者专门的捕获缓冲了。

2.4 与 PWM 中心对齐模式、ADC 采样触发的联动

在基于 Renesas 的电机控制和电源类项目中，定时器的使用往往不仅是测频率，还要同步产生 PWM 和控制 ADC 采样时刻。很多朋友搜索“stm32 高级定时器 pwm 中心对齐模式和 adc 采样时刻点设置”其实就是因为不了解中心对齐模式下的计数方向变化。

中心对齐模式（Center-Aligned Mode）下，计数器先从 0 递增到周期值，再从周期值递减到 0，形成三角波。PWM 输出在递增段和递减段的比较匹配点位置不同，但输出效果是中心对齐的。在这个模式下，ADC 采样的时刻点设置必须明确自己到底想采“波峰”还是“波谷”附近的电流。常见做法是利用定时器的事件触发信号（比如比较匹配事件或周期事件）来触发 ADC。相比之下，上升计数模式下，计数器从 0 开始递增，比较匹配和周期事件的时序是单向明确的；中心对齐模式下要特别注意事件触发的时机究竟对应的是递增段还是递减段。

不过这里要提示一下：Renesas 的 GPT 和 STM32 高级定时器在中心对齐模式下的事件触发行为有所不同。GPT 在配置事件触发输出时，可以指定“在计数器递增匹配”、“在计数器递减匹配”或两者都触发。实际使用时，如果我们希望 ADC 在 PWM 开通中点采样，通常选择递增段的比较匹配事件；如果我们希望 ADC 在 PWM 关断中点采样，则选择递减段的比较匹配事件。这个细节非常容易搞混，我在项目里调试时为此反复看过波形才彻底弄明白。

3. 实操过程：用 Renesas e² studio 配置定时器输入捕获并测频率

3.1 准备工作：确认芯片型号与开发环境

瑞萨目前主流的开发环境是 e² studio，配合 FSP（Flexible Software Package）配置工具，用于 RA 系列；RL78 和 RX 系列则常使用 CS+ 或者 e² studio 配合 Code Generator / Smart Configurator。这里我用 RA 系列举例说明，因为 FSP 的图形化配置比较直观，也方便上手。如果你用的是 RL78，别急，后文我会补充说明 Code Generator 里的配置差异。

需要的准备工作有：

• 一块 Renesas RA 系列开发板，推荐 RA2A1 或 RA4M1 这类常见型号。
• e² studio 开发环境，建议使用较新版本。
• FSP 配置工具（通常集成在 e² studio 中）。
• 一个可以输出方波信号的信号源，可以是另一块 MCU 的 PWM 输出、函数信号发生器，或者 555 定时器组成的脉冲发生器。

硬件连接上，把信号源的输出引脚连接到开发板定时器输入捕获通道对应的引脚上。不同开发板的引脚定义不同，可以在 FSP 里查看定时器通道对应的可选引脚。以 RA 系列 GPT 为例，GPT0 的输入捕获引脚通常标记为 GTGTRG0/GTIOC0A 等，具体以板卡用户手册为准。如果信号源的电压和 MCU 工作电压不一致，必须加电平转换或分压电路，否则可能烧毁引脚。

3.2 FSP 配置定时器：一步步设置输入捕获功能

打开 FSP 配置界面后，找到定时器（Timer）模块，添加一个 GPT 定时器实例。这里以 GPT0 为例进行配置。

配置项大致如下：

• 模式（Mode）：选择“PWM”之外的“Input Capture”模式，RA 系列 FSP 里可能显示为“Input Capture”或“Timer Mode”。
• 通道（Channel）：选择你接信号的那个 GPT 通道。
• 计数模式（Count Mode）：通常选择“Up”递增计数。递增计数模式下，计数器从 0 开始逐步递增，到达周期值后产生溢出事件并回 0。递增模式比较容易理解，也方便计算时间。
• 周期（Period）：建议设置为计数器的最大值（比如 0xFFFF），或者根据你要测的信号频率设置一个合适的周期，使得计数器在两次边沿之间尽量不溢出。如果信号频率很低，可以把周期设到最大，并在溢出中断里做溢出计数。
• 输入捕获源（Input Capture Source）：指定哪个引脚输入，以及捕获边沿极性。这里通常有“Rising Edge”（上升沿）、“Falling Edge”（下降沿）、“Both Edges”（双边沿）等选项。
• 中断使能：开启捕获中断（Capture Interrupt）和溢出中断（Overflow Interrupt），并在 FSP 里生成对应回调函数。

以上是 RA 系列的 FSP 配置方式。如果你用的是 RL78 系列，流程也类似：在 Code Generator 里选择定时器单元，设置为脉冲间隔测量模式，选择有效沿，使能中断，生成代码即可。底层寄存器操作虽然不同，但配置项的逻辑本质是一样的：选时钟源、设分频、选边沿、开中断。

3.3 代码实现：中断回调中计算频率

FSP 生成代码后，我们在用户代码里实现回调函数。以 RA 系列为例，FSP 会生成一个回调函数，在捕获中断触发时被调用。我在回调函数里维护一个捕获值数组，并记录溢出次数，然后在主循环或更高层模块中完成频率计算。

简单来说，中断里的核心逻辑是：

// 捕获中断回调示例 volatile uint32_t g_capture_value = 0; volatile uint32_t g_overflow_count = 0; volatile uint32_t g_capture_flag = 0; void gpt0_callback(timer_callback_args_t *p_args) { if (p_args->event == TIMER_EVENT_CAPTURE_A) { g_capture_value = p_args->capture_a; // 读取捕获值 g_capture_flag = 1; } else if (p_args->event == TIMER_EVENT_OVERFLOW) { g_overflow_count++; // 溢出计数 } }

再看主循环里的频率计算逻辑：

// 第 N 次捕获时计算频率 // 需根据两次捕获值差值和溢出次数还原 tick 数 // tick_per_second 由定时器时钟频率和分频决定 #define TICKS_PER_SECOND 1000000 // 示例值：1 MHz 计数频率 double calculate_frequency(uint32_t prev_capture, uint32_t curr_capture, uint32_t overflow_count, uint32_t counter_max) { uint32_t total_ticks = overflow_count * (counter_max + 1) + curr_capture - prev_capture; double period_sec = (double)total_ticks / (double)TICKS_PER_SECOND; return 1.0 / period_sec; }

注意：TICKS_PER_SECOND要根据实际配置的定时器时钟和预分频系数换算。假设定时器时钟为 48 MHz、预分频为 48，那么计数频率为 1 MHz，每个 tick 为 1 μs，此时TICKS_PER_SECOND就是 1000000。如果信号频率太高，tick 数太少，频率测量精度就会下降，此时可以降低预分频系数来提高分辨率。

先写一个基础版本，再考虑优化。优化方向包括：使用环形缓冲区存储多次捕获值，用于实时计算频率和占空比；在捕获中断中直接完成周期计算，减少上层模块的负担；或者通过 DMA 实现无中断高频捕获。这些我都会在后面的常见问题部分展开说。

3.4 参数选择：如何根据被测信号设置预分频和计数器周期

理论再好，不会选参数也白搭。这里我提供一个可操作的选择流程，我自己在项目里就是这么做的。

先估算被测信号的频率范围。假如我们测的是 1 kHz 到 10 kHz 的方波信号，那么周期范围是 100 μs 到 1 ms。我们希望一个周期内至少有几百个 tick，这样量化误差在 1% 以内甚至更小。

假设定时器时钟是 48 MHz，如果不用预分频，1 个 tick 约为 0.0208 μs，1 kHz 信号一个周期有 48000 个 tick，分辨率极高。但如果计数器是 16 位，65535 个 tick 的满量程只对应 65535 × 0.0208 μs ≈ 1.365 ms。对于低于约 733 Hz 的信号，16 位计数器会溢出。这时候就要要么开启溢出中断做溢出计数，要么增大预分频降低计数频率，换取更长的最大可测周期。

举个例子，如果把预分频设为 48，计数频率降到 1 MHz，16 位计数器满量程是 65535 μs ≈ 65.5 ms，最低可测频率约为 15.26 Hz。分辨率上，1 tick 对应 1 μs，测 1 kHz 信号时有 1000 个 tick，量化误差约 0.1%，大多数应用都能接受。用这个组合来兼顾低频覆盖和中频分辨率是比较均衡的方案。如果你需要同时测高频率（比如 100 kHz 以上），可以考虑使用 32 位计数器模式，或者动态切换分频——但动态切换分频在代码里要处理时间基准切换，复杂度高，我建议普通项目固定一个分频反而更稳，然后把测量的频率上限控制在合理的范围内。

对了，还要提到一个细节：很多 Renesas 定时器支持“自由运行计数器”模式和“周期受限计数”模式。自由运行下计数器持续递增到最大值后回零；周期受限则到一个指定值就回零。如果使用的是周期受限模式，计算总 tick 时要把“回零点”换成周期值，而不是计数器最大值，否则误差会很大。这也是我踩过的坑。

3.5 完整示例：用输入捕获测量 PWM 的频率和占空比

测频率和测占空比这两件事，在输入捕获里其实是同一个套路，只是处理方式稍有不同。最常用的方法是配置同一个通道为双边沿捕获，在上升沿和下降沿都产生捕获中断。

假设我们先捕获到上升沿，记下计数值 prev_capture；下一次捕获是下降沿，记下 curr_capture1，那么高电平时间 tick 数就是 curr_capture1 - prev_capture。再下一次捕获是上升沿，记下 curr_capture2，此时从 prev_capture 到 curr_capture2 的 tick 数就是一个完整周期。占空比等于高电平 tick 数除以周期 tick 数。

中断实现逻辑：

// 双边沿捕获计算频率和占空比 volatile uint32_t rising_capture = 0; volatile uint32_t falling_capture = 0; volatile uint32_t period_ticks = 0; volatile uint32_t high_ticks = 0; volatile uint8_t capture_state = 0; // 0: 等待上升沿, 1: 已捕获上升沿 void gpt_callback(timer_callback_args_t *p_args) { if (p_args->event == TIMER_EVENT_CAPTURE_A) { if (capture_state == 0) { rising_capture = p_args->capture_a; capture_state = 1; } else { falling_capture = p_args->capture_a; high_ticks = falling_capture - rising_capture; period_ticks = falling_capture - rising_capture; // 第一次先计算高电平，周期暂存 // 这里实际上需要记录上次上升沿，才能计算完整周期 if (prev_rising_capture_valid) { period_ticks = rising_capture - prev_rising_capture; } prev_rising_capture = rising_capture; prev_rising_capture_valid = 1; capture_state = 0; measurement_done = 1; } } }

上面这段代码我故意把“周期计算”和“高电平计算”分开写，方便你理解。严格来说，占空比计算需要三个相邻边沿：上升沿 t1、下降沿 t2、上升沿 t3。高电平时间 = t2 - t1，周期 = t3 - t1。所以要在中断里保存上一次的上升沿 capture 值，下一次上升沿到来时才能算出完整周期。这个状态机的写法，很多初学者容易搞混，我给一个在实际工程中验证过的简化版本。

更简化的做法是：用两个通道，通道 A 捕获上升沿，通道 B 捕获下降沿，这样中断里拿到的 capture 值天然对应不同边沿，省去状态判断。Renesas GPT 通常支持多通道，这种“双通道分工”的方案我比较推荐，尤其适合信号频率较高、中断时间比较紧的场景。

4. 常见问题与排查技巧实录

4.1 捕获值一直为零或不变

遇到这种问题，先别急着改代码。大概率是输入引脚配置不对，或者信号根本没有到达定时器模块。

排查顺序如下：

• 第一步，用示波器或万用表确认信号源确实有输出，且电平符合 MCU 引脚容忍范围。
• 第二步，检查 FSP 里定时器通道对应的引脚是否被复用为其他功能，或者没有设置为输入模式。
• 第三步，确认捕获边沿极性设置正确——如果你的信号空闲为高电平、脉冲为低电平，但你配置的是下降沿，那捕获事件会突然大量触发，而不是稳定捕获。
• 第四步，检查定时器时钟是否已启动。有些情况下，定时器时钟默认是关闭的，需要在代码里先用打开定时器的接口启动计数。

我遇到过最隐蔽的问题是：信号源输出的 PWM 占空比是 0% 或 100%，即引脚始终为低电平或高电平。此时永远不会出现有效的捕获边沿。这个问题在调试时特别容易忽略。

4.2 捕获数据抖动大、测频不准

测量结果不稳定，很多时候不是硬件问题，而是计算方式有问题。最常见的是溢出计数没处理好，或者两次捕获之间的差值跨越了计数器的回零点。

举个例子，16 位计数器从 0xFFF0 计数到 0x0010，如果直接计算 0x0010 - 0xFFF0，得到的值是负数或者一个非常大的数（取决于数据类型）。正确的处理方式是利用无符号整数回绕特性：

uint32_t diff = (uint32_t)(current_capture - prev_capture);

只要保证差值小于 2^31，无符号减法会自动处理回绕问题。这是 C 语言中利用无符号数回绕特性的常规技巧，也是嵌入式领域计算时间差的标准做法。如果差值可能超过 2^31，那就必须先处理溢出计数。

此外，如果信号本身带有噪声，边沿检测可能出现抖动，也就是在真实边沿前后多次触发捕获。这种情况下捕获数据会偶尔出现明显偏离。解决方法是在硬件上加入 RC 滤波，或者在软件里加入“最小间隔判断”逻辑：如果两次捕获间隔小于某个阈值，就忽略后一次捕获。阈值可以设置为信号最小周期的 1/4 左右。

4.3 中断响应不过来导致捕获值被覆盖

当被测信号频率非常高时，捕获中断的触发频率也会变得很高。如果中断服务函数里做的事情太多（比如浮点运算、printf 打印、函数调用），CPU 可能来不及在下一次捕获事件到来之前完成中断处理，造成捕获寄存器被新数据覆盖。

解决方案有几个：

• 方案一：在中断服务函数里只做最少的操作——把捕获值存入局部变量或直接塞入全局数组，不做浮点计算、不做打印。
• 方案二：用 DMA 自动搬运捕获值。Renesas GPT 支持通过 DMA 在捕获事件发生时自动读取捕获寄存器并写入内存，这样 CPU 只需要处理 DMA 完成中断，捕获过程 CPU 几乎零负担。实测下来，用 DMA 可以很轻松支持几百 kHz 级别的输入捕获。
• 方案三：拉高捕获中断优先级，确保它不会被其他中断长时阻塞。

我在一个项目里测一个约 200 kHz 的脉冲信号，普通中断方式出现了偶发丢数，改成 DMA 方案后就稳定了，这算是我实测过的一个分水岭。

4.4 占空比测量不准，尤其是接近 0% 或 100% 时

这个问题在 PWM 波测量中很典型。如果信号的占空比是 99%，高电平时间很长，低电平时间很短。你的捕获逻辑如果只在低电平跳变时更新测量值，那可能出现长时间没有更新、数值保持旧值的情况。

解决办法是：不仅做占空比计算，还要在每次捕获中断里都更新“最后一次捕获时间”。如果超过预设的超时时间没有新的捕获事件，就要认为信号占空比接近 0% 或 100%，并给出相应的边界值。比如高电平时间超时就认为占空比为 100%，低电平时间超时就认为占空比为 0%。这个超时逻辑在遥控信号解码、PWM 信号质量检测里基本是标配。

另外，如果捕获源选择的是双边沿，且信号占空比接近 100%，那下降沿和下一次上升沿之间的间隔可能非常短，短到只有几个 tick，此时量化误差会显著影响占空比精度。要缓解这个问题，可以考虑提高计数频率（降低预分频），或者在信号条件允许的情况下，改为测量低电平时间再换算占空比——哪个小测哪个，再切换测量对象。

4.5 用 555 定时器和信号发生器做输入捕获实验的注意事项

如果你出于学习目的搭建实验环境，用 555 定时器产生方波给 MCU 输入捕获，这是非常经典的组合，但在实验时有几个点和使用信号发生器不同：

• 555 定时器输出的频率受电阻电容精度影响很大，最好先用示波器或频率计校准一下实际输出频率，再和单片机测量的结果对比，避免误会单片机测错了。
• 555 定时器输出信号的边沿不是特别陡峭，如果走线较长，可能触发捕获不稳定。建议缩短连接线，或者在 MCU 输入引脚附近加一个上拉电阻。
• 信号发生器的输出阻抗通常是 50 欧姆，驱动 MCU 引脚没什么问题。但有些开发板的输入引脚已经接了较大下拉电阻，可能分压导致电平达不到阈值，测量结果就会异常。

5. 进阶扩展：从单一输入捕获到多通道协同测量

5.1 多通道测占空比与相位差

如果只测一个信号的频率和占空比，单个通道就够了。但实际项目中经常要同时测多路信号的频率，或者测量两路信号的相位差。Renesas 定时常支持多通道独立捕获，配置多个通道十分方便。

以测量相位差为例：两路频率相同的方波信号，分别接入 GPT0 和 GPT1 的捕获通道。基准信号上升沿到来时，记录 GPT0 的捕获值 t1；另一路信号上升沿到来时，记录 GPT1 的捕获值 t2。相位差就是 (t2 - t1) / 周期 × 360°。这里要求两个定时器的计数时钟同源、复位同步，配置时把两个通道配置成相同的时钟源和计数周期，这样两个通道的 tick 值在时间上具有可比性。

这个思路在电机控制里经常用来测量编码器两路信号的相位差，间接判断转动方向。不过要注意，如果你的应用里相位差可能超过一个完整周期，就需要额外记录周期数和方向，否则会计算出错误的角度。

5.2 在定时器中断里触发 ADC 采样

在电机控制、数字电源这类实时控制应用里，通常希望 PWM 周期中的特定时刻采样电流或电压。Renesas GPT 定时器可以配置为在比较匹配事件或周期事件时产生触发信号，这个触发送给 ADC 作为硬件启动条件。这样省去了 CPU 软件触发 ADC 的开销，且采样时刻与 PWM 输出严格同步，重复性好。

以中心对齐模式 PWM 为例，如果我们配置比较匹配事件在“计数器递增到某个值”时发生，那么该事件对应的采样点就在 PWM 周期的某个固定相位。用这个方式，可以实现“在 PWM 波峰采样”或“在 PWM 波谷采样”，完全由比较值决定。这一点我认为比 STM32 的中央对齐模式更直观，因为 Renesas GPT 的事件触发源可以在递增匹配和递减匹配之间分别选择。

5.3 用 DMA 实现高频信号的无中断捕获

前面提过用 DMA 搬运捕获值，这里给一个更详细的思路。把 DMA 配置为“外设到内存”传输，触发源选择定时器捕获事件。每当捕获事件发生时，DMA 自动把捕获寄存器值搬到一个数组里。DMA 传满预设数量后触发完成中断，CPU 在完成中断中统一处理这批数据。

这个方案的优点是 CPU 几乎不参与捕获过程，捕获时间戳由硬件保证，频率再高也不会丢数。缺点是实现相对复杂，需要配置 DMA 的源地址、目的地址、传输宽度和触发源，并且要处理 buffer 翻转（双缓冲或环形缓冲）。好在 FSP 已经封装了不少 DMA 相关的配置项，图形化界面里勾选就可以，代码里只需处理传输完成回调。

如果像我一样习惯用“先跑通功能再看优化”，建议先确保普通中断方式已经能够正确计算频率和占空比，然后再尝试 DMA 改造。因为 DMA 模式下，一旦配置错误，现象往往是不更新或者乱跳，排查起来远比中断方式麻烦。先把功能基线稳住，再优化性能，这是嵌入式调试的通用心法。

6. 写在最后的经验总结

定时器输入捕获这个功能，说起来不外乎“边沿检测 + 硬件锁存计数 + 中断通知”三件事，但真要在某个具体芯片上稳定跑起来，需要关注的点还是很多的。时钟分频怎么选、溢出怎么处理、中断里做什么不做什么、边沿极性怎么配置，这些细节都会直接影响测量结果。个人经验是，遇到问题不要急着改代码，先拿示波器看信号，确认硬件上确实有干净、稳定的边沿，再回头检查软件逻辑。很多“测量不准”的案例，最后都发现是信号本身质量差，而不是定时器配置错了。

如果你是刚从 STM32 转到 Renesas 平台，建议先用 FSP 的图形化配置跑通一个最简单的测频 demo，打印出频率值，感受一下 GPT 的工作方式，再逐步增加复杂度。Renesas 定时器的功能比想象中要强，但外设命名和库函数的抽象层次和 STM32 标准库差异挺大，多花点时间熟悉数据手册和生成代码，后面会顺畅很多。如果遇到具体配置问题，优先去看该系列的用户手册里定时器章节的时序图，很多模糊的细节对着时序图一看就明白了。

另外再分享一个小技巧：在调试输入捕获时，可以在中断服务函数里临时加一个 GPIO 翻转，用示波器看中断里的执行时间。如果翻转间隔不稳定，说明中断负载或信号抖动确实存在问题。这个技巧在我之前的项目中帮了大忙，一度排查出是信号源的占空比抖动，不是定时器配置的问题。希望这篇内容能帮你在 Renesas 定时器输入捕获的路上少走一些弯路。