如题，使用官方例程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对蓝牙连接的影响更为明显。

                                                撰写回复...