[参考译文] CC2340R5：每100ms 读取一次 UART 失败

您好、Vignesh：

我希望你做得好! 我想询问我们是否可以尝试空的代码、还是尝试 UART 示例项目(而不是 BLE)、以查看我们是否仍然注意到这个问题。 改变时间间隔会改变接收到的数据包数量、这听起来确实很奇怪。

我们还可以在下面添加一个返回换行符吗？ (应为"...匹配\r\n")

UART2_write (uart、"接收数据不可加工"、24、0)；

谢谢！
Alex F

您好、Alex、

我已经尝试使用 UART 回调示例项目。 我没有  遇到任何问题。

缓冲区分配：

应用 UART_MAX_READ_SIZE = 100；

 在 SYS.CONFIG (默认值)中、UART RX Ring Buffer Size = 32；

然后、我已经交叉检查 UART 回调示例项目和应用项目(修复了 UART 过运行问题的基本 BLE 项目)之间的 UART 配置。

当我们开始分析代码时、我们发现 UART RX FIFO 没有清除、所以我们首先尝试了一下 UART2_readCancel (UART)； 电感  UART2_flushRx (UART)；  

前面是  UART2_READ (UART、uartReadBuffer、UART_MAX_READ_SIZE、0)；。 即使在这种情况下、也不清除 UART RX FIFO。

当我们从 UART 回调中检查 UART 数据大小时、我们会从实际数据包大小(即  100ms 的数据接收延迟)得到双倍大小。

缓冲区分配：

应用 UART_MAX_READ_SIZE = 300；

 在 SYS.CONFIG UART RX Ring Buffer Size = 1500中；TI 支持团队建议将下面的链接附加到您的参考。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1345246/cc2340r5-uart-overrun-event-has-occurring

谢谢！

Vignesh。

您好、Vignesh：

我过去使用了 flush 命令实现了相同的效果、还与缓冲区的 memset 配对：

void clear()
{
    memset(buffer, 0, strlen(buffer));
    memset(input, 0, strlen(input));
    UART2_flushRx(uart);
}

Clement 在该主题中的建议也应该是一个很好的参考！

谢谢！
Alex F

您好、Alex、

   我们 已经累了 UART2_flushRx (UART)； 即使是在 UART 回调中、我们也被计为200或300。

例如：

每隔100ms、我们就会向 UART 传输100个字节的数据(在 UART 数据包中、第一个字节包含 length (0x64))、但在 UART 回调中、我们在多次传输后计数为200或300。

请向我们提供如何清除 UART 环形缓冲区。

谢谢！

Vignesh。

尊敬的 Vignesh：

您能给我列出要在 basic_ble 示例中实现以再现相同情况所做的更改吗？ 请确保指定在 SysConfig 中所做的所有更改。

此致、

您好、Clement、

   抱歉、我无法在论坛上共享源代码。

谢谢！

Vignesh。

尊敬的 Vignesh：

请共享最小的代码更改以重现 basic_ble 示例中的问题-无需共享整个源代码。

此致、

我们已通过电子邮件单独发送了源代码。

尊敬的 Rahul：

谢谢你。

我已经完成了对您的代码的初始审阅(但我尚未成功构建和测试它)。

我已经确定了一种可能会导致您所描述问题的情况-由于您的系统正在运行非常复杂的程序、内核可能无法及时提供某些 UART 回调服务。 因此、您可以在接收到的不是一个、而是两个或三个100字节缓冲区后输入回调。

为了检查是否发生这种情况、您可以在每次进入 UART 回调时切换引脚。 然后使用逻辑分析仪、您可以记录引脚上的 UART 流量和活动。

假设出现所述的情况、我建议接受该行为-即检查缓冲区中的字节数；如果有多条 UART 消息、请确保处理所有消息。
要实际解决该问题、必须提高 UART 处理的优先级-但这实际上会对 BLEStack 产生很多副作用(因此我不建议继续采用该方法)。

请告诉我您的想法。

此致、

您好、Clement、

  我已经  通过每次  进入 UART 回调时切换引脚来检查该情形。 然后、使用 DSO、我们在那里测量了信号、我们发现所有 UART 回调的时序都不同。(某些 UART 回调的时间为100ms、当发生错误时、大约为250ms 至350ms。 )。

我们尝试了禁用   BLEAppUtil_invokeFunction (HandlingFunction、NULL)；  在 UART 回调例程中、我们能够按预期看到信号。 (与每100ms GPIO 正在切换一次类似)。

您是否可以建议使用其他任何方法来处理回调函数以处理数据？  

谢谢！

Vignesh。

您好！

您的观察结果证实了我提到的情形。

正如您所注意到的、除非您在软件设计中进行了重大更改、否则您将无法根据需要进行回调。

然后、我建议的方法是检查在每次回调中传递的缓冲区的长度。 根据长度、您可以评估您拥有的消息数。 然后、您应该能够适应数据处理。

我希望这将有所帮助、

此致、

尊敬的 Vignesh：

您是否已成功实施我在上一封邮件中提出的建议？

Unknown 说：

我建议的方法是检查每次回调中传递的缓冲区的长度。 根据长度、您可以评估您拥有的消息数。 然后、您应该能够调整数据处理。

要回答您的问题"必须在应用或堆栈端进行更改"、建议的更改必须在应用级别进行。

对于下面的问题、能否确认您使用的是 SDK 8.10.01.02 -此问题看起来已经在此 SDK 中修复？
如果是、我建议打开一个专用线程、以便避免主题混合。

另一个问题是、    在从模块传输多个数据包后、在尝试以 MTU 的大小连续将数据从模块发送到移动设备时 、我们遇到的问题是、状态为  blePending。

发生此错误后、我们无法与该模块连接或配对、需要重启电源才能恢复。

Status = SimpleGattProfile_SetParameter (SIMPLEGATTPROFILE_CHAR4、MTU_VALUE 和 uartReadBuffer[SentDataLen])；

如果您已经在使用 SDK 8.10.01.02,您能指定调用 SimpleGattProfile_SetParameter ()的时间间隔吗? 您使用的连接间隔是多少？

此致、