This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1015319/tda4vm-dmtimer-timer15-accuracy
大家好、我在主域中的 R5内核上使用了10ms 自动重新加载中断模式中的 timer15。 以下是我的设置：
时钟：19200000
中断：10msec
TLDR/TCRR 寄存器值=(0xFFFFFFFF - 192000 +1)
当我在更长的时间内观察中断的累积计时并将其与系统时间(Windows 机器)进行比较时、观察到几百毫秒(~600)的差异？
导致此漂移的可能原因是什么？ 频率完全可以在时间周期上分频！！！！
您好！
我们尚未发现与不准确相关的问题。 那么、您能否提供更多信息？
1、您使用的是哪款 SDK？
2、您使用的是哪种操作系统？ 您是否尝试过使用 BareMetal 代码？
3、如何注册 ISR？ 您能否为中断提供更高的优先级？
4、在这个内核上启用了任何其他中断吗？
此致、
Brijesh
感谢您的回复。 以下是详细信息： 1.我没有使用 SDK
2.我正在使用 Mentor RTOS
ISR 只包含 两个写入操作-清除状态寄存器中的溢出中断标志和一个节拍计数器增量。 定时器在 VIM 中具有最高中断优先级(0)。
4.系统中没有其它中断。
我不确定导致此漂移的原因是什么？ 定时器持续运行(如自动重新加载溢出模式中配置的那样)、这意味着即使中断正在处理、定时器也不处于等待状态并且正在计数。
因此、在某些时间点、我获取到目前为止发生的节拍数(中断)加上当前计时器计数、然后计算时间(将该计数除以频率)。 在这里、我可以看到几百毫秒的漂移在几个小时的时间范围内。
您可以分享您的定时器寄存器值吗？
另外、如何计算/比较当前时间与计时器中断数量？ 您从何处获取当前时间？ 您是否使用了不同的计时器来获取当前计时器？
定时器处于带有溢出中断的自动重新加载模式。 这意味着、如果我们有中断服务、计时器会继续计数。 定时器启动后、它将继续计数、直到它停止。
我使用 python 脚本(timer.pref_counter() API)来测量时间差。 我发送了一个字符的开始/停止序列来指示脚本何时开始计数。 发送1个字符后、I 开始计数中断、在所需的中断数量之后、I 发送停止序列并检查时间差。 我确信 windows+python 不会提供实时计数、但至少它应该在范围内(几毫秒内)、或者它是否比这更坏？
我怀疑基于 pythod 的性能测量。 我真的怀疑计时器是否有任何不准确之处。
您可以使用不同的机制吗？ 假设您是否可以使用 GTC 计时器、在每个 ISR 上获得64位时间戳值并检查两个 ISR 之间的差异？ GTC 在 PSDKLA 和 PSDKRA 中以200MHz 运行、因此您可以计算以 uS/ms 为单位的时间。
Rgds、
