CH395常見(jiàn)問(wèn)題匯總及解答(持續更新)

一般情況下,組播MAC前三個(gè)字節固定為0x01,0x00,0x5E,后三個(gè)字節與組播IP的后三個(gè)字節對應。注意,0x5E這一項的原因,會(huì )導致一個(gè)組播MAC實(shí)際上是對應多個(gè)組播IP的,此時(shí)需要人為的去規避一個(gè)局域網(wǎng)內不要使用會(huì )導致重復的組播IP地址。


好的,謝謝?!?span style="color:rgb(51,51,51);">0x5E這一項的原因,會(huì )導致一個(gè)組播MAC實(shí)際上是對應多個(gè)組播IP的,此時(shí)需要人為的去規避一個(gè)局域網(wǎng)內不要使用會(huì )導致重復的組播IP地址。“這個(gè)怎么理解呢,一個(gè)組播MAC對應到多個(gè)組播IP,那實(shí)際是對應到哪幾個(gè)組播IP了,對應關(guān)系是如何的呢,如果不知道對應關(guān)系,就無(wú)法人為避免導致重復的組播IP地址了。


請問(wèn)我用spi給ch395發(fā)送命令,不管發(fā)什么它都返回255,這個(gè)可能是哪里出問(wèn)題了?



讀取的是255情況下問(wèn)題可能性很多,建議抓取SPI時(shí)序波形查看。



技術(shù)支持你好,請問(wèn)可以提供一份使用STM32的CH395的FTP客戶(hù)端例程嗎?


您好,沒(méi)有STM32的CH395的FTP客戶(hù)端例程。


你好,我這邊使用CH395Q,SPI接口連接處理器:

測試1:給395Q連發(fā)2包數據間隔很?。?00us),包大小約1000字節,使用中斷方式,發(fā)現接收有概率會(huì )丟包,丟第2個(gè)包。

測試2:使用keil進(jìn)調試模式,處理器暫停執行,給395Q連發(fā)2包數據間隔很?。?00us),然后處理器再繼續執行,可正確讀回2個(gè)包。

初步估計,測試1中當收到第1包數據后,中斷中去讀取數據,此時(shí)395Q收到了第2包數據,然后實(shí)際讀取不到第2包數據。


看到樓主的說(shuō)明,是否跟描述的這個(gè)原因有關(guān):

1)395在收發(fā)數據的過(guò)程中不能被其他進(jìn)程打斷,如果395在數據收發(fā)中被其他任務(wù)打斷,則可能會(huì )導致數據丟包

如果是,請問(wèn)這個(gè)過(guò)程具體是指從什么時(shí)候開(kāi)始什么時(shí)候結束?處理器這邊如何判斷395Q是否正在收發(fā)?


您好,請問(wèn)您使用的是UDP、還是TCP模式,如果您使用的是UDP模式,那么按照您的這個(gè)速度,那么您可以使用CH395重新設置Socket接收緩沖區大小函數,將單個(gè)Socket接受緩沖區設置大一些,這樣可以連續收到兩包數據不丟包。如果您是TCP模式的話(huà),您也可以先是前面的步驟,然后抓包看重傳包是否有發(fā)送。


使用的是UDP。SPI時(shí)鐘24MHz

應該不是接收緩沖區的問(wèn)題,緩沖區大小已設置成9(個(gè)塊),實(shí)際使用外部工具發(fā)送也是只發(fā)送連續2個(gè)包(間隔很?。y試1次。

而且,把主控處理器進(jìn)調試模式暫停,這個(gè)時(shí)候實(shí)際上收到的2個(gè)包都在395中,然后再主控處理器繼續執行時(shí)是能正常收到2個(gè)包的。

目前判斷:如果主控全速運行,外部工具發(fā)2個(gè)包,當主控讀取第1個(gè)包時(shí),395可能正在接收第2個(gè)包。不知道這個(gè)過(guò)程有沒(méi)有影響?


主控目前在接收到395中斷時(shí),中斷處理程序中發(fā)信號量后退出;信號量會(huì )喚醒395數據處理線(xiàn)程,執行“查全局中斷狀態(tài)”->“查socket中斷狀態(tài)”->“是接收中斷則讀取接收長(cháng)度”->"讀取接收數據"。

也曾懷疑是否在spi讀取接收數據的過(guò)程中被第2包數據產(chǎn)生的中斷打斷會(huì )有問(wèn)題,所以做了驗證:在上述“查全局中斷狀態(tài)”前就關(guān)閉了全局中斷,直到"讀取接收數據"執行完才開(kāi)全局中斷,但是還是會(huì )有概率讀不到第2包


多個(gè)CH395通過(guò)交換機進(jìn)行組網(wǎng),5ms為周期通過(guò)UDP廣播發(fā)送數據,一段時(shí)間后出現CH395_1無(wú)法接收到CH395_2的數據情況(最長(cháng)約30s后恢復),但此時(shí)CH395_1能夠接收CH395_3的數據,且此時(shí)CH395_3能夠收到CH395_2的數據;測試抓包發(fā)現CH395的發(fā)送全部成功;請問(wèn)技術(shù)支持這是什么原因呢?讓人很費解,從現象看此時(shí)CH395_1的接收功能應該還是正常的;通過(guò)交換機端口監控,也能看見(jiàn)此時(shí)CH395_2發(fā)送的數據包也向CH395_1轉發(fā)了,但CH395_1就是收不到


你好:

我用 UDP客戶(hù)端模式 通訊正常. 改用UDP服務(wù)模式 遇到點(diǎn)兒?jiǎn)?wèn)題.

通過(guò)中斷引腳狀態(tài) 判斷有無(wú)新數據包 有時(shí)會(huì )重復讀最后收到的包兩次,

過(guò)程如下

while 中斷引腳為低

{??

? 讀中斷狀態(tài)寄存器

?? 判斷有socket中斷

?? 讀socket狀態(tài)

?? 讀接收數據長(cháng)度? 并處理

}

用這種方法處理 發(fā)現 有時(shí)發(fā)生數據包丟失.

有時(shí)發(fā)生 重復讀取. ??

由于在服務(wù)模式下? 接收數據長(cháng)度 寄存器,在數據讀出后還保持原來(lái)的值, 無(wú)法判斷數據是否讀空,不知如何處理比較可靠.


你好,我們使用stm32f407 spi1 PA5 PA6 PA7 連接CH395Q,在初始化過(guò)程中測試CHECK_EXIST ,無(wú)論發(fā)送什么數據均只能收到0x00回復。請問(wèn)能否提供一份該硬件下的初始化示例代碼,謝謝!


您可以參考一下,改一下IO配置即可。

icon_rar.gifCH395_F4x.zip



我在使用CH395L時(shí),經(jīng)常出現CH395CMDInitCH395指令返回0xFA 位置異常錯誤。請問(wèn)如何處理呢?



您好,(1)設置完IP掩碼網(wǎng)關(guān)之后建議增加300ms之后再執行初始化指令 ? (2)初始化之后功耗會(huì )急增,建議電源驅動(dòng)3v3和1v8各按150mA計算。


只有登錄才能回復,可以選擇微信賬號登錄
97精品依人久久久大香线蕉97-亚洲欧美日韩一区二区三区-国产亚洲欧美精品久久久-久久99精品久久久大学生-亚洲成a人片在线不卡一二三区 97精品依人久久久大香线蕉97-亚洲欧美日韩一区二区三区-国产亚洲欧美精品久久久-久久99精品久久久大学生-亚洲成a人片在线不卡一二三区