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.

[参考译文] LAUNCHXL-CC1352R1:使用 SysConfig 并使用 IEEE 802.15.4配置发出刷写代码

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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1496311/launchxl-cc1352r1-issue-flashing-code-with-ieee-802-15-4-configuration-with-sysconfig

器件型号:LAUNCHXL-CC1352R1
主题:SysConfig 中讨论的其他器件

工具/软件:

他们要求我在两者之间使用 Code Composer Studio 中的 SysConfig 比较 CC1352R1的功耗  

  • 2.4GHz 频段(240–2480 MHz)
    • 250kbps、62.5kHz 偏差、MSK、530kHz RX 带宽
    • 250kbps、125kHz 偏差、2-GFSK、530kHz RX 带宽
    • 100kbps、50kHz 偏差、2-GFSK、350kHz RX 带宽
  • 低于1GHz 频段(779–930 MHz)
    • 50kbps、25kHz 偏差、2-GFSK、100kHz RX 带宽
    • 200kbps、50kHz 偏差、2-GFSK、311kHz RX 带宽
    • IEEE 802.15.4、50kbps、25kHz 偏差、2-GFSK、100kHz RX 带宽

一切都很好、直到我不得不刷写代码  

  • IEEE 802.15.4、50kbps、25kHz 偏差、2-GFSK、100kHz RX 带宽。
  • 200kbps、50kHz 偏差、2-GFSK、311kHz RX 带宽

不同之 处在于、默认射频命令现在是 CMD_PROP_TX_ADV 和 CMD_PROP_RX_ADV 。 因为代码编写器会不断提醒我  未定义 CMD_PROP_TX 和 CMD_PROP_RX。 我现在选择 CMD_PROP_TX 和 CMD_PROP_RX 。 并且必须将链路层最大数据包长度从2047更改为255。 我还更改了默认设置、即 TXpower 从14更改为5。  否则无法设置配置。

现在、我尝试刷写时不再出现错误。 但该过程始终会停止  

if ((result != RF_EventLastCmdDone)||((volatile RF_Op*)&RF_cmdPropTx)->status != PROP_DONE_OK)
while (1);
}
 
结果= 2052。  代码是  
使用 SysConfig 使用这种特定的 IEEE 802.15.4配置时、是否有人遇到类似的问题? 如果能就为什么会发生这种情况或如何解决这种情况提供任何指导、将不胜感激。

感谢您的帮助!

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    抱歉、
    也不是那些线
    RF_cmdPropTx.startTriggerType = TRIG_NOW;//立即执行 μ s
    RF_cmdPropTx.startTrigger.pastTrig = 1
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Xiaopeng、

    对于 IEEE 版本的 PHY、您使用的命令是否正确?(另外、这是在哪个 SDK 上)  

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

    是、、因为代码编写器无法使用  CMD_PROP_TX_ADV 和 CMD_PROP_RX_ADV 进行构建

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

    你好、小鹏范、

    我拉取了 CC13xx/CC26xx 示例、似乎我们需要执行以下操作:修复 IEEE 版本的 RF_CMDxxx:

    //射频内核 API 命令
    extern RFC_CMD_RADIO_SETUP_PA_t RF_cmdRadioSetup_ieee154_0;
    extern RFC_CMD_FS_t RF_cmdfs_ieee154_0;
    extern RFC_CMD_IEEE-TX_t RF_cmdIeeetx_ieee154_0;
    extern RFC_CMD_IEEE-RX_t RF_cmdIeeerx_ieee154_0;

    由于您尝试使用在 syscfg 上不可用的 IEEE PHY、我们需要引入 rcl_settings.c 和 rcl_settings.h 的本地副本、同时不包括 syscfg ti_radio_config.h  

    谢谢、
    Alex F

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

    我 在 TI 专有射频下使用 rfSynchronizedPacketTx 和 Rx 示例。 如果我 手动将 RF_CMDxxx 修正到 IEEE 版本、那么在尝试编译时会出现错误  

    RFC/TASK_SynchronizedPacketTX.c:133:17:错误:"RFC_CMD_IEEE-TX_t"{aka "truct RFC_CMD_IEEE-TX_s"}没有名为"pktLen"的成员 src
    133 | RF_cmdPropTx.pktLen = sizeof (message);
    |^
    RFC/TASK_SynchronizedPacketTX.c:134:17:错误:"RFC_CMD_IEEE-TX_t"{aka "truct RFC_CMD_IEEE-TX_s"}没有名为"pkt"的成员 src
    134 | RF_cmdPropTx.ppkt =(uint8_t*)&message;
    |^
    make:***[Makefile:201:_build/packettx/task_SynchronizedPacketTX.o] src 错误1

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

    您好、Xiaopeng、

    观察 IEEE 的结构、我们需要将 pktLen 更改为 payloadLen、将 pkt 更改为 pPayload:  

    uint8_t payloadLen;          //!<    有效载荷中的字节数
    uint8_t* pPayload;          //!<    指向 size payloadLen 的有效载荷缓冲区的指针
    #define CMD_IEEE_TX                                             0x2C01
    //! IEEE 802.15.4 Transmit Command
    struct __RFC_STRUCT rfc_CMD_IEEE_TX_s {
       uint16_t commandNo;                  //!<        The command ID number 0x2C01
       uint16_t status;                     //!< \brief An integer telling the status of the command. This value is
                                            //!<        updated by the radio CPU during operation and may be read by the
                                            //!<        system CPU at any time.
       rfc_radioOp_t *pNextOp;              //!<        Pointer to the next operation to run after this operation is done
       ratmr_t startTime;                   //!<        Absolute or relative start time (depending on the value of <code>startTrigger</code>)
       struct {
          uint8_t triggerType:4;            //!<        The type of trigger
          uint8_t bEnaCmd:1;                //!< \brief 0: No alternative trigger command<br>
                                            //!<        1: CMD_TRIGGER can be used as an alternative trigger
          uint8_t triggerNo:2;              //!<        The trigger number of the CMD_TRIGGER command that triggers this action
          uint8_t pastTrig:1;               //!< \brief 0: A trigger in the past is never triggered, or for start of commands, give an error<br>
                                            //!<        1: A trigger in the past is triggered as soon as possible
       } startTrigger;                      //!<        Identification of the trigger that starts the operation
       struct {
          uint8_t rule:4;                   //!<        Condition for running next command: Rule for how to proceed
          uint8_t nSkip:4;                  //!<        Number of skips + 1 if the rule involves skipping. 0: same, 1: next, 2: skip next, ...
       } condition;
       struct {
          uint8_t bIncludePhyHdr:1;         //!< \brief 0: Find PHY header automatically<br>
                                            //!<        1: Insert PHY header from the buffer
          uint8_t bIncludeCrc:1;            //!< \brief 0: Append automatically calculated CRC<br>
                                            //!<        1: Insert FCS (CRC) from the buffer
          uint8_t :1;
          uint8_t payloadLenMsb:5;          //!< \brief Most significant bits of payload length. Should only be non-zero to create long
                                            //!<        non-standard packets for test purposes
       } txOpt;
       uint8_t payloadLen;                  //!<        Number of bytes in the payload
       uint8_t* pPayload;                   //!<        Pointer to payload buffer of size <code>payloadLen</code>
       ratmr_t timeStamp;                   //!<        Time stamp of transmitted frame
    } __RFC_STRUCT_ATTR;
     
    谢谢、
    Alex F
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    非常感谢您的回答、这启发了我进一步了解对讲机文件中的这些参数。

    我已经找到了关于这个问题的解决方案。 参考问题" ">e2e.ti.com/.../lp-cc1352p7-no-transmission-when-using-rf_cmdproptxadv" 和技术参考手册,我只是通过添加一个长度字节和一个美白字节编辑了数据包,并调整了数据包的 TX RX 代码。 由于  CmdIeee 和 CmdAdv 的结构差异很大、我不敢自行修改命令。

    现在我还有一个问题、"IEEE
    802.15.4、50kbps、25kHz 偏差、2-GFSK、100kHz RX 带宽"中的默认设置是可以理解的。 必须为 CmdAdv。 因为 IEEE 有特定的数据包规则。 但是、为什么"200kbps、50kHz 偏差、2-GFSK、311kHz RX 带宽"中的默认设置也具有 CmdAdv? 以及为什么某些普通的 ti 专有设置只使用普通命令、如" 低于1GHz 频段(779–930 MHz)-- 50kbps、25kHz 偏差、2-GFSK、100kHz RX 带宽"? 有些人使用 adv 命令? 我看不出不同的设置之间有任何显著的区别。

    祝你一切顺利



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

    您好、Xiaopeng、

    为了根据 PHY 要与哪些底层命令标头一起使用、可以略微改变我们在实践中使用的命令。 例如、IEEE 有自己的命令与通用命令相比较、也就是说、这两个命令最终会在较低级别使用类似的 LRF 命令。  

    我不太熟悉 Sub-1GHz、但按照2.4GHz 的经验、我们往往使用 PHY 的设计命令、而且通常它们有许多相似之处。 有时我们会看到内部命令结构之间的差异(例如 ACK)。  

    谢谢、
    Alex F