我在应用CH372中遇到了如下附件中的问题,请帮忙解决下!UploadImages/200961917362414.doc
延时肯定是不用加的,应该是程序上的问题了,关于速度的,可参考\CH372EVT\PUB\CH375451.PDF:⑸、参考资料及例子 下载CH372EVT.ZIP,参考\CH372EVT\PUB\BULK下的上下位机测速程序流程
这个是流程出现问题了,你不需要主动的去读USB数据,因为MCU不知道什么时候数据会来,正确的方式是等待中断,每次产生USB_INT_EP2_OUT:的中断状态就说明有数据了,需要去读.所以您说的延时是不对的,所以基本可以判断是您下位机出现问题了. 至于另外36S哪去了,是因为您只计算了延时,没有计算数据通讯也是需要时间的. 至于数据没有发完就返回了,就是因为上位机超时退出了,所以最小包是不确定的. . 为了能够及时的给您解决问题您可以拨打电话:02552638370(下位机),02552638376(上位机)
我看到了公司给提供的MCU程序,是采用中断方式处理的。可是我们老板在设计的系统中不允许中断(为了不影响其他功能)所以采用的是查询方式。而且我看了CH372 芯片资料上也支持查询方式呀。我们设计的是上位机通过命令控制下位机工作,所以下位机初始时就是等待上位机发送命令,然后执行相应的操作(包括执行各功能或返回数据等,其中可能会有64K字节数据需要传送)
理解上有问题,中断方式和查询方式没有什么本质区别.就是查询一个引脚.是支持查询方式,CH372有中断事件就是把INT引脚拉低,至于你MCU里面是查询还是中断CH372不可能去关心的. 你必须查询这个INT引脚是否有低电平,有低电平就说明有中断,然后去处理中断就可以了.肯定是你MCU端程序有问题.按照我们提供的中断函数来写,以免产生不必要的麻烦.
您好现在我由PC机下传128个数据,用示波器测量CH372的INT引脚,发现始终为低电平导致程序陷入死循环。 在向CH372发送CMD_GET_STATUS命令后,INT引脚会自动恢复高电平吧?INT引脚是在接到这个命令后就恢复还是要等待发送的数据(1包)完毕后在恢复呢?
发送CMD_GET_STATUS命令之后INT#引脚自动拉高.如果是下传128个数据的话,那么会产生2次中断.每次中断状态都应该为批量端点下传数据.
在发送128字节时测INT引脚始终为低电平,发送CMD_GET_STATUS命令后也不恢复,请帮忙解决下!十分感谢! 这是我写的初始化和接收程序,我们用的时philips的XA芯片 ;************************************************************** ;检测ch372与ch372初始化程序:用到资源r0,r1,r3,r5,r6 ;r0发送测试数据,r3回读数据,r5数据端口地址,r6命令端口地址 ;************************************************************** ch372_check: push.w r0 push.w r1 push.w r3 push.w r5 push.w r6 push.b ES mov.b ES,#SYS_SEG
ch372_check1: mov.w r6,#USB_WR_CMD mov.w [r6],#CMD_CHECK_EXIST ;命令 mov.w r5,#USB_DATA_ACCESS mov.w r0,#0055h ;测试数据 mov.w [r5],r0 ;发送数据 mov.w r3,[r5] cpl.w r0 cmp.b r3l,r0l beq check jmp CH372_RESET check: jmp check_ok mov.b r1l,#50h ;用于多次重发命令 CH372_RESET: mov.w [r6],#CMD_RESET_ALL ;复位命令 ;加延时40ms djnz r1,CH372_RESET ;试验检测能够通过,所以没加延时 call point_led5 ;等闪烁指示CHECK没通过 jmp ch372_check1
check_ok: pop.b ES pop.w r6 pop.w r5 pop.w r3 pop.w r1 pop.w r0 ret
;*********************************************************************** ;CH372初始化程序:所用资源:r5,r6,r0 ;r5数据端口地址,r6命令端口地址,r0回读状态数据 ;*********************************************************************** ch372_init: push.w r5 push.w r6 push.b ES mov.b ES,#SYS_SEG mov.w r6,#USB_WR_CMD mov.w r5,#USB_DATA_ACCESS mov.w [r6],#CMD_SET_USB_MODE mov.w [r5],#02h ;发送工作模式 ch372_init1: mov.w r0,[r5] cmp.b r0l,#CMD_RET_SUCCESS ;初始化成功判断 bne ch372_init1 pop.b ES pop.w r6 pop.w r5 ret
;******************************************************************* ;接收中断:所用资源:r0,r1,r3,r4,r5,r6 ;r0读回地址状态数据以及接收数据长度,r3发送数据首地址 ;r4读INTU数据地址,r5数据端口地址,r6命令端口地址 ;******************************************************************* my_receive: push.w r0 push.w r1 push.w r2 push.w r3 push.w r4 push.w r5 push.w r6 mov.b ES,#SYS_SEG mov.w r6,#USB_WR_CMD mov.w r5,#,#USB_DATA_ACCESS mov.w r4,#000eh ;扫描INT引脚的地址
mov.w r2,#1ffeh ;接收长度保存地址 mov.w [r2],#0000h ;先清零
receive1: mov.w r0,[r4] ;读取该地址的内容给r0,r0.0为int引脚 jb r0.0, receive1 ;不断扫描int引脚 mov.w [r6],#CMD_GET_STATUS nop nop nop nop nop nop mov.w r0,[r5] ;读回状态判断是什么中断 nop nop nop nop cjne.b r0l, #USB_EP2_OUT, receive1 ;USB_EP2_OUT
ch372_down_ok: mov.w [r6],#CMD_RD_USB_DATA nop nop nop nop nop mov.w r0, [r5] mov.b r0h, #00h cmp.b r0l, #00h beq receive1 ;发送长度为0重新等待接收 mov.w r2, #1ffeh add.w [r2], r0 ;保存接收数据长度(1ffeh) ch372_down_1: mov.w r1, [r5] ;接受数据 mov.b [r3+], r1l djnz.b r0l, ch372_down_1
call delay_30ms ;我们这里测试中要加入这段延时程序才能正常接收大于64字节的数据,不明白为什么? mov.w r4, #000eh mov.w r0, [r4] ;接收后继续判断是否仍有接收的数据未完成 jb r0.0, receive_ret mov.w [r6],#CMD_GET_STATUS nop nop nop nop nop nop mov.w r0,[r5] ;读回状态判断是什么中断 nop nop nop nop cjne.b r0l,#02h,receive_ret ;USB_EP2_OUT jmp ch372_down_ok ;仍有数据继续接收,否则推出 receive_ret: pop.w r6 pop.w r5 pop.w r4 pop.w r3 pop.w r2 pop.w r1 pop.w r0 ret
这是我在试验中编写的程序,我们是不断搜索INT引脚,不去响应其他请求。帮忙看看由什么不对活不足之处,谢谢!!!!
首先如果你可以检测到INT#引脚为低电平的话,那么,你就在那边循环的发送0X22的命令(获取中断状态命令),不去做任何事情,这样你在看下INT#引脚会拉成高电平吗?如果没有的话,建议你还是先做测试命令,先发0X55数据,看下返回的是否为0XAA,在发送0XAA数据,看是否返回0X55.这样才能确保你的并口硬件没有任何问题
call delay_30ms 我们这里测试中要加入这段延时程序才能正常接收大于64字节的数据,不明白为什么? mov.w r4, #000eh mov.w r0, [r4] ;接收后继续判断是否仍有接收的数据未完成 jb r0.0, receive_ret
发送128个字节应该有两次中断产生的,不应该接收完本次64字节,然后马上在取下面64字节,我们在上面已经说明了,你应该不断的去查询INT脚,有中断则去处理中断,中断中去读取数据,不应该主动的去读数据,而是有数据了才去读,有数据过来,会中断通知的.因为数据过来是不定时的,可能会慢也可能会快,这跟总线空闲是有关系的.
看到楼主帖子中的实际需要,建议楼主考虑改用CH341,既可以大大地简化程序,又能够有效地解决实质问题。
先谢谢各位,这几天发现是硬件的有些问题,MCU晶振有点高导致读写地址时出错了,非常感谢各位!