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.

[参考译文] CC2640R2F:计时器不准确

Guru**** 2625255 points

Other Parts Discussed in Thread: CC2642R, SIMPLELINK-CC13XX-CC26XX-SDK, SYSCONFIG, SIMPLELINK-CC2640R2-SDK

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1066983/cc2640r2f-timer-is-not-accurate

部件号:CC2640R2F
“线程”中讨论的其他部件:测试CC2642RSIMPLELINK-CC13XX-CC26XX-SDKsysconfigSIMPLELINK-CC2640R2-SDK

大家好,团队

客户提出的问题可能需要您的帮助:

使用计时器在回叫功能中将100us 设置为水平翻转。 测量的时间不是100 us。 cc2642r 测试准确无误。 (黄色为2642r,蓝色为2640):

相同的翻转功能。 黄色 CH1主控制器,蓝色 CH2从控制器,主机100us:

1 ms 也不是很准确:

问题:

 2640r2f 计时器的最小精度是多少? 还是代码有什么问题?

2.在哪里可以发现2640r2f 使用48M 24M 乘数?

void timerCallback(GPTimerCC26XX_Handle handle, GPTimerCC26XX_IntMask interruptMask)
{
//    syn_t_count++;
//    GPIO_toggle(IOID_0);
    GPIO_toggleDio(EEG_BOARD_UART_TX);
    // interrupt callback code goes here. Minimize processing in interrupt.
}
void Timer_Init(void)
{
  GPTimerCC26XX_Params params;
  GPTimerCC26XX_Params_init(&params);
  params.width          = GPT_CONFIG_16BIT;
  params.mode           = GPT_MODE_PERIODIC;
  params.direction      = GPTimerCC26XX_DIRECTION_UP;
  params.debugStallMode = GPTimerCC26XX_DEBUG_STALL_OFF;
  hTimer = GPTimerCC26XX_open(EEG_BOARD_GPTIMER1B, &params);
  if(hTimer == NULL) {

//    Task_exit();
  }
  Types_FreqHz  freq;
  BIOS_getCpuFreq(&freq);//48000 000
  GPTimerCC26XX_Value loadVal = freq.lo / 10000 - 1; //100us
  GPTimerCC26XX_setLoadValue(hTimer, loadVal);
  GPTimerCC26XX_registerInterrupt(hTimer, timerCallback, GPT_INT_TIMEOUT);
  GPTimerCC26XX_start(hTimer);

}

请帮您检查此案例? 谢谢。

此致,

樱桃

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

    你好,Cherry,

    看似相关的主题: https://e2e.ti.com/f/1/t/1060837 

    GPTimer 时钟取决于 MCU 系统时钟。 如果需要非常高精度的输出,应用程序应使用外部高频晶体进行请求。  在 sysconfig 中,默认情况下,SIMPLELINK-CC13XX-CC26XX-SDK 示例使用48 MHz XOSC HF 作为 HF 时钟源。 SIMPLELINK-CC2640R2-SDK 默认情况下使用源/ti/devices/cc26x0r2/startup_files/ccfg.c 中的24 MHz XOSC HF。  因此,如果两者都不使用 RCOSC,它们应该是准确的。  如果时间回调的唯一目的是切换 GPIO,则他们可以选择使用 PWM TI 驱动器。  如果偏移量一致(始终不正确为“X”微秒),它们将能够通过轻微更改 loadVal 来补偿。

    此致,
    瑞安

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

    你好 Ryan,

    今天我刚刚听到了最终客户的回复,很抱歉反馈延迟了。

    [引用 userid="114053" url="~ë/support/wireless-connectivity /蓝牙组/Bluetooth/f/Bluetooth-forum/1066983/cc2640r2f-timer-is -不准确/3947775#3947775"]如果回调的唯一目的是切换 GPIO

     计时器回调的目的是计时,并通过 GPIO 翻转来验证计时器是否准确。

    谢谢,致以诚挚的问候,

    樱桃

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

    感谢您提供更多信息。  我唯一的注意事项是,硬件中断有时可能被其他中断(例如来自另一个外围设备或无线电堆栈)触发的 HWI 线程抢占。  尽管这不会是一致误差的原因,但您可以参考 TI-RTOS 内核(SYS/BIOS)用户指南 了解更多信息。

    此致,
    瑞安

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

    你好,瑞安,

    [引用 userid="114053" url="~ë/support/wireless-connectivity /蓝牙组/Bluetooth/f/Bluetooth-forum/106983/cc2640r2f-timer-is -不准确/3955136#3955136"]您可以参考 《TI-RTOS 内核(SS/BIOS)用户指南 》了解更多信息。

    请仔细检查链接是否错误? (链接: 测量 CC13xx 和 CC26xx 电流消耗)  

    将计时器(100us)翻转到 GPIO 是否非常有效?

    谢谢,致以诚挚的问候,

    樱桃

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

    你好,Cherry,

    感谢您提醒我该链接,我已在上一份回复中更正了该链接,并在此处提供: https://dev.ti.com/tirex/explore/node?a=pTTHBmu__&node=ALClAD.5LZKCXi9Ff7.hWg__krol.2c__LATEST 

    由于我目前无法使用工作台设备,所以我没有测试过这种情况。  我不知道其他用户报告的类似问题。  客户是否正在评估启动板?

    此致,
    瑞安

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

    你好,瑞安,

    [引用用户 ID="114053" url="~ë/support/wireless-connectivity /蓝牙组/Bluetooth/f/Bluetooth-forum/1066983/cc2640r2f-timer-is -不准确/39598919#3959819"]客户是否正在评估 LaunchPad?

    现在使用1毫秒计时器计时。 主从机和从机同时打开计时器,每2分钟读取一次主从机时间。 发现主从时间(M-S)的差异更大。 理论上,只有一个连接间隔(23 ms)应该不同。 这与连接间隔冲突。

    所以客户想知道主从设备如何保持稳定的连接间隔? 使用什么时钟?

    注:同一连接事件上的从机时间;同一连接事件上的 M 主机时间;M_U:主机接收串行读取时间指令时间。 Δ:下一次–上一次

    S (毫秒)

    米(毫秒)

    M_U (毫秒)

    M-S (毫秒)

    ΔM (毫秒)

    ΔS (毫秒)

    ΔM μ_U (毫秒)

    61836.

    61860

    61818

    24.

    181828

    181857

    181828

    29.

    119997

    11992.

    120010.

    301841

    301874

    301839.

    33.

    120017

    120013.

    120011.

    421854.

    421891

    421853.

    37.

    120017

    120013.

    120014.

    541866

    541908

    541865

    42.

    120017

    120012.

    120012.

    661859.

    661904

    661875

    45.

    119996

    119993

    120010.

    781872.

    781922.

    781886

    50

    120018

    120013.

    120011.

    901884

    901938年

    901897

    54.

    120016.

    120012.

    120011.

    1021877

    1021955年

    1021907

    78

    120017

    119993

    120010.

    1141890

    1141952年

    1141918年

    62.

    119997

    120013.

    120011.

    对于几个已测试的模块,它们都保持不变:100 us 不准确,1 ms 勉强准确。

    谢谢,此致,

    樱桃

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

    客户应使用测试设置使用 LAUNHXL-CC2640R2F 评估其代码,以确认其硬件未导致任何问题。  您是否特别指的是 BLE 连接事件?  我可以与 BLE 专家联系以提供进一步的见解,也可以通过 BLE 堆栈用户指南SLA 解决您的问题

    此致,
    瑞安