补充一下：由于之前(上面)的测试(包括最近的一些项目应用)，littlefs都是用在Nand Flash上，我们以120K大小为限，超过此大小就新建文件，并没有遇到过读写效率的问题，因此也没太关于这个

补充一下：由于之前(上面)的测试(包括最近的一些项目应用)，littlefs都是用在Nand Flash上，我们以120K大小为限，超过此大小就新建文件，并没有遇到过读写效率的问题，因此也没太关于这个

已报名，嘿嘿???

win10系统下压缩包解压之后打开提示有错误

littlefs的问题可以参靠我之前的这篇测试https://club.rt-thread.org/ask/question/423119.html目前我们的产品还会使用littlefs做文件系统，主

官方的OTA局限性有点大，而且不开源，完全跟RTT背道而驰了

要实现获取每个线程的利用率，这个算法估计是不行了，不能在每个线程里都搞个死循环吧，那还干不干活了可以换一种思路，利用一个硬件定时器，每个线程在进入与退出的时候获取一次硬件定时器的累加值，通过两个数值做

这个100ms只是在第一次上电的时候执行一次，获取到total_count的值，以后就不在执行了，count只在空闲的时候进行累加计算，并修正total_count的值，并不会一直执行的，要说实时性的

分析的很详细，学习了

我这个是在老版本的rt_thread上移植的，2.0的版本，很多年前的产品了，在新版本的rt_thread 4.0的框架中测试过，并没有此问题，所以就没往仓库中提交。估计是新版本修正了这个bug或者是

经过数据分析及对通信线路进行抓包发现，BC28返回值正常，且通信没问题，而at_device缓冲器用来与关键字对比的数据出现了异常，字符重复以致超出缓冲区长度，内容如下所示从图片看，右侧BC28返回数