你好，我使用ch582做串口透传，遇到一个问题，请帮忙解答一下，串口使用38400 57600 115200波特率，只要外部设备通过串口持续给ch582发数据，ch582蓝牙很快就会断线，9600波特率没有问题，是不是因为ch582不停在串口中断中接收数据导致协议栈不能正确处理导致的？如果是这个原因，有解决办法吗？我使用ble_uart例程修改串口引脚下载到我的板子上去跑也是一样的现象。

 你好，使用BLE_UART例程，我们这里测试例程没有出现断连的情况。需要注意的点是，串口发送的时长建议大于连接间隔，单次发包的数量建议小于MTU。如果数据量传输比较大，则可能出现丢包的情况。

可以查看蓝牙的断开原因是多少。

谢谢这么及时的回答，串口发送的时长建议大于连接间隔，这句话具体是什么意思呢？我又测试了一遍，发现同样的代码在开发板上确实不会断线(ble_uart和我自己的代码都不会断)，最多发的太快，数据太多，丢数据而已，但是在我的板子上发同样多的数据就会断线，是不是我的板子信号不太好(空间限制，用的陶瓷天线)导致的？

这样的天线布局有没有问题？

发现是另一个mcu的spi工作(读取flash数据通过串口发给582)的时候影响了 天线信号，现在ch582串口不初始化，只要spi工作也是会断线。

另一个芯片的SPI与582是否有连接，如果没有连接，则其他芯片的SPI理论上是不会对582的无线部分产生影响的。

你可以测试另一颗MCU通过串口发送固定数据给582，且不操作SPI，判断是否SPI影响的断开。

如果确定SPI影响，可以发送邮件至lpc@wch.cn，描述一下数据收发逻辑和原理图，我们查看一下。

哇，天线这么靠近天线没问题么？天线也不规范啊信号都发不出去直接辐射到主芯片、晶振、spi芯片上咯。

信号是有点差(空间太紧凑了)

我再测试了一下，确认不是spi影响的，是另一个mcu通过串口发数据影响的(串口与ch582连接)，串口波特率越高越容易导致蓝牙断线(断线原因是8)，我是这么测试的，ch582不做任何事情(包括串口收发全部关闭)，Main_Circulation()只运行TMOS_SystemProcess()，还是一样断线，另一个mcu串口不发数据就不会导致蓝牙断线(spi可以一直读flash数据不影响)，另一个mcu在天线的背面(不知道是不是会影响天线)

另外我是不是可以考虑使用ch32f208一个芯片来替代这两颗芯片的功能，看到说这个芯片flash又掉小，协议栈就要占用大部分快速flash，如果放到慢速flash是不是特别的慢，还有这个芯片是正常供货吗？感觉使用的不多。

1、BLE_UART例程，接上串口透传数据后，串口的速度只会影响丢包，不会影响断连。因为多出来的包是被丢了；

2、如果判断为串口数据收发，则建议使用peripheral例程，然后外接CH340，查看是否会出现断开。从理论上分析这也不会导致蓝牙断开；

3、根据上述提供的信息，串口走线走在了天线背面，这是不建议的走线方式。天线背面不要有任何走线。如果走串口线在数据收发的时候有高低电平，出现问题是不可预知的；

4、CH32F208/CH32V208是MCU+BLE的芯片，稳定出货，可以尝试替代MCU，资源如图。FLASH有480K，160K的快速FLASH+320K的慢速FLASH。蓝牙协议栈占用的大部分是慢速FLASH，因此快速FLASH的100K+基本都是可以自行配置使用。

总结：建议天线部分的走线重新绘制，芯片的背面/天线的背面/ANT馈线的背面不要有任何走线。天线绘制参考：CH57x/CH58x原理图与PCB绘制 - SweetTea_lllpc - 博客园 (cnblogs.com)

感谢你的耐心解答，同样的代码在开发板上外接usb转串口连接电脑是不会断线的，最多发的太快丢数据而已，应该是影响了天线导致断线的，我们考虑一下是否使用CH32F208来替代，再一次感谢！