【已解决--驱动设计与使用方式差异】tuyaOS模组WBR3 SDK3.5.3串口收发严重BUG

[jafatek]

对于第一个问题：我不这么认为，我看到串口的配置中也有流的配置 如果我的串口配置成流的模式 那么我不关心单次收到的数据长度 ，但是我目前的串口是关闭流模式的 我不可能还像流模式那样收取串口数据 串口发送和接收应该是稳定的 不能被打断的 发送了一帧数据 如果不是流模式 是不能多帧收的 我想这是最基本的 应该在串口底层设置锁或者其他。 第二个问题 我想也和这个有关 应该都是在刷串口缓存的时候出现了问题 我这边改一下代码 然后我在上传一下视频 第一个问题 还请=专家好好考虑 串口模式不是流模式的时候不应该按照流模式那样接收

[jafatek]

我以按照你们的要求提供了代码 建议你们用我的代码测试一下 即可复现问题，我代码中只有串口初始化是 对底层串口做了配置 其他代码 都是应用层的自有功能逻辑的实现

[卢台长]

大佬您好，说一下我的看法

1. 流模式是解决，双方处理速度或者内部缓存不对等的情况下，可以通过RTS/CTS（硬件的流模式）进行控制串口发送

2. 有些芯片是按您理解的机制处理的，例如通过串口空闲中断，完成一帧数据的接收，其次软件上也可以通过阻塞接收模式确保收到的长度，这样的方式都存在一定局限性，硬件串口需要空闲中断，或者软件需要等待指定的数据长度，如果中途因为干扰等原因漏接收了，即使通过下一帧数据收到指定的长度，这样的包在应用上解析也有问题

3. 涂鸦提供的串口接收是只保证把接收的数据存到内部环形缓冲中，所有在串口上的协议都需要在应用上按自己定义的帧格式进行处理。这样应用可以做到跨平台，而不依赖串口驱动

总的对于应用协议来说，只需要通过串口读数据就行，而不关心是否单次能接收完成，通过协议自身机制来完成解析或者超时处理

祝您生活愉快！

[jafatek]

感谢你的发言
我指的流模式不是硬件上的流模式 是数据流的意思
你对涂鸦的理解也很到位，涂鸦可能也是这么想的
如你所说 串口接收的问题可以通过应用层去规避 这个没有问题，但是有一个场景如果双方都是定周期通信，通信周期很紧密的情况下，如果双方不是同时开始，会导致我在应用层的处理时间延长，因为我要在串口的接收队列中找到有效帧。应用层的处理时间延长，会导致串口数据的缓存的溢出
有一个在用的方案：串口的波特率配合定时器，串口在开始接收的时候 就开启一个定时器，定时器的时间就是波特率的时间，超时就表示收取了一帧，这个定时器的超时中断映射到串口数据接收中断 我想可能会比现在的串口数据有消息通知的中断要好一些吧 （现在是有消息 但是多少不确定 是否一帧也不确定，但是定时器的方案 会明确告诉你 是一帧数据）
比较严重的问题是串口发送的问题 串口发送的问题会出现粘包现象

[jafatek]

问题已解，我在串口发送的时候清了队列，并多了一个检查，目前测试没有出现粘包问题。串口接收在应用层中做了处理规避，但是还是希望后续能开放原生接口 或者中断通知能告知完整的一帧

[愚者千虑必有一得]

大佬非常专业，你的意见我们会考虑吸取。在后续的代码中改进。

我们非常欢迎大佬这样的专业开发者，能够发现问题，提出问题，大家共同进步。