[参考译文] CC3235SF：MQTT 在设置为非阻塞时发布呼叫、在连接中断时最多阻止10秒。

MQTTClientCore_sendPubMsg 是进程中的阻塞函数。

尊敬的 Keith：

我从未使用过 TI MQTT 库、但我认为10秒的超时来自 sl_Connect ()以建立 TCP 连接。 此超时在 NWP 内进行硬编码、不能更改。 如果您的问题与 sl_Connect()有关，则无法解决该问题。 这不是 CC32xx 的限制、而是 TCP/IP 网络的工作方式。

唯一正确的解决方案是将网络逻辑与其他硬件通信分开。 这意味着与其他线程的单独 SPI 通信并使用信标或消息队列创建进程间通信。

1月

一月、

我们已尝试将其移至另一个线程、但出于某种原因、发布调用会干扰我们用于与其他硬件通信的 SPI_1。  我们被迫在每次发布调用之前暂停 SPI 通信、并在之后恢复。  这使我们无法在另一个线程中执行发布调用。  由于发布呼叫仍处于非阻塞状态、因此我仍然不清楚为什么非阻塞呼叫内部会有阻塞连接。

您好！

我不确定您的 MQTT (这意味着 TCP/TLS 通信)为什么会干扰其他硬件 SPI 通信。 我有非常复杂的应用、这些应用大量使用 I2C、SPI 和 UART (与 LCD 显示屏、传感器、ADC、存储器、RTC、 USB……)。 我在此应用中有许多套接字服务(应用处理器上的 HTTP (s) 1.1多套接字 Web 服务器、多套接字 ModbusTCP 服务器、SNMPv1/2/3服务器、基于 UDP 广播的零配置查找设备、支持 TLS/STARTTLS 的 SMTP 客户端、含 TLS 的专有通信协议、HTTPS POST 到服务器)。 所有这些功能都同时在 CC32xx 上运行、我从未见过此类问题。 但我自己编写的所有网络库(SNMP 是从 lwIP 移植的)是正确的。

如果您的问题与超时 sl_Connect()有关(我无法100%确认这一点)，则很难通过非阻塞方式建立 TCP 连接。 是的、此 API 具有非阻塞模式、但在 MQTT 等更高级别的库中实现这种非阻塞方式将会非常复杂。 这将是在代码中使用这个更高级别的库的非常复杂的方法。 非阻塞套接字的使用不是很复杂的 CC32xx 套接字接口、但也不是其他 TCP/IP 堆栈。 例如 Netx duo……

但我猜这个问题与 sl_Connect()有关可能是错误的。 您将需要使用调试器来确定 MQTT 库的哪个部分导致了此延迟。

1月

我也不知道有任何此类问题。

您可以检查 TI MQTT 代码(在 source/ti/net/MQTT 下)-没有任何东西会阻止第二个 SPI 被使用。

请注意、在发送"已发布"消息时、SPI 我们使用互斥量和信标(在 simplelink 驱动程序内)-但它们仅保护 simplelink 驱动程序内部的执行(以及对其 SPI 的访问)、不应影响其他外设。  

问题可能 与 上层(应用程序)代码中的某个内容有关。