用CH375V做host能正常讀寫U盤，但接MP3或USB軟驅(qū)無反應(yīng)連接中斷也沒有，燈也不亮， 從上電到等待連接只進(jìn)行過375初始化即設(shè)模式6且成功，理論上接上MP3即有中斷且燈亮可現(xiàn)在沒有，且D+與D-都為0V，設(shè)備端已測到有電壓,請問CH375V是3.3V的與這個(gè)有關(guān)嗎,還是375不能兼容別的USB接口,或是模式設(shè)得不對應(yīng)怎樣設(shè)置,在線等待謝謝!!

原因可能如下： Mp3或USB軟驅(qū)耗電過大，USB口供電足，Mp3或軟驅(qū)沒能正常工作，設(shè)備端上拉電阻沒能啟用，因此375V無法檢測到設(shè)備。USB口電最好大于4.7V

老大多謝了,就是CH375V是3.3V電壓不夠的原因,原來說375周圍都必須3.3V,就一直沒敢接5V,這次冒著375生命的危險(xiǎn)接了5V到MP3現(xiàn)在能跑了,多謝SCM

請問SCM,剛你說好多USB軟驅(qū)是CBI傳輸,能給點(diǎn)靈感嗎,怎樣把375傳成CBI傳輸,

具體實(shí)例沒有，只是看過一點(diǎn)協(xié)議。 如果你的軟驅(qū)支持BulkOnly協(xié)議，那么CH375+子程序庫就可實(shí)現(xiàn)操作軟驅(qū) 如果你的軟驅(qū)支持CBI協(xié)議，那么你得自己寫固件程序。 CH375芯片內(nèi)置BulkOnly協(xié)議固件，但沒有CBI協(xié)議固件。 建議你先了解USB大容量存儲(chǔ)類設(shè)備的傳輸協(xié)議。

CH375芯片內(nèi)置BulkOnly協(xié)議固件,如果寫CBI協(xié)議固件能在375上運(yùn)行嗎,或是得換別的芯片,現(xiàn)在USB軟驅(qū)連描述符也讀不出來就在那死等中斷了,按這樣說法它就真的是跑CBI協(xié)議了,回頭這協(xié)議我會(huì)了解的,就是想知道375能不能接受CBI協(xié)議來讀寫,現(xiàn)項(xiàng)目的目的是讀寫USB軟驅(qū)而不是U盤或MP3

CH375是USB通用接口芯片，與你用什么協(xié)議無關(guān)，可以實(shí)現(xiàn)你的要求。 讀取描述符的過程還沒涉及具體的傳輸協(xié)議，只與控制傳輸有關(guān)，沒能讀到描述符，可能是硬件或軟件還有一些問題，CH375DS2.PDF中有參考流程。 至于USB軟驅(qū)的具體協(xié)議，你可以用一個(gè)PC機(jī)軟件bushound去抓一下它的描述符，其中接口描述符中的傳輸協(xié)議代碼決定了傳輸協(xié)議類型，0x50表示BulkOnly，0x00與0x01表示CBI

我讀USB軟驅(qū)又出現(xiàn)問題了，下面是讀取它的設(shè)備描述符，可是它本身定義的數(shù)據(jù)包大小只有8個(gè)字節(jié)，當(dāng)再讀后面的數(shù)據(jù)時(shí)就沒有反應(yīng)了，讀得前8個(gè)數(shù)據(jù)為：12 01 00 02 00 00 00 08，幫我分析下就是DATA0與DATA1是怎樣處理交換的，還有用CH375_WR_CMD_PORT( CMD_GET_DESCR ); /* 控制傳輸-獲取描述符 */這個(gè)命令讀取USB軟驅(qū)沒有反應(yīng)（U盤和MP3能正常讀?。跃陀昧讼旅孢@個(gè)讀描述符， Request.Req.bmRequestType=0x80;//獲取設(shè)備描述符 Request.Req.bRequest=0x06; Request.Req.wValue=0x0001; Request.Req.wIndex=0x0000; Request.Req.wLength=0x1200;

unsigned char get_descr_ex() { unsigned char descr_len,i; unsigned char *p=buffer; unsigned char descr_cou_temp=0; endp7_mode=0x80; toggle_send(); wr_usb_data(8,Request.Req_buf); issue_token(( 0 << 4 ) | DEF_USB_PID_SETUP); status=mWaitInterrupt(); if(status==USB_INT_SUCCESS)/* SETUP階段操作成功 */ { endp6_mode=0xc0; toggle_recv(); } else return(0); issue_token(( 0 << 4 ) | DEF_USB_PID_IN); status=mWaitInterrupt(); if(status==USB_INT_SUCCESS)/* DATA階段操作成功 */ { descr_len=mReadCH375Data(buffer);//到這步得到前8個(gè)描述符 descr_cou+=8; descr_len=Request.Req_buf[6]-0x08;/*剩余描述符長度計(jì)算*/ while(descr_len>0) { toggle_recv(); p+=0x08; issue_token(( 0 << 4 ) | DEF_USB_PID_IN);//繼續(xù)讀剩下的描述符 status=mWaitInterrupt();//程序執(zhí)行上步后就沒有再收到中斷，而就一直停在這里 if(status==USB_INT_SUCCESS) /* DATA階段操作成功 */ { descr_cou_temp=mReadCH375Data(p); if(descr_cou_temp!=0x08){descr_cou+=descr_cou_temp;break;} else {descr_len-=0x08;descr_cou+=8;} } else return(0); } } else return(0); endp7_mode=0xc0; toggle_send(); wr_usb_data(0,Request.Req_buf); issue_token(( 0 << 4 ) | DEF_USB_PID_OUT); status=mWaitInterrupt(); if(status==USB_INT_SUCCESS)/* 狀態(tài)階段操作成功 */ return(1); else return(0); }

你第二次讀取描述符時(shí)，沒有切換接收同步標(biāo)志。

while(descr_len>0) { // 此處應(yīng)先切換同步標(biāo)志，才能執(zhí)行IN事務(wù)

toggle_recv(); p+=0x08; issue_token(( 0 << 4 ) | DEF_USB_PID_IN);//繼續(xù)讀剩下的描述符

應(yīng)該切換了吧,下面函數(shù): void toggle_recv() { /* 主機(jī)接收成功后,切換DATA0和DATA1實(shí)現(xiàn)數(shù)據(jù)同步 */ CH375_WR_CMD_PORT( CMD_SET_ENDP6 ); CH375_WR_DAT_PORT( endp6_mode ); endp6_mode^=0x40;//這個(gè)是切換同步標(biāo)志 delay2us(); }

void toggle_send() { /* 主機(jī)發(fā)送成功后,切換DATA0和DATA1實(shí)現(xiàn)數(shù)據(jù)同步 */ CH375_WR_CMD_PORT( CMD_SET_ENDP7 ); CH375_WR_DAT_PORT( endp7_mode ); endp7_mode^=0x40;//這個(gè)是切換同步標(biāo)志 delay2us(); }

是不是不管BULK ONLY還是CBI協(xié)議,在讀取描述符時(shí)都是一樣的,我看了CBI與BULKONLY的英文協(xié)議可還是不太明白怎能么用,感覺就算是BULKONLY的模式也和你們給的程序編寫模式不一樣,是不是CH375內(nèi)置的原因而隱了好多該有的東西

實(shí)際你在獲取設(shè)備描述符和配置描述符的時(shí)候，完全不需要用外置固件來寫，可以直接發(fā)送獲取描述符的命令來讀取描述符。

是不是說控制傳輸那幾個(gè)標(biāo)準(zhǔn)請求不管BULKONLY或CBI用你們的簡化命令都是能跑的,而CH375DS1.PDF上的命令只有BULKONLY上能跑,是這樣嗎? 寫CBI的讀寫函數(shù)好困難呀,現(xiàn)在也沒有想明白USB怎么運(yùn)行的,雖然程序是跑起來了,可內(nèi)在的這些東西好像都在你們手上拿著一樣,能不能再幫個(gè)忙弄一小段CBI協(xié)議的外置固件,只一小個(gè)舉例函數(shù)也行,理論是看了不少可真寫還弄不出來

如果你想看CBI或者UFI的例子的話，你可以去下載CH374LIB。ZIP，里面有一個(gè)EXAM的文件夾下面例子程序