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

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

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

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

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

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

你好，我這邊使用CH395Q，SPI接口連接處理器：

測(cè)試1：給395Q連發(fā)2包數(shù)據(jù)間隔很小（100us），包大小約1000字節(jié)，使用中斷方式，發(fā)現(xiàn)接收有概率會(huì)丟包，丟第2個(gè)包。

測(cè)試2：使用keil進(jìn)調(diào)試模式，處理器暫停執(zhí)行，給395Q連發(fā)2包數(shù)據(jù)間隔很?。?00us），然后處理器再繼續(xù)執(zhí)行，可正確讀回2個(gè)包。

初步估計(jì)，測(cè)試1中當(dāng)收到第1包數(shù)據(jù)后，中斷中去讀取數(shù)據(jù)，此時(shí)395Q收到了第2包數(shù)據(jù)，然后實(shí)際讀取不到第2包數(shù)據(jù)。

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

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

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

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

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

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

而且，把主控處理器進(jìn)調(diào)試模式暫停，這個(gè)時(shí)候?qū)嶋H上收到的2個(gè)包都在395中，然后再主控處理器繼續(xù)執(zhí)行時(shí)是能正常收到2個(gè)包的。

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

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

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

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

你好：

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

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

過(guò)程如下

while 中斷引腳為低

{??

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

?? 判斷有socket中斷

?? 讀socket狀態(tài)

?? 讀接收數(shù)據(jù)長(zhǎng)度? 并處理

}

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

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

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

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

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

CH395_F4x.zip

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

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