完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
当我们以 576000 的波特率向其发送数据时,ESP8266有时会给出 Rx OVF。它似乎没有出现在 115200 中。CTS (MTD0) 是否适用于ESP8266? 我们使用 4.7k 电阻拉下该引脚。它会影响任何事情吗?
AT version:0.30.0.0(Jul 3 2015 19:35:49) SDK版本:1.2.0 编译时间:2015-7-20 18:15:27 OK ESP8266设置为处理流量控制 在 uart_cur=576000,8,1,0,3 我们仅在收到 SEND OK 后发送新数据。 AT+CIPSTART=0,"TCP","xxx.xxx.xx.xxx",8888 0,连接 OK 在 cipbufstatus=0 0,21,20,20,2920,8 OK 在 cipsendbuf=0,1400 21,20 OK > 接收 1400 字节 0,21,发送OK 在 cipsendbuf=0,1400 22,21 OK > 接收 1400 字节 0,22,发送正常 在 cipsendbuf=0,1400 23,22 OK > 接收 1400 字节 0,23,发送正常 在 cipsendbuf=0,875 24,23 OK > |
|
相关推荐
1个回答
|
|
CT S(Carrier Sense Time)是一种硬件流量控制方法,用于在通信设备之间管理数据传输。然而,ESP8266主要使用软件流量控制,如XON/XOFF。尽管CT S可以在某些情况下使用,但它并不是ESP8266的标准配置。
关于您提到的Rx OVF(接收溢出)问题,这可能是由于数据传输速率过高导致的。在576000波特率下,ESP8266可能无法及时处理接收到的数据,从而导致溢出。在115200波特率下,数据传输速率较低,因此不太可能出现溢出问题。 关于CTS(MTD0)引脚,使用4.7k电阻将其拉下是正确的做法。这将确保引脚保持低电平,不会影响ESP8266的正常工作。然而,由于ESP8266主要使用软件流量控制,CTS引脚的实际作用可能有限。 为了解决Rx OVF问题,您可以尝试以下方法: 1. 降低波特率:尝试使用较低的波特率,如115200,以减少数据传输速率,降低溢出风险。 2. 优化数据发送策略:确保在发送新数据之前,ESP8266已经成功接收并处理了之前的数据。这可以通过检查AT命令的响应来实现。 3. 检查硬件连接:确保您的硬件连接正确,没有损坏或接触不良的问题。 4. 更新固件:您提到的AT版本和SDK版本相对较旧。尝试更新到较新的版本,以获取可能的性能改进和bug修复。 5. 使用软件流量控制:考虑使用XON/XOFF等软件流量控制方法,以更好地管理数据传输。 总之,虽然CTS(MTD0)引脚可以用于ESP8266,但其实际作用可能有限。为了解决Rx OVF问题,您可以尝试上述方法,并确保您的硬件和软件配置正确。 |
|
|
|
只有小组成员才能发言,加入小组>>
1132 浏览 1 评论
576浏览 6评论
477浏览 5评论
有没有办法在不使用混杂模式的情况下实现Wifi驱动程序接收缓冲区访问中断呢?
461浏览 5评论
462浏览 4评论
435浏览 4评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-21 18:08 , Processed in 1.005798 second(s), Total 77, Slave 61 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号