如题,使用官方例程FATS加入蓝牙广播,并使用手机连接;在主循环1s调用一次fwrite每次写入4096字节,发现蓝牙会自动断开连接,将这个写入字节数降低至每秒512,影响较小,但还是有;初步认为是spi0写sd卡有阻塞,影响了蓝牙协议栈的调度,求教大神指点下这个SPI优化思路该如何做,因为SPI初始化已经使用的非阻塞模式了。。。。在我看来,即便直接在用户程序里while(1),也不会影响蓝牙连接的呀,所以请教下有经验的各位,能否指点下fats的优化思路。感激不尽!

    treh2014 尝试把连接超时改大。还有可以统计一下写完4096字节要多长时间。如果写入这4096字节的数据?在哪里写?其次,spi时钟是多少?

    SPI配置
    fwrite在主循环while里面1s调用一次
    目前连接超时4s,试过改成8秒或30秒,依然会自动断开连接(蓝牙不发送数据,仅仅测试能否保持连接),写入4096字节耗时还没测试。。。。

    Wireless-Tech

      treh2014 你好

      1. 连接超时时间改大了是否验证已经改成功了,有没有改善?还是同样的时间点就断开了?
      2. 能否提高spi写入sd卡的速度?是不是用了dma?
      3. 那个写入时间还是测试一下吧
      4. 是否使能了带协议栈的读写sd卡操作?

      按理协议栈对于占时比较久的操作是做过处理的。

        Wireless-Tech 谢谢大佬解答,1、2点已经验证过了,开了easyDMA的,然后蓝牙掉线应该是直接写入4096字节对于底层应该是一个连续循环调用导致频繁进入spi中断函数导致的

        ,目前按512字节写入,每次延时510ms连续写八次(共4096字节)情况好转很多,但不能根除蓝牙不稳定的现象。对于第4点。还请指点下协议栈的sd操作使能宏是哪个呢?这是我目前的spi使能宏

          你用的哪个工程,我看看

          Wireless-Tech sdk15.2->examples->peripheral->fats,基本上是根据这个根据工程+蓝牙串口透传从机例程修改的

          工程大于50M传不上来。。。。。

            Wireless-Tech 我把测试工程放在了百度网盘里,大佬有时间可看下,这个测试工程我修改了UUID和UUID TYPE,主循环每1000ms写入一次数据,可以用手机连接明显看到蓝牙根本没法用,将写入字节数和频率调低可以缓解这个现象,但不能根除。。。
            链接:https://pan.baidu.com/s/1IMie31P1At2FriuYe9Rp8Q
            提取码:4gvx
            复制这段内容后打开百度网盘手机App,操作更方便哦

              treh2014 这个就足够了,我们手上没有你的板子,也没有办法去调试

                Wireless-Tech 好的,谢谢啦

                  treh2014 由于没有你们的硬件,根据你百度网盘的工程。我查看了一下,有如下几个建议:

                  • APP_SDCARD_FREQ_DATA配置成8MHz再次试试
                  • 请确认,断开连接时是谁发起的,手机app还是从机?
                  • 连接成功之后,请查询当前的连接间隔以及超时连接的时间。在此之前,请不要对SDCARD进行操作。如果连接间隔过小而且超时连接时间也过短则应发起连接更新请求。
                  • 请确认SPI最终的时钟速率是多少?

                    Wireless-Tech 谢谢大佬耐心解答
                    1.nrf52832配置成8M和4M对试验结果没有影响,因为蓝牙依旧会断开。原因在下面第二点
                    2.根据你的2.3提示,我着重查询断开连接的原因,发现用nrfCONNECT并不会频繁断开连接,但是接收明显卡慢,因此考虑断开由主机发起;由此修改了程序里的 连接更新由30秒改为15s,重新连接后,不再断开连接。
                    3.这样改动虽然解决了蓝牙掉线问题(或者说延缓了),但是如果每秒一次性f_write 4096字节,同时用蓝牙发送固定数据240byte/30ms,从 主机端的接收数据分析,明显可以看到蓝牙接收有卡顿,但是数据并没有丢失或错乱,如果蓝牙发送不使用定时发送,而是直接在主循环测试连续发送蓝牙数据,依然会有掉线情况。但总体比之前好很多了

                    目前spi配置 125K+8M

                      treh2014 Thanks for your feedback. 我不建议在写SDCARD时,还进行BLE透传的动作。如你所说,此时会出现卡顿甚至有可能出现丢包出现。建议在应用层应该尽可能的避免同时出现SDCARD操作和透传的动作。如果实在没有办法,您可以尝试将连接间隔改小。你说的这个原因并不是本质的问题根源。那个更改只是将连接间隔更新请求时间提前了。实质你还是需要看看你的更新连接间隔参数的合理配置。规则就是:连接间隔减小->超时时间变大。

                      注意:你还需要注意的是就算你发起了连接更新请求,这不就百分百意味着主机端就会百分百采纳,你还要是去查询下当前的连接间路和超时时间最终是多少。

                      好的,谢谢啦😁

                        Wireless-Tech 调试了几天,总结下经验吧。
                        目前没能找到根治nrf52832的蓝牙透传和spi中断冲突的办法,只能说有缓解这种冲突的心得。
                        1.对于SD卡的数据存储操作,在不改的官方的fats spi底层驱动情况下,使不使用FreeRTOS对最终结果影响不大。如果有大神对此有优化心得,希望分享下。
                        2.建议避免或频繁的执行fopen->fwrite->fclose流程操作,实际上如果每次存数据都使用这个流程,将放大对蓝牙连接/蓝牙数据传输的影响。
                        3.一般应用下,即便打开文件后连续写入,不执行关闭动作,经测试每次fwrite的字节也不要超过200字节,调用fwrite尽量保持在20ms及以上频率,否则蓝牙连接很可能不能保持;如果必须一次写入几K数据,就需要加快更新连接参数的频率,效果嘛,不好说,虽然暂时未发现断开连接,但影响蓝牙发送数据是肯定的,自求多福。。。。
                        4.实际上单单连续执行fwrite函数,不执行f_sync函数或fclose同步数据,SD卡文件里是没有数据的。。。。所以还需要考量f_sync函数的同步,最好在蓝牙未连接时进行同步,连接状态下不同步,不然。。。。。还是会有影响。
                        5.第四点的原因,比起fwrite,函数f_sync对蓝牙连接的影响更为明显。

                        撰写回复...