Uint16 WriteReqDataBlock(Uint08 *Buf)

{

Uint16 BlockLen,BlockLenBak;

SendCmdToCh376(WriteReqData);

BlockLenBak=BlockLen=GetCh376IntStatus();

if(BlockLen)

{

do

{

//SendOneByteToCh376(*Buf++);

SendOneByteToCh376('1');

}while(--BlockLen);

}

return(BlockLenBak);

}

void ByteWriteCh376(Uint08 *Buf,Uint32 Len)

{

Uint16 BlockLen;

SendCmdToCh376(Byte_Write);

SendOneByteToCh376((Uint08)Len);

SendOneByteToCh376((Uint08)(Len>>8));

while(1)

{

if(GetCh376IntStatus() == USB_DISK_WRITE)

{

BlockLen=WriteReqDataBlock(Buf);

SendCmdToCh376(Byte_Write_Go);

Buf = Buf + BlockLen;

}

else

{

CloseFile();

break;

}

}

}

如圖

程序中寫入的都是1，但是出現(xiàn)了不希望的字符，且每次請求都有不希望的字符出現(xiàn)。及時是新創(chuàng)建的文件，沒有打開更沒有寫數據，也有一個不希望的字符。

文件大小不錯，需要寫入592個字節(jié)，PC上顯示文件大小也是592個字節(jié)，但為什么有亂碼呢？

在PC上新建一個空文件，文件大小顯示為0字節(jié)，占用空間0字節(jié)；而CH376新建的空文件，文件大小為1字節(jié)(有1個W字符，占用空間8192字節(jié)；為什么呢？？

究竟哪出問題了呢？通過“SendOneByteToCh376('1');”給CH376寫數據內容是沒錯的，計數也正確，就是在每次“向內部指定的緩沖區(qū)寫入請求的數據塊”時前幾個字節(jié)為亂碼??！請求指點！謝謝！

GetCh376IntStatus()是怎么實現(xiàn)的？檢測到INT的中斷信號了嗎？

強烈建議使用FILE_SYS.C文件。

回5樓，我也想可能是時序配合問題，其它產生中斷并且需要讀取中斷狀態(tài)的命令可以先判斷INT狀態(tài)，可WR_REQ_DATA命令不產生中斷??！

執(zhí)行“SendCmdToCh376(WriteReqData);”命令后，讀取狀態(tài)返回的字節(jié)數是完全正確的！為什么寫就有問題！

芯片是在網上買的，市場上有沒有問題芯片在流通？謝謝！

字節(jié)寫命令和字節(jié)繼續(xù)寫命令是有中斷的，必須等中斷。

可以用ch376.exe工具調試一下。

ch376.rar

void ByteWriteCh376(Uint08 *Buf,Uint32 Len)

{

Uint16 BlockLen,Sta;

SendCmdToCh376(Byte_Write);

SendOneByteToCh376((Uint08)Len);

SendOneByteToCh376((Uint08)(Len>>8));

while(1)

{

while(INT376);

if(GetCh376IntStatus() == USB_DISK_WRITE)

{

BlockLen=WriteReqDataBlock(Buf);

SendCmdToCh376(Byte_Write_Go);

Buf = Buf + BlockLen;

Usb.FileCntLen += BlockLen;

}

else

{

CloseFile();

break;

}

}

}

這個函數里在讀取中斷狀態(tài)前已經等待中斷發(fā)生了！

8、關于CH376串口操作方式的注意事項。(部分用戶會混淆中斷檢測的方式)

CH376串口操作時，INT引腳也是可選的。第一種情況是使用INT引腳作為中斷檢測引腳，也就是中斷是通過INT引腳變?yōu)榈碗娖絹磉M入的，使INT引腳重新恢復高電平的唯一方式是執(zhí)行GET_STATUS(0x22)命令讀取“中斷狀態(tài)”。但是，在INT引腳變成低電平的同時，單片機串口也會接收到一個字節(jié)數據(中斷狀態(tài))，這個數據一般丟掉(清中斷一般可以丟棄)，使用0x22命令重新獲取中斷狀態(tài)，同時恢復INT引腳電平。

第二種情況是不使用INT引腳作為中斷判別標志的，而是使用上文提到的和INT引腳變低的同時串口收到的數據作為中斷判別標志，即只要收到數據就說明中斷到來(376的中斷只會在確定的一些命令發(fā)下去之后產生或者拔插操作也會產生，所以中斷產生的時刻是確定的，在那些時刻等待這個串口數據就可以了)。讀到的這個數據可以作為中斷狀態(tài)直接返回，也可以丟棄，只作為一個中斷到來的標志，使用0x22再次讀取中斷狀態(tài)值。關于串口方式的這兩種檢測使用的詳細代碼參考CH376EVT資料包(UART_HW.C)。

特別說明：例程中xWriteCH376Cmd函數中RI=0就是丟棄串口數據的一種方式。

暫時已經解決（用CPU串口接收中斷接收的數據做判據，不用再一次讀取CH376的中斷狀態(tài)），還是程序與芯片之間的邏輯時序配合不好造成的，有空還要繼續(xù)找讀取CH376的中斷狀態(tài)時序不合理的原因。