HAL_TIM_IC_CaptureCallback中断好像不是每次都能进去。

最近用STM32的一个芯片测PWM输入，发现频率有的时候不对，原因是HAL_TIM_IC_CaptureCallback函数里测量的上升沿之间间隔和上升沿下降沿之间间隔，发现有的时候丢了一个上升沿或者下降沿。将这个定时器的优先级该成0，状况好点，但是还出错。输入频率是10000Hz的时候，__HAL_TIM_GetCounter函数测的值，比HAL_TIM_ReadCapturedValue要多2个，即使__HAL_TIM_GetCounter放到前面。
我用的是TIM10和TIM13分别做两路PWM输入捕获，每个定时器都是先测上升沿，之后再测下降沿，再测上升沿的方式，来计算频率和占空比。请各位版主和大佬帮看看，谢谢！@香水城, 呐咯密密, 小叶三千, STM新闻官, lihui567

发生捕获事件时 是硬件将counter值放到ccr寄存器，比你基于中断去读要更快捷点。
另外，你觉得没进入捕获中断，可能是你的代码没区别开来，主要是当两个捕获事件发生太近，代码处理有点冗长时。

基于定时器捕获测量脉宽的应用示例

香水城 发表于 2024-7-4 22:02
发生捕获事件时 是硬件将counter值放到ccr寄存器，比你基于中断去读要更快捷点。
基于定时器捕获测量脉宽的 ...

谢谢香版！还好这个捕获中断是偶尔进不去，今天我在软件上加了点判断，在实时性要求不太高的时候是可以避免的。你发的这个我仔细研究下。

配置有误

是否有硬件故障

中断处理延迟

如果你使用多个定时器（如TIM10和TIM13），确保它们之间没有同步问题。两个定时器可能需要共享时钟源或同步配置，以避免时间偏移导致的数据捕获错误。

中断嵌套太多了，导致的有时候会延迟一些时间才到达处理函数。

说的是那个函数嵌套太多。sorry。

虽然将定时器的优先级设置为 0 可以使其优先处理，但如果定时器中断频率很高，可能会影响其他中断的处理

过期的塔头 发表于 2024-7-30 15:02
如果你使用多个定时器（如TIM10和TIM13），确保它们之间没有同步问题。两个定时器可能需要共享时钟源或同步 ...

谢谢，我用软件解决了，就是频率变化不快的时候，两次的上升沿之间差一致才算，不一致就丢了。定时器同步好像FPGA里有这个，我没太关注ST的这方面。

mintspring 发表于 2024-7-30 15:50
说的是那个函数嵌套太多。sorry。

我今天只判断频率，就是不用捕获下降沿，频率是没问题的。应该是上升沿下降沿来回切换，频率高了来不及捕获。

jcky001 发表于 2024-7-9 20:00
是否有硬件故障

谢谢，没有硬件故障的。

cr315 发表于 2024-7-9 11:15
配置有误

应该是信号沿来回切换，来不及捕获。

两只袜子 发表于 2024-7-10 11:00
中断处理延迟

谢谢，应该是信号沿来回切换，来不及捕获。

很好的问题，其实软件层面确实会有这个问题

将这个定时器的优先级该成0，状况好点，但是还出错

有的时候丢了一个上升沿或者下降沿

用的是TIM10和TIM13分别做两路

HAL_TIM_IC_CaptureCallback函数里测量的上升沿之间间隔和上升沿下降沿之间间隔