你好，如果能够把错误的输出截个图发出来就更好了

@xddl00 正解！

@xddl00 我大概懂了，层主在主线程中有一个停机的操作，但是主线程中会有很多的延时。但一般来说停机这种都是会单独有一个故障维护线程，这个故障维护线程以一个比较低的延时在不断轮询，如100ms，这个

@xddl00 可能我理解错意思了，我以为层主是说500ms太慢了，无法满足立即停机的需求，但好像层主不是这个意思，能解释一下层主最终是想达到什么效果吗

没错，这种情况下确实是要等延时完成才能停机，理论上要做到非常及时应该是需要用到中断，如果是使用这种轮询检测的方式必然会有一段时间是无法响应的，不过降低延时时间也是一种方法，比如每5ms检测一次，就能达

具体一点呢

摘自 RT-Thread 官方文档。原文链接

看了一下题主成功的map文件，最后的统计数据如下：可以看到总的ROM大小已经到达了508.68kB,也就是说在题主成功的状态下flash已经占用了508.68kB，而Pandora开发板的flash总

题主检查一下在调用 free 的时候传入的地址是否是已经释放过的内存地址，或者是非 malloc 动态申请的内存地址。

比如说我需要通过串口输入一个DNS地址：串口输入对应DNS地址。程序中得到串口输入的字符串，并且通过ipaddr_aton将字符串转换为ip_addr_t结构的DNS地址变量。调用 dns_setse

可以通过如下方式添加多个DNS地址dns_setserver(0, &dns_s0); dns_setserver(1, &dns_s1); dns_setserver(2, &

@xinxinDady 不客气!

netdev 组件中会默认导出 ping 功能支持，如果使用系统中包含并开启 netdev 组件，该配置选项在 ENV 中将不会被显示。请题主确认一下是否开启了netdev组件?

题主提到的执行过程中被切走其实并不是导致通讯失败的根本原因，因为最终还是会回来继续执行，但是执行过程中被切走就可能导致通讯帧错误，帧超时这种问题，而这些才是导致通讯失败的本质，而且其对应解决方案也是不

首先得弄清楚通讯失败的本质是什么，也就是到底是哪个处理导致的RTU通讯失败，如题主描述的被高优先级任务切走这个机制本身并不会导致通讯的失败，如果题主能够定位本质问题的话也就能提供对应的解决方案了。