完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
发现用CH392GetRecvLength获取长度,CH392GetRecvData读取数据后,接收缓冲区的数据任然保留着,于是在CH392GetRecvData读取数据后,主动用 CH392ClearRecvBuf 清除该socket的接收缓存,但是无效,这可能是什么原因造成呢
我的应用轮询读CH392接收缓冲区的有效数据长度,有数据就进行处理,实际没有用到中断,是这种方式不可行吗? 我用的淘宝买的以太网模块,spi接口,读到的芯片版本23.又发现2个问题
|
|
相关推荐
1个回答
|
|
“我的应用轮询读CH392接收缓冲区的有效数据长度,有数据就进行处理,实际没有用到中断,是这种方式不可行吗?”,这种方式不太合理,会很占用CH392的处理,正常情况是读出数据后缓冲区数据就会自动清空。
|
|
|
|
只有小组成员才能发言,加入小组>>
463 浏览 1 评论
CH579M+RT-Thread,RTC从Sleep模式唤醒失败是什么原因?
2868 浏览 2 评论
2357 浏览 1 评论
808浏览 2评论
CH569通过HSPI实现USB3.0和FPGA高速双向通讯
630浏览 1评论
492浏览 1评论
CH32F103C8T6使用当前官网上的CDC例程会出现设备描述符请求失败
356浏览 1评论
630浏览 1评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-11-22 07:27 , Processed in 0.977896 second(s), Total 77, Slave 60 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号