[参考译文] LAUNCHXL-CC1352R1：TI-RTOS 时钟模块性能

您好、Tyler、

该主题对您有什么帮助吗？ https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1118318/cc1352p-improve-accuracy-of-packet-timestamp/4174773#4174773

如果您使用 来自射频内核(https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_20_00_29/docs/proprietary-rf/proprietary-rf-users-guide/rf-core/signal-routing.html)的 RAT_GPO1来触发计时信号、该怎么办？ 我认为可以改善您观察到的抖动、但您可能需要转换时间戳。

此致、

Arthur

尊敬的 Arthur、目前我仅使用射频来同步两个时钟、然后使用时钟模块每隔100ms 使用通过射频发送的时间戳的初始启动时间输出一个信号。 您认为使用 RAT_GP01信号比使用时钟模块更准确吗？

如果是、将覆盖位置置于何处以启用此信号？

您好、Tyler、我看到您以前实际上使用过这些信号、对吗？ https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1084058/launchxl-cc1352r1-rf-core-signals-output/4012582?tisearch=e2e-sitesearch&keymatch=%25252525252520user%2525252525253A511063#4012582

我们/您必须执行一些测试才能确定抖动的特征。 您使用射频同步时钟的频率如何？

此致、

Arthur

到目前为止、我计划每隔1秒重新同步时钟(尚未实际实施)、因为时钟模块上的漂移会在大约1秒后使时序不正确。 原始抖动数是通过示波器测量的、该示波器捕获来自时钟模块的8个脉冲。

感谢您找到另一个线程、我将需要找到我为此编写的代码、以查看我使用的覆盖项。

要同步时钟、我在发送端的中断中捕获时间戳、添加100ms、然后使用绝对触发器在正确的时间发送。 在接收端、附加 RX 时间戳、在正确的时间接收时间戳数据包、我从从 TX 到 RX 高同步信号的时间延迟固定开始、即(前导码位+ syncword 位)*微秒/符号速率->转换为 RAT 节拍。 经过一些测试、我将此延迟降低了382微秒、这使我能够始终在几微秒内获得开始时间。 然后、我使用周期为100ms 的时钟模块来输出那里的其余脉冲、但正如上面提到的那样、我遇到了抖动和漂移问题。

您好、Tyler、

我想知道、您是否也观察到 TCXO 的漂移？ 以下是如何在 https://www.tij.co.jp/jp/lit/an/swra640g/swra640g.pdf?ts=1666773026023&ref_url=https%253A%252F%252Fwww.google.com%252F 中启用它

此致、

Arthur

谢谢你。 我将启用 TCXO。 链接的该文档具有 CC1312R 电路板上 TCXO 的电容器失调电压值和启动时间值。 这些相同的配置值是否可以在我使用的 CC1352R1板上使用？ 此外、我是否需要移除 CC1352R1电路板上该文档中列出的相同电阻器？

您好、Tyler、

不用担心、LAUNCHXL-CC1352R1上没有安装 TCXO。 我的错误。
您可以在 SysConfig -> Device Configuration 中启用"RF Temperature Compensation"。
无需修改硬件。

此致、

Arthur

明白了、 您是否有 XOSC 单点校准参数的起始值？ XOSC_HF 需要进行温度测量。 它通常在实验室环境中的室温(70F)下进行测试

我将尝试查找数据、但实际上我不确定这将有助于解决您的问题。 与时钟模块相比、您是否评估了无线电计时器？

此致、

Arthur

亚瑟

很抱歉我的答复很晚。 我还没有尝试过无线电计时器、因为使用时钟模块的周期功能更方便。 是否有办法为低于1GHz 的射频 TX 设置绝对时间触发器、并利用射频 TX 驱动程序在该时间之前传输数据？  

现在、我使用的是 ABS 触发器的默认示例、它将关闭对讲机、直到在触发时间之前几毫秒、此时对讲机将唤醒。 这是我当前使用的代码：  

这会根据预先计算的时间(代码中的较早时间)将下一个时间戳设置为触发、加载有效负载(带时间戳)并运行 RF 命令、在该命令中、它将进入空闲状态、等待触发时间。 我要做的是保留此功能、但仍能通过射频发送数据、直到触发时间。 然后在正确的触发时间发送数据包。 这是否可以在无需每次重新配置对讲机的情况下实现？ 到目前为止、我已经假设这不是因为当我通过射频发送常规数据时、我现在使用的是射频 TX 的 TRIG 触发器类型、而不是 ABS TRIG。

您好、Tyler、

遗憾的是，如技术参考手册25.3.2.5节所述，这是不可能的。 在此之前、您必须安排(或链接)您的命令。

我尝试使用以下代码片段验证该声明、但它不能正常工作、正如预期的那样：

/*
 * Copyright (c) 2019, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/***** Includes *****/
/* Standard C Libraries */
#include <stdlib.h>
#include <unistd.h>

/* TI Drivers */
#include <ti/drivers/rf/RF.h>
#include <ti/drivers/GPIO.h>
//#include <ti/drivers/pin/PINCC26XX.h>

/* Driverlib Header files */
#include DeviceFamily_constructPath(driverlib/rf_prop_mailbox.h)

/* Board Header files */
#include "ti_drivers_config.h"
#include <ti_radio_config.h>

/***** Defines *****/

/* Do power measurement */
//#define POWER_MEASUREMENT

/* Packet TX Configuration */
#define PAYLOAD_LENGTH      30
#ifdef POWER_MEASUREMENT
#define PACKET_INTERVAL     5  /* For power measurement set packet interval to 5s */
#else
#define PACKET_INTERVAL     500000  /* Set packet interval to 500000us or 500ms */
#endif

/***** Prototypes *****/

/***** Variable declarations *****/
static RF_Object rfObject;
static RF_Handle rfHandle;

static uint8_t packet[PAYLOAD_LENGTH];
static uint8_t packetFromThePast[] = "  I come from the past";
static uint16_t seqNumber;

rfc_CMD_PROP_TX_t RF_cmdPropTx2 =
{
    .commandNo = 0x3801,
    .status = 0x0000,
    .pNextOp = 0,
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .pktConf.bFsOff = 0x0,
    .pktConf.bUseCrc = 0x1,
    .pktConf.bVarLen = 0x1,
    .pktLen = 0x14,
    .syncWord = 0x930B51DE,
    .pPkt = 0
};

/***** Function definitions *****/

void *mainThread(void *arg0)
{
    RF_Params rfParams;
    RF_Params_init(&rfParams);

    GPIO_setConfig(CONFIG_GPIO_GLED, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

    GPIO_write(CONFIG_GPIO_GLED, CONFIG_GPIO_LED_OFF);

    /* Request access to the radio */
#if defined(DeviceFamily_CC26X0R2)
    rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdPropRadioSetup, &rfParams);
#else
    rfHandle = RF_open(&rfObject, &RF_prop, (RF_RadioSetup*)&RF_cmdPropRadioDivSetup, &rfParams);
#endif// DeviceFamily_CC26X0R2

    /* Set the frequency */
    RF_postCmd(rfHandle, (RF_Op*)&RF_cmdFs, RF_PriorityNormal, NULL, 0);

    /* Schedule command 5 seconds in the future */
    packet[0] = (uint8_t)(seqNumber >> 8);
    packet[1] = (uint8_t)(seqNumber++);

    RF_cmdPropTx2.pktLen = sizeof(packetFromThePast);
    RF_cmdPropTx2.pPkt = packetFromThePast;
    RF_cmdPropTx2.startTrigger.triggerType = TRIG_REL_SUBMIT;
    RF_cmdPropTx2.startTime = RF_convertMsToRatTicks(5000);
    RF_postCmd(rfHandle, (RF_Op*)&RF_cmdPropTx2, RF_PriorityNormal, NULL, 0);

    while(1)
    {
        /* Reset command trigger */
        RF_cmdPropTx.pktLen = PAYLOAD_LENGTH;
        RF_cmdPropTx.pPkt = packet;
        RF_cmdPropTx.startTrigger.triggerType = TRIG_NOW;

        /* Create packet with incrementing sequence number and random payload */
        packet[0] = (uint8_t)(seqNumber >> 8);
        packet[1] = (uint8_t)(seqNumber++);
        uint8_t i;
        for (i = 2; i < PAYLOAD_LENGTH; i++)
        {
            packet[i] = rand();
        }

        /* Send packet */
        RF_EventMask terminationReason = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx,
                                                   RF_PriorityNormal, NULL, 0);

        switch(terminationReason)
        {
            case RF_EventLastCmdDone:
                // A stand-alone radio operation command or the last radio
                // operation command in a chain finished.
                break;
            case RF_EventCmdCancelled:
                // Command cancelled before it was started; it can be caused
            // by RF_cancelCmd() or RF_flushCmd().
                break;
            case RF_EventCmdAborted:
                // Abrupt command termination caused by RF_cancelCmd() or
                // RF_flushCmd().
                break;
            case RF_EventCmdStopped:
                // Graceful command termination caused by RF_cancelCmd() or
                // RF_flushCmd().
                break;
            default:
                // Uncaught error event
                while(1);
        }

        uint32_t cmdStatus = ((volatile RF_Op*)&RF_cmdPropTx)->status;
        switch(cmdStatus)
        {
            case PROP_DONE_OK:
                // Packet transmitted successfully
                break;
            case PROP_DONE_STOPPED:
                // received CMD_STOP while transmitting packet and finished
                // transmitting packet
                break;
            case PROP_DONE_ABORT:
                // Received CMD_ABORT while transmitting packet
                break;
            case PROP_ERROR_PAR:
                // Observed illegal parameter
                break;
            case PROP_ERROR_NO_SETUP:
                // Command sent without setting up the radio in a supported
                // mode using CMD_PROP_RADIO_SETUP or CMD_RADIO_SETUP
                break;
            case PROP_ERROR_NO_FS:
                // Command sent without the synthesizer being programmed
                break;
            case PROP_ERROR_TXUNF:
                // TX underflow observed during operation
                break;
            default:
                // Uncaught error event - these could come from the
                // pool of states defined in rf_mailbox.h
                while(1);
        }

#ifndef POWER_MEASUREMENT
        GPIO_toggle(CONFIG_GPIO_GLED);
#endif
        /* Power down the radio */
        RF_yield(rfHandle);

#ifdef POWER_MEASUREMENT
        /* Sleep for PACKET_INTERVAL s */
        sleep(PACKET_INTERVAL);
#else
        /* Sleep for PACKET_INTERVAL us */
        usleep(PACKET_INTERVAL);
#endif

    }
}

我仍会尝试检查是否有办法实现您想要的目标。

此致、

Arthur

Arthur、我不能真正调度 TX 命令、因为我正在使用电路板通过射频中继信息、因此、不知道数据何时会通过 UART 传入。 想法是当数据通过 UART 进入->通过射频立即发送到其他电路板。 当通过射频接收到内容时、立即通过 UART 驱动程序发送。 但是、在这段消息之间、我需要通过射频定期发送时间戳。 精度很重要、因此我使用了 TX 函数的绝对时间触发器。 我正在计算超时、直到需要发送下一个周期性时间戳。 在应发送时间戳的大约20ms 之前、我取消正在进行的 UART 和射频读取、关闭射频驱动程序、将 TX 射频功能重新配置为绝对时间触发器、重新打开与射频驱动程序的连接、设置频率、 并运行 TX 命令以在 TRIG Abs 时间发送时间戳。 但是、这不起作用、每次调试代码时都会出现随机错误、如下所示：

这不会提供太多信息、因此几乎无法进行调试。 您知道如何修复或调试它吗？ 下面是发生该情况的代码(我在上面描述了的函数)：

当射频 TX 命令与 RF_runCmd 一同运行时、会发生上述错误

Tyler、您好、我还没有看到这些片段中明显的错误。

但是、根据您所描述的内容、您似乎正在尝试实现与以下目标相同的目标(缩短同步时间)： https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_30_00_84/examples/nortos/LP_CC1352P7_4/prop_rf/rfUARTBridge/README.html

是这样吗？

此致、

Arthur

亚瑟

是的、我使用射频 UART 桥作为基础来发送数据。 我使用绝对触发器发送时间戳、关闭射频连接并更改参数、然后重新打开射频驱动器时、我遇到问题。 我将会遇到随机错误(如上所示、在地址0xXXXXXXX 处中断)[编辑：从技术上讲、这并不是真正的错误、  但它对调试没有帮助、因为处理器正在执行 CCS 无法显示的某些汇编或其他类型的代码、因此我无法查看或了解它是如何卡在那里的]、否则射频在触发时不会发送 (它只是不发送任何内容)。 我正在尝试使用 TI RTOS、利用两个任务和时钟对象来实现这一点。 但是、我已经重新配置了时序部件、以使用一个32位定时器、这个定时器比时钟对象更简单、并且看起来具有更好的性能(更少的抖动和漂移)。 现在、我正在尝试使用与 RFSynchronizedPacket 示例工作方式类似的状态将所有代码移动到 No RTOS。

我需要重新配置射频的原因是我需要每隔一秒左右重新同步一次时钟、因为接收 TI 电路板上的内部振荡器具有大量漂移、会使计时信号改变数微秒。 因此、我将射频驱动器重新配置为根据从参考器件接收到的新锚点执行绝对时间触发。 发送后、接收板会重新计算两个时钟之间的时间延迟、并使用该延迟计算下一个时间戳。 很明显、调整外部振荡器会减少这一问题、但我使用的评估板没有该选项。

Tyler、

通过您的解释、我实现了一些目标。

您能否尝试通过设置为2500 (射频内核驱动器中的默认值)来禁用自动 RFcore 加电计算？
https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_30_00_84/docs/rflib/html/struct_r_f___params.html#a58dc682aa09acabe6411ea186dd3aebf
如果您重复打开和关闭 RFCore、这可能有助于您观察到的抖动。

告诉我结果、

此致、

Arthur

亚瑟

我将该参数设置为：  

这是正确的、您的想法是什么？ 如果是、我今天将对其进行测试。

另外、在关闭无线电连接、重新配置以执行绝对触发、然后重新打开连接并运行 TX 命令时、射频驱动程序为什么会出现错误或无法正常工作的任何帮助？

您好、Tyler、

这正是我真正想到的。

关于该错误、我不确定我是否曾看到过该错误、但您是否碰巧在您谈到的两个不同线程中修改 RF_cmdPropTx？

此致、

Arthur

感谢您的帮助、我将很快对其进行测试。

配置参数会在两个任务之间发生更改、一个任务是这样设置的。 这是在时间戳时间之前大约10ms 完成的。

另一个是类似这样的设置。 这是在发送绝对触发器之后、并且我们已经超过了时间戳时间。 这用于常规消息传输。

我认为每次关闭与射频驱动器的连接可以避免在更改配置参数时出现任何错误。

Tyler、

 那么、可能值得添加一个互斥量来保护 RF_cmdPropTx。 让我知道抖动测试的结果。

此致、

Arthur

Arthur、您好、抖动测试没有产生不同的结果。 抖动大致相同。 此时、我更关注时钟漂移。  

是否有办法将外部晶体用于 CC1352R1评估板？  

在我上面链接的代码中、关闭射频内核会有 RF_Yield (RF_Handle)命令帮助、从而有可能解决我的问题？ 我认为我可以通过重新同步时钟来纠正时钟漂移、但仍然难以将射频 TX 重新配置为使用 ABS 时间触发器。

您好、Tyler、

当芯片处于工作模式时、我们已经使用了外部晶振、根据您的建议、我不确定是否会产生影响。

我们有两个新选项供您测试。 我们知道、当器件从待机状态唤醒时、会发生时钟漂移。 我们还知道 TI-RTOS 使用 LF 时钟作为其时钟模块。 因此：

_您能否从 HF XOSC 获得 LF 时钟？ 这将产生禁用器件待机模式的副作用。
_如果两个器件之间存在可见漂移、您可以尝试自行调整内部晶体电容器阵列、以便它们更好地匹配。

在这两种情况下、请参考图片：

此致、

Arthur

Arthur、这似乎有所帮助、但我仍然看到大约每秒20微秒左右的漂移。 有没有其他方法可以减少这种漂移？ 我意识到、此时漂移/秒可能难以解决。 请注意、这是在计时器超时时时时看到的漂移。

Tyler、

除了尝试将一个10PPM 或更低的晶振焊接到 launchpad 电路板上(焊接到电路板上的晶振为20PPM)之外、我觉得我们已经用尽了在 TI-RTOS 时钟上可以执行的所有操作。 此外、即使是20 PPM、我们也不应该有如此大的漂移。

因此、您可以尝试使用我们的 GPTimer 驱动程序、而不是使用时钟模块吗？ https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_30_01_03/docs/drivers/doxygen/html/_timer_8h.html

这些器件直接使用系统时钟、驱动程序提供了一种回调函数的排序方式、与 TI-RTOS 时钟模块的排序方式相同。 我认为这是我们的最佳机会。

此致、

Arthur

此外、我在 SysConfig 中注意到这一点：

您可以尝试降低该值吗？

此致、

Arthur

我没有尝试过 GPTimer 实例、但我通过 Sys config 尝试了32位计时器、并使用了上面链接的驱动程序。 使用 GPTimer 会改善这一点吗？

抖动优于时钟模块、每个时钟周期使用1微秒、因此更准确(抖动约为1.5us)。 但是、我仍然看到类似的漂移、每隔几秒就会出现多次微秒。 我正在使用 OneShot 计时器进行回调。 我使用射频通过初始时间戳发送、计算时钟之间的时间差、根据通过射频发送的原始时间戳的100ms 计算下一个计时器超时。 然后启动计时器。 计时器回调发生后、我设置一个标志、然后重新计算下一个计时器超时(再次基于100ms +通过射频发送的原始时间戳)、并再次启动计时器。 我不认为我计算超时的方式会导致漂移问题。 在调试模式下、我观察计时器超时计算变量每100ms 更新一次、它始终是99954或99955、因此值实际上不会改变。

如果我了解您所描述的内容、您实际上已经通过 SysConfig 使用了 GPTimers。

我相信您的超时计算是正确的、但我们可以通过使用计时器的快照模式(技术参考手册中的15.3.2.1)将进入 ISR 的总时间考虑在内来使其更好。 不过、您必须将计时器配置为周期性计时器、但发送数据包后可以将其停止。

另一位同事认为、我们最准确的计时器是 SysTick 计时器 ：https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_30_01_03/docs/driverlib_cc13xx_cc26xx/cc13x2_cc26x2/driverlib/group__systick__api.html

您是否也尝试过这个？ 您还可以使用此 API 设置回调。

Arthur、我试着用这个价值来玩。 然而、选择不同的值似乎只会增加两个电路板之间的漂移率。 我观察到的最小漂移量是当此字段留空时的默认值。 我最终手动补偿了代码中的漂移、这不是很好、但允许进行基线测试。 我无法找到   上面显示的代码(链接)不起作用的原因。 如果我能够重新发送另一个时间戳消息、我可以每两秒重新同步一次电路板上的时钟、以避免最差的漂移。

除非您对如何使上述代码正常工作或完成我在最后一段最后一句中所写的内容有任何其他想法、否则我可以将此问题标记为已解决。 感谢您为我提供的所有帮助！