一般情況下，組播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配置即可。

CH395_F4x.zip

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

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