ueJone

> 我这边也出现同样的问题， 原因我这边大致找到了，在打印堆栈调用信息的地方，如果使用的是ulog日志模块，那么打印不出来，只需要 print_call_stack 函数中， > cmb_println(print_info[PRINT_CALL_STACK_INFO], fw_name, CMB_ELF_FILE_EXTENSION_NAME, cur_depth * (8 + 1), call_stack_info); 中， cmb_println 替换成 rt_kprintf，堆栈调用信息就可以打印出来了。 有道理，系统崩溃的时候ulog线程不一定能跑，谢谢提醒，我验证一下您的方法。

哇原来有啊，之前现在L4的芯片上移植没找着头绪，我看下资料，谢谢楼主

> 有哇： > http://blog.xtoolbox.org/add_teenyusb_to_cubemx_project/ 楼主，这篇文章是不是不太适用新版的tusb了呢，新的tusb在usb_stack多了很多文件。或者说usb_stack目录下并非所有文件都需要加到工程中？我移植过程遇到了下面的问题： 把usb_stack目录下的所有源码添加到工程目录下，编译的时候usb_stack/inc/stm32_otg_platform.h会提示缺少board_config.h board_config.h好像都是demo里做的bsp，demo里的board_config.h没有和我相似的芯片，需要您指导一下board_config.h中接口定义

“teeny_usb_init.h”也是在demo目录下，建议楼主把tusb的协议栈都归类到一个目录下，然后说明哪些接口需要用户来实现，这样方便移植

> > > 有哇： > > > http://blog.xtoolbox.org/add_teenyusb_to_cubemx_project/ > > > > > > 楼主，这篇文章是不是不太适用新版的tusb了呢，新的tusb在usb_stack多了很多文件。或者说usb_stack目录下并非所有文件都需要加到工程中？我移植过程遇到了下面的问题： > > 把usb_stack目录下的所有源码添加到工程目录下，编译的时候usb_stack/inc/stm32_otg_platform.h会提示缺少board_config.h > > board_config.h好像都是demo里做的bsp，demo里的board_config.h没有和我相似的芯片，需要您指导一下board_config.h中接口定义 > > 是的，那篇文章在写的时候用的时比较老的TeenyUSB，那个时候还没设计类驱动。现在新的TeenyUSB可能不太适合了，我后面会更新一下那篇文章。 我基于demo中的drd_rtt，最后总算是能识别设备了，说下我移植过程遇到的最头疼的地方吧： 1. usb初始化部分都是直接用的寄存器接口 2. USB的IO配置也是使用寄存器 3....

> 其实可以使用在线代码生成器,可以直接生成对应的配置的.https://jiejietop.gitee.io/mqtt/index.html 有了解过这个工具，楼主用心啦。不过配置工具有局限性，在动态修改参数的场合不适用，而在参数固定的场景配置工具那是真的方便

> 等有空了，更新一下版本^_^ 给作者加加油 O(∩_∩)O

``` rc = mqtt_read_packet(c, &packet_type, timer); switch (packet_type) { case 0: /* timed out reading packet */ /*when mqtt closed by server, funtion mqtt_read_pacek return no delay time, so add...

> 因为Mqtt有一个线程来处理网络的连接与断开 明白您的意思，说下我的理解：之所以无法进行线程切换是因为socket断开后没马上释放socket而是在连续recv()，此时recv不会阻塞而是立即返回从而导致了线程一直占用cpu。再来看下面代码，对socket断开即`nread == 0`未作处理。感觉在检测到socket断开时立即释放socket比较好，不过我对这个库的逻辑还不熟悉，能不能在此处释放还请指教 ``` int platform_net_socket_recv_timeout(int fd, unsigned char *buf, int len, int timeout) { ... platform_net_socket_setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof(struct timeval)); while (nleft > 0) {...

> 这里读取socket返回0时，表示未读取到数据，可能是原因是socket连接正常，mqtt服务器端没有发送数据，或是网络线路故障，服务器发送的数据没有正确传输到mqtt客户端，所以这里就不能断开socket连接。Socket的正常通信时的连接断开要通过检测keepalive超时来断开。如果服务端主动断开了连接，读取socket会返回-1，mqtt线程会立即进行重新连接。 目前的mqtt库的socket连接断开的处理已经比较合理了，可以满足大部分应用，不建议在这种地方做这么小的优化了，而且你对整个通信机制没有深入的理解，很难优化的更好。 发送自 Windows 10 版邮件应用 发件人: ueJone 发送时间: 2021年1月16日 9:47 收件人: jiejieTop/kawaii-mqtt 抄送: longteng; Author 主题: Re: [jiejieTop/kawaii-mqtt] 解决个别异常网络情况下的稳定性 (#2) 因为Mqtt有一个线程来处理网络的连接与断开 明白您的意思，说下我的理解：之所以无法进行线程切换是因为socket断开后没马上释放socket而是在连续recv()，此时recv不会阻塞而是立即返回从而导致了线程一直占用cpu。再来看下面代码，对socket断开即nread == 0未作处理。感觉在检测到socket断开时立即释放socket比较好，不过我对这个库的逻辑还不熟悉，能不能在此处释放还请指教 int platform_net_socket_recv_timeout(int fd, unsigned...