[参考译文] CC3235SF：是否可以为内部网络处理器编写一个#39自己的固件？

您好 Tobias、

内部 NWP 处理器基于 ROM、因此无法更改。 在考虑其他选项之前、您可以分享一个代码片段、了解如何创建套接字和传输数据包以及切换引脚？ 它只是在创建套接字后切换和发送的循环中吗？ 我想了解您的代码在执行什么操作、以便对您看到的延迟进行量化。

Jesu

您好！

我的代码基于"network_terminal"示例的"radioTool"部分。 我已经将所有内容迁移到 NoRTOS 设置。 在设置部分、我将其称为不变

RadioTool_Open() 

打开插槽(我在此处删除了错误检查...)

//创建套接
字 radioTool_rawSocketdesc = sl_Socket (sl_AF_RF、sl_SOCK_RAW、RxChannel)；
//从 RadioTool
SlTimever_t timeVal =｛0｝中保留；
= sl_SetSockOpt (radioTool_rawKetdesc、sl_SOL_Socket、sl_SO_RimeO、CVTval 和 RimeO sizeof (timeVal)；
//为 NoRTOS
SlSockNonBlocking_t enableOption 设置为非阻塞操作；
enableOption.NonBlockingEnabled = 1；
sl_SetSockOpt (radioTool_rawSockdesc、sl_SOL_socket、sl_SO_NONBlocking、(_u8 *)&enableOption；enableOption (enableOption)；enableOption (enableOption) 

稍后、我的发送器会执行该操作

//发送
静态 bool led_on 前切换 PIN = false；
led_on =!led_on；
GPIO_write (Board_GPIO_LED0、LED_on)；
//填充标题信息
sl_NetCfgGet (sl_netcfg_MAC_address_get、NULL、&pConfigLen、memTemplate_HDR[TA_OFFSET](sl_DR_MODET]
)；[SL_DR_DR_DR_DR_DRVS_DRVESS_GET](sl_DR_DR_DR_DRVE_DRVE_DRVES "123456 "、SL_WLAN_BSSID_LENGTH)；//接收
器 memcpy (&Template_HDR[DA_OFFSET]、"abcdef"、SL_WLAN_BSSID_LENGTH)； //目的
memcpy (Tx_FRAME、Template_HDR、sizeof (Template_HDR))；
//复制数据
memcpy (&Tx_FRAME[sizeof (Template_HDR)]、"ping"、strlen ("ping")；
//计算总大小





：头+数据 uintseq 16_t total_size = MCS eof (Template_rule_sx)；txrwlan_r_sense_rand_del_ram_rule_rulate = t_sle_rand_rulate；// t_sle_rand_rulate = t_sle_rate_rule_rand_rule_rulate = t_sle_rand_rand_rulate；t_sle_r_rulate = t_sle_rand_rule_rand_rulate = t_sle_rand_rule_rke_rand_ 速率、powerLevel、前置序列)； 

RX 端看起来是：

//尝试接收数据，非阻塞
Int32_t ret = sl_Recv (radioTool_rawSocketdesc、&Rx_FRAME、RX_buffer_size，0)；
//如果
(ret > 0){，则检查我们是否已接收到任何数据
//过滤此数据包是否适合我们
if (memcmp (&rx_frame[RA_offset+8]、"123456 "、6)=0 && memcmp (&rx_frame[DA_offset+8]、"abcdef"、6)=0)｛
静态 bool led_on = false；
LED_ON =！LED_ON；
GPIO_WRITE (Board_GPIO_LED0、LED_ON)；
｝
｝ 

在发送器侧、引脚在数据包被传递到 NWP 之前被切换、因此应用代码中不会有进一步的延迟。 在接收器端、此代码在循环中运行、循环会额外调用所需的

SL_Task (空)； 

但那里没有发生其他事情、因此我看不到可能发生延迟的情况。 你怎么看？

您理论上是正确的、但这显然不是问题。 我已经测量了 LED 的切换速度、设置/取消设置引脚大约需要5us。 因此、这大约比我观察到的延迟快1000倍。

此外，我已经在 sl_NetCfgGet ()函数调用之后(甚至在 sl_Send ()函数调用之后)移动了引脚的切换！ 但延迟仍然保持在5到15毫秒左右。

您能给我们提供有关 NWP 上运行的软件类型的进一步见解吗？ 它可能是某种类型的 RTOS 吗？ 这些延迟是否可以由 NWP 上的调度程序引起？

您好、Tobee、

在 NWP 中、您几乎拥有整个网络堆栈。 编程人员指南 将让您更好地了解 NWP 上运行的内容。 我已经测试了 LED 切换的运行时间、它看起来您正是在等待时间。

为什么您对实际发送的延迟感兴趣？ 是因为您要尝试实现特定的数据速率吗？

Jesu

您好、Jesu、

首先、我知道 NWP 上有一个802.11网络堆栈(甚至更多)、但当我处理原始数据包时、该网络堆栈大部分会被绕过。 对于实际的基带处理(我需要和使用这些处理)、我非常确信专用硬件中发生的所有事情都没有相当长的延迟(对吗？)。 因此、我感到惊讶的是总延迟如此之高、因为我不知道它们发生在何处以及为什么、我想大幅减少这些延迟。

不、我对数据速率不是很关心、它只是用于不允许这些延迟的实时应用。

此致。