在端點(diǎn)2里面組裝一個(gè)1024byte數(shù)據(jù)，組裝完拷貝出去，發(fā)現(xiàn)有時(shí)部分64byte數(shù)據(jù)會(huì)出錯(cuò)，被新值覆蓋

in?offset = 0;

u8 usb_tmp_buf[1024] = {0};

u8?my_buf[1024] = {0};

case UIS_TOKEN_OUT | 2://端點(diǎn)2 Out

{

????len = R8_USB_RX_LEN;

????memcpy(&usb_tmp_buf[offset], pEP2_OUT_DataBuf, len); //組裝數(shù)據(jù)每次最大64byte

????offset += len;

????if(offset>=1024)

????{

????????//有沒有 可以 暫停usb pEP2_OUT_DataBuf接收?

????????memcpy(my_buf,? usb_tmp_buf , 1024); //發(fā)現(xiàn)拷貝數(shù)據(jù)時(shí)間比較長(zhǎng)，pEP2_OUT_DataBuf數(shù)據(jù)更新了，來不及接收，后面會(huì)覆蓋

????????// 打開usb?pEP2_OUT_DataBuf接收

????????offset = 0;

????}

????//沒有其他操作，清中斷，退出中斷

????....

}

芯片是ch579

有沒有一種可能，memcpy前先NAK，拷貝完數(shù)據(jù)再ACK這種騷操作

附注：

測(cè)試過了，usb會(huì)暫停，是不是打開方式不對(duì)，

給點(diǎn)思路? :)

用兩個(gè)buf或許可以？復(fù)制數(shù)據(jù)之前把buf換成另一個(gè)，下次復(fù)制再換回來，交替執(zhí)行

出錯(cuò)的64字節(jié)中，是大面積與前一包不同嗎，還是只有前N個(gè)字節(jié)與上一包不同，64-N個(gè)字節(jié)與上一包是相同的？

如果后續(xù)的包比較小，出現(xiàn)后者的情況，比較好判斷是在pEP2_OUT_DataBuf被取出前就被覆蓋了這個(gè)情況。

看描述，拷貝異常出現(xiàn)的環(huán)節(jié)似乎有待商榷，最好是數(shù)組內(nèi)容都打印出來看看哪個(gè)環(huán)節(jié)出現(xiàn)了錯(cuò)誤。

“?memcpy(&usb_tmp_buf[offset], pEP2_OUT_DataBuf, len); //組裝數(shù)據(jù)每次最大64byte”

如果出現(xiàn)覆蓋問題，在此處發(fā)生的可能性較大。

“memcpy(my_buf,? usb_tmp_buf , 1024); //發(fā)現(xiàn)拷貝數(shù)據(jù)時(shí)間比較長(zhǎng)，pEP2_OUT_DataBuf數(shù)據(jù)更新了，來不及接收，后面會(huì)覆蓋”

這里已經(jīng)是與USB的DMA緩存區(qū)域無關(guān)的數(shù)組之間的拷貝了，即使是pEP2_OUT_DataBuf在拷貝期間更新，也不應(yīng)該影響my_buf中的內(nèi)容。

先置USB回NAK再memcpy這個(gè)思路沒問題。

“測(cè)試過了，usb會(huì)暫停，是不是打開方式不對(duì)”

USB暫停是不是因?yàn)闆]有將NAK再置回ACK？
建議USB中斷中發(fā)現(xiàn)收滿1024字節(jié)后，置標(biāo)志變量，置NAK，先釋放USB中斷退出來到主循環(huán)；

1024字節(jié)長(zhǎng)的memcpy放到主循環(huán)中執(zhí)行，拷貝完成后清標(biāo)志變量，置ACK，再在USB中斷中收后續(xù)包。

感謝樓上2位的解答，特別是是?TECH_JW?詳細(xì)的解答！

問題已經(jīng)解決，CH579功能拉滿，高優(yōu)先級(jí)中斷過于頻繁，解決辦法是：

把端點(diǎn)2? IN挪到其他端點(diǎn)進(jìn)行上傳，然后空出in的buf做雙buf

芯片DS第83頁(yè)