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.

[参考译文] AM625:计算 PWM 输入信号频率时计时器读数不一致

Guru**** 2871710 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/clock-timing-group/clock-and-timing/f/clock-timing-forum/1634894/am625-inconsistent-timer-readings-when-calculating-frequency-of-a-pwm-input-signal

器件型号: AM625

你好

我使用计时器 MCU_TIMER1 并使用寄存器 DMTIMER1MS_TCAR1 (0481 0050h) 和 DMTIMER1MS_TCAR2 (0481 0058h) 来计算 PWM 信号的频率。 它旨在获得 3Hz 至 10kHz 范围内的信号频率。

我们实现信号频率计算的方式如下:

1.设置 INPUT_CLOCK_Hz = 25000000
2.读取 TCAR1 的计时器捕获值并存储在 TCAR1_VALUE 中
3.读取 TCAR2 的计时器捕捉值并存储在 TCAR2_value 中
4. calculate measured_ticks = TCAR2_value - TCAR1_value
5.计算频率= input_clock_Hz/ measured_ticks
 
对于大多数频率范围、读数都正确、+/- 1Hz。 但是、对于低频(主要是 45Hz 或更低)、计时器读数不一致、导致频率值错误、有时甚至读取 TCAR2_value < TCAR1_value、从而导致 measured_tick 下溢。
 
是否 有任何关于低频计时器读数的信息?
 
谢谢

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    我现在将此事转告有关专家、请预计由于专家离职、答复会有所延迟。

    此致、

    会面。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    如果您使用的是 MCU_Timer1、那么您应该从此外设的寄存器中读取吗?

    例如、我看到您提到了一些地址、即  DMTIMER1MS_TCAR1 (0481 0050h) 和 DMTIMER1MS_TCAR2 (0481 0058h)。

    但它应如下所示:  突出显示的消息所示

    如果我错误地解释了某些内容、请告诉我。

    期待您的答复。

    此致、

    Vaibhav

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    仅供参考、如果此常见问题解答有用: e2e.ti.com/.../faq-processor-sdk-am64x-how-to-create-a-pwm-using-a-timer

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好:

    我正在根据给定的脚本处理这个主题、因此如果我遇到问题、我会道歉。

    我们使用以下参数:

    TIMER_INPUT_CLOCK_HZ=25000000
    REG_SIZE=32
    CFG_TCLR_REG=0x4810038
    CFG_TCAR1_REG=0x4810050
    CFG_TCAR2_REG=0x4810058
    IRQSTATUS_REG=0x04810028
    IRQSTATUS_SET_REG=0x481002C
    MCU_SPI0_CS1_PIN_REG=0x4084004
    
    AR_VALUE=1 # Auto reload mode
    PTV_VALUE=0 # Prescaler Trigger Value
    PRE_VALUE=0 # Prescaler Enable
    TCM_VALUE=1 # Capture of rising edge
    CAPT_MODE=1 # Capture input mode
    GPO_CFG_VALUE=1
    
    TCLR_REG_VALUE=(({AR_VALUE} << 1 | {PTV_VALUE} << 4 | {PRE_VALUE} << 5 | {TCM_VALUE} << 9 | {CAPT_MODE} << 13 | {GPO_CFG_VALUE} << 14))
    busybox devmem {CFG_TCLR_REG} {REG_SIZE} {TCLR_REG_VALUE}

    我尝试使用计时器来计算信号的频率。

    ```μ s

    #清除捕获中断请求
    Busybox devmem ${IRQSTATUS_REG}${REG_SIZE}0x04

    #读取计时器捕捉值
    TCAR1_VALUE=$(busybox devmem ${CFG_TCAR1_REG}${REG_SIZE})
    TCAR2_VALUE=$(busybox devmem ${CFG_TCAR2_REG}${REG_SIZE})
    measured_ticks=$(( TCAR2_value - TCAR1_value ))

    #计算频率
    ENGINE_STATE_FREQ=$(${TIMER_INPUT_CLOCK_Hz}/${measured_ticks})

    ```μ s

    这种方法适用于大多数频率、频率为+/–1Hz、但如果信号频率较低(45Hz 或更低)、这种方法会给出一些不一致的值。

    下面是一个示例、我们尝试读取 30Hz。

    0481 0050h 是用于这种情况的正确计时器、还是有另一个更正确的计时器?

    感谢您的关注、

    Francisco

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    您能告诉我是否使用 Linux SDK 吗?

    此致、

    Vaibhav

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好:

    是的、Linux、Apertis Pro

    此致、

    Francisco

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、

    我已将该线程重新分配给正确的专家。

    此致、

    Vaibhav

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Francisco、

    若要确认、TCAR1 的寄存器地址 0x04810050 和 TCAR2 的寄存器地址 0x04810058 对于 MCU_Timer1 是正确的。 这不是问题的根源。

    低频率不一致是软件同步问题。 您的脚本会在开始时清除捕获中断标志、但随后立即读取 TCAR1 和 TCAR2、而无需等待下一个捕获周期完成。 在高频率下、这会被忽视、因为硬件捕获新边缘的速度比软件读取寄存器的速度快。 在低频率下、情况恰恰相反、您的软件在下一个边沿到达之前读取这两个寄存器、因此 TCAR2 仍保留上一个捕获周期的值。 由于该值比 TCAR1 旧、因此您会得到 TCAR2 < TCAR1、这会导致下溢和您在输出中看到的频率值错误。

    修复方法是使用捕获中断标志 (IRQSTATUS 中的 TCAR_IT_FLAG 位 2) 作为同步机制。 更正后的顺序应为:

    1. 清除 IRQSTATUS 中的捕获中断标志
    2. 轮询 IRQSTATUS 并等待直到设置捕获标志—这确认硬件已完成一个新的捕获对
    3. 仅在这时读取 TCAR1 和 TCAR2
    4. 计算差值并计算频率

    这可以确保每次读取 TCAR1 和 TCAR2 都会反映一个全新且有效的连续捕获对、无论输入频率有多低。

    此致、
    Harshith

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好:

    这项建议有效,谢谢!

    此致、

    Francisco