[参考译文] CC1314R10：无线电驱动程序回调问题

也很特别…

我有一个“任务“命令,显示正在运行的内容。

这是运行时的打印输出

寻址的
Name      状态  优先级堆栈  编号
命令        X    3    278 2.    
空闲       R    0    84 5.    
net        b    6    350 4.    
ETH        S    4    404 3.    
TMR 服务      b    5    72   6

无线电       S    7    318 1.    

从表 Eth 和 Radio 有一个状态 S,=暂停,但我没有做暂停,我只使用通知,从文档这应该会导致一个 B 状态,即等待

要运行 en 事件

令人困惑...

Gullik

【已删除】

更多的发现…

当我收到无线电回调时、我会根据 10us 运行时计时器来记录时间戳。

此计时器仅运行 I HW、并且在其中断运行时会递增（可能还有 2 个计时器变量）、因此不会产生昂贵的成本。

ISR 到任务的典型延迟为 100 到 180us、这意味着在数据包接收和任务执行之间执行了大量代码。 这似乎可以、但限制为 5000 到 10000 个无线电包/秒

每一次、延迟是 3000、有时甚至比 2000us 更大。 我在这方面没有任何时间

但这是数据包丢失的问题。 那么、3000us 延迟是由什么引起的？ 这似乎与丢弃的数据包相一致。

什么可能导致 FreeRTOS 无法为 3MS 安排优先级最高的任务？？

更令人困惑

Gullik

因为我是以一种糟糕的方式登录编辑的…

更新：

夜间跑步：

我得到 1.0125 数据包回调/任务激活、因此 1.25%。 在 prio 6 处、监督任务只完成一次定时等待、更改延迟对延迟问题没有影响。 除创建之外、不使用其他操作系统调用。

尊敬的 Gullik：

感谢您提供详细的报告。

我是否正确地认为该主题与以下内容相关： https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1524765/cc1314r10-driver-overhead-nortos-freertos ？

如本主题中所述、您能否将您对 FreeRTOS UART 桥接器示例的修改分享给其他人？

默认设置使用两个回调：
1. ReceivedOnRFcallback ():当对讲机接收到数据包并将消息内容保存在 RX 队列中时触发。 设置 main 的标志。
2. ReceiveonUARTcallback ():在 UART RX 活动时触发,非阻塞并等待 UART2_STATUS_SUCCESS 以确保 RX 完成。 设置 main 的标志。

此致、
Theo

您好 Theo、

这是我的真正问题、驱动程序开销是在调试期间观察到的。

进一步调查显示、在 prio 7 上运行的对讲机进程的正常激活时间为

100us 至 150us。 这会抓取 IPG 内的数据包、所有这些都很好。 然而,每次现在,然后激活

时间高达 1.2mS、然后数据包溢出。 我通过在无线电回调中设置 GPIO、和来看到这一点  

在 ulTaskNotifyTake 之后清除“main rfUARTBridge loop“等待的位置。

我猜 1.2ms 是 200us、加上一些未定义的 MS、即与 FreeRTOS 相关。

可能是驱动程序/ISR、我只有一个处理以太网中断的 GPIO 引脚。

以太网任务相当不重要、因为我正在使用的 W5500 芯片上有许多缓冲区、

因此、中断响应相当宽松。 该任务在 prio 4 上运行。 中断会一直持续到其处理过程结束

已提取数据包、但从文档中、我了解到 GPIO INT 已被其驱动程序攻击、

我只对该 IO 引脚使用负侧面触发器。

我还有一个以 10kHz 的频率运行的计时器中断、这相当快、但 int 只能运行

｛

运行时++；

if(Timer0！=0) Timer0-;

if(Timer1！=0) Timer1-;

}

因此不应对任何毫秒负责、

所以,对于一个 MS（或最初观察到的 2 或 3 MS）做什么

我不是在调试代码时寻求帮助、而是提供有关如何调试代码的提示和建议

调查此问题。

此致、

Gullik

尊敬的 Gullik：

如此处所示： https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1524765/cc1314r10-driver-overhead-nortos-freertos

我认为最好的继续方法是添加 TI Logger 和驱动程序调试日志、查看是否有任何内容被阻止。

我认为值得尝试直接确认此中断并使用事件对其进行处理。

[引述 userid=“609575" url="“ url="~“~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1524273/cc1314r10-radio-driver-callback-question/5863563 #5863563“]

中断会一直持续到其处理过程结束

获取了数据包、

[/报价]

此致、
Theo