完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
看了EVT发现回复握手包在Init函数中已经设置好了，每次中断都自动回复ACK数据包。
void USB1DeviceInit( void) R8_UEP1_RX_CTRL1 = UEP_R_RES_ACK| bUEP_AUTO_TOG; 但在接收数据包的时候，需要根据判断回复握手包该怎么处理呢？例如根据判断，选择性的回复ACK、NAK或NYET。 
0
|
|
相关推荐
3个回答
|
|
|
RX对应OUT事务，正常情况下状态阶段是设备给主机，贴出的代码的意义是当主机发起OUT事务时，相应ACK，事务完成芯片会进中断。根据例程中断函数中内容，会进入端点1 OUT的处理分支。
|
|
|
|
|
|
谢谢，请问下：
1、按照例程的代码，如果在中断里设置握手包，则是在下次包传输的中断生效。例如以下代码，在第一次向端点1OUT时是应答ACK(在中断函数时已经完成应答)，并产生中断，在中断函数中将握手包设置为NYET，下一包OUT的数据则回复NYET。现在的问题是，如何在传输过程中，根据当前OUT的数据进行逻辑判断，选择不同的握手包进行应答？例如在收到端点1OUT数据时，根据数据包内容进行判断，选择应答为NYET、ACK或者NAK等等。目前想到的办法只能是推测下次令牌包的请求，提前进行应答设置。请问这个该在哪个步骤可以实现呢？ 令牌包：OUT 数据包：空 握手包：需要实时应答NYET、ACK或者NAK void USB1DeviceInit( void){ R8_UEP1_RX_CTRL1 = UEP_R_RES_ACK| bUEP_AUTO_TOG; void USB1DevIntDeal(void){ if ( (R8_USB1_INT_FG & UIF_TRANSFER)) { if(intstatus == (UIS_TOKEN_OUT|1)){ R8_UEP1_RX_CTRL1 = UEP_R_RES_NYET| bUEP_AUTO_TOG; 2、在批量传输过程中，发现主机向设备发送OUT或IN令牌包，在设备通过中断回复NAK时，主机不再进行请求。通过Printf调试输出显示，只发生了一次中断，但通过抓包显示，主机一直向设备请求IN或OUT，只是没有发生中断事件，请问这个是什么原因造成的呢？ 按照例程，在中断函数的结尾有R8_USB1_INT_FG = 0xFF; |
|
|
|
|
|
一个原则，该次事务的中断，是在事务完成之后产生的！所以我们都是在事务开始之前就准备好端点的应答状态。
问题1、实际的USB传输都是有协议支撑的，所以你永远知道接下去应该IN 还是 OUT，当然SETUP是设备强制一定要接收的。所以不是推测下次令牌包的请求，而是根据标准协议来准备应答状态，或者自定义可靠的交互逻辑。 问题2、根据中断产生时间点的原则，再看看这个问题呢 |
|
|
|
|
只有小组成员才能发言，加入小组>>
477 浏览 1 评论
CH579M+RT-Thread，RTC从Sleep模式唤醒失败是什么原因？
2874 浏览 2 评论
2361 浏览 1 评论
818浏览 2评论
CH569通过HSPI实现USB3.0和FPGA高速双向通讯
645浏览 1评论
500浏览 1评论
CH32F103C8T6使用当前官网上的CDC例程会出现设备描述符请求失败
365浏览 1评论
642浏览 1评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
695
评论
淘帖
818
