[参考译文] LAUNCHXL-CC1312R1：LAUNCHXL-CC1312R1：射频 API 的正确使用方案

您好 theo ,谢谢您的答复,很抱歉从我身边的延迟...

1. 我只使用 simplelink_cc13xx_cc26xx_sdk_7_41_00_17。
2. 不使用 RTOS、在 syscfg 文件中设置：- rtos"nortos"。

关于您的回复：

1. 感谢您的链接。 我以前已经研究过它们。 感谢您提供详细可靠的文件。
2. 好的、可以理解。
3. 我们的应用程序中未使用 RTOS。 我将尝试在文档中阅读更多内容。

"一般而言,我认为,你想要实现的时间安排应该由 RTOS 任务监禁完成。 但请更详细地解释我希望执行哪个无线电操作以及要在哪个软件栈上运行。"

我们有意不在库开发中使用 RTOS、原因有以下几个：

• 可移植性-库可以在没有操作系统的情况下使用、也可以与操作系统一起使用、我们远远不能与任何操作系统集成、因为它在我们的产品中是可选的(客户将其与他们想要的东西集成)。
• 严格的时序裕量-我们的堆栈(6TiSCH)要求无线电在严格的时序机制下运行(如在 BLE 中)、如果任何操作系统以微秒精度处理这一切、就会不容易实现。 在特权模式下必须执行关键的、可能是短暂的操作、其余的任务被委派给线程/应用上下文(同样与 BLE 中的控制器和主机类似)。
• 端口的 API 已经建立-我们的产品已经成熟、我们很难更改端口 API。 我们更关心的是将 TI 驱动程序与端口 API 相匹配、而不是反过来。 我们已经有许多其他芯片以这种方式与我们的软件一起工作。

我的早期开发平台是使用 FreeRTOS 的应用程序(syscfg 参数：- rtos"freertos")。 在 GPTIMER ISR 中、我运行无线电 API 函数以开始传输。 这种简化的代码片段以确定的执行时间以可预测的方式工作、因此可以提前执行传输以满足严格的传输时序("说前先听"功能也进行了测试、结果为正)。

static rfc_CMD_FS_t txChainSetFs = {
    .commandNo = CMD_FS,
    .startTrigger.triggerType = TRIG_NOW,
    .pNextOp = (RF_Op *)&txChainCs,
    .condition.rule = COND_STOP_ON_FALSE,
    .synthConf.bTxMode = 0x1, // Start FS in Tx Mode, this option seems to be unused (even in example code)
};

static rfc_CMD_PROP_CS_t txChainCs = {
    .commandNo = CMD_PROP_CS,
    .pNextOp = 0,
    .startTime = 0,
    .startTrigger.triggerType = TRIG_NOW, // Triggers immediately
    .condition.rule = COND_NEVER,         // COND_STOP_ON_FALSE, // Run next command if this command returned True, stop if it returned False
    .csFsConf.bFsOffIdle = 0,             // Keep synth running if command ends with channel Idle
    .csFsConf.bFsOffBusy = 0,             // Keep synth running if command ends with channel Busy
    .csConf.bEnaRssi = 1,                 // enable RSSI as a criterion
    .csConf.busyOp = 0,                   // continue carrier sense on channel Busy
    .csConf.idleOp = 0,                   // continue on channel Idle
    .csConf.timeoutRes = 1,               // Timeout with channel state Invalid treated as Idle
    .rssiThr = -80,                       // RSSI threshold
    .numRssiIdle = 0,                     // Number of consecutive RSSI measurements below the threshold needed before the channel is declared Idle
    .numRssiBusy = 0,                     // Number of consecutive RSSI measurements above the threshold needed before the channel is declared Busy
    .csEndTrigger.triggerType = TRIG_REL_START, // Trigs at a time relative to the command started
    .csEndTime = 0,
};

bool txNow(){
  TimeUs t = time_us();
  // software-dl.ti.com/.../cmd_prop_cs.html
  txChainCs.csEndTime = 880; // first RSSI sample takes 214us + 5us, RAT tick with 250ns period, lower time produces PROP_DONE_BUSYTIMEOUT or
  // PROP_DONE_IDLETIMEOUT irrelevant to signal strength
  txChainCs.status = IDLE;
  // measured - takes 435us
  RF_runCmd(rfHandle, (RF_Op *)&txChainSetFs, RF_PriorityHigh, NULL, 0);
  // time must be manually counted down because of when the EMBENET_RADIO_TxNow funcion is called from GPTimer ISR then RF_runCmd returns immediately
  // and command is not processed properly
  while((uint32_t)(time_us() - t) < 435)
    ;
  if(PROP_DONE_IDLE != txChainCs.status)
    return false; // CHANNEL BUSY
  // measured posting takes 82us
  // measured after end of posting, signal appears with 64us delay
  txTransaction = RF_postCmd(rfHandle, (RF_Op *)&txChainDoTx, RF_PriorityHigh, txProcessCb, RF_EventCmdDone);
  // RF_EventTxDone or RF_EventMdmSoft does not work properly, so the SOF handler is called immediately
  if(onStartOfFrameHandler) {
    onStartOfFrameHandler(handlersContext, t + txSofToSignal);
  }
  return true; // OK
}

但是、此部件和其他一些部件在没有 RTOS 的情况下的工作方式不同(syscfg 参数：--rtos"nortos")。

我设法使它可以在有或没有 RTOS 的情况下工作、但传输功能中没有"说前先听"功能。 现在、我的目标是实现一个阻塞功能、无论传输是否启动、该功能都会给出"是"或"否"结果。 最好恰好有160us 的侦听周期和最小的代码执行开销。