can多包接收解析求解

ID:378659 · 發(fā)表于 2023-8-5 17:27

can一幀數(shù)據(jù)最多8個字節(jié)，發(fā)送超過8個字節(jié)就涉及到多幀發(fā)送了，那么接收函數(shù)怎么寫？
現(xiàn)在設想的是把擴展標識符拆成8bit發(fā)送地址8bit接收地址8bit發(fā)送長度，接收方判斷接收數(shù)據(jù)長度一致或者接收到一幀后后面10ms都沒收到就判斷接收結束（超時處理，避免拆包發(fā)送中發(fā)一幀后突發(fā)死機不再發(fā)送，那buf會卡死一直達不到接收長度一致的情況）。但是假設我發(fā)送15個字節(jié)，第一幀發(fā)出去后，恰巧有個高優(yōu)先級的插入發(fā)送，后面那個原本低優(yōu)先級的又重發(fā)，那么我接收端接收到的不就是8Byte+高優(yōu)先級的數(shù)據(jù)+剩下的7byte，那樣解析就錯換了，后來又想了個接收方解析，收到的數(shù)據(jù)根據(jù)不同發(fā)送地址設定不同的接收buf，但是要是節(jié)點一點多那不是要設立很多buf很麻煩，請問有啥更好的方法

ID:771630 · 發(fā)表于 2023-8-6 07:38

can不是可以指定地址的么，你把數(shù)據(jù)包拆分成 1字節(jié)的拆分標志位，7字節(jié)的數(shù)據(jù)，只接收該地址，并判斷拆分標志位進行數(shù)據(jù)完整度判斷和組合不就行了

ID:378659 · 發(fā)表于 2023-8-7 09:41

XLinliY.Zhang 發(fā)表于 2023-8-6 07:38
can不是可以指定地址的么，你把數(shù)據(jù)包拆分成 1字節(jié)的拆分標志位，7字節(jié)的數(shù)據(jù)，只接收該地址，并判斷拆分標 ...

一個節(jié)點不止接收一個地址的數(shù)據(jù)啊，要是有個廣播和有個地址的

ID:123289 · 發(fā)表于 2023-8-8 14:01

1、CAN的硬件系統(tǒng)中有一個8字節(jié)的數(shù)據(jù)緩沖器，必須寫滿8個字節(jié)才能發(fā)送出去（當指令成8字節(jié)時）。不存在發(fā)了3個再等5個的問題。
2、CAN更高級端口，不能打正在發(fā)送中尚未結束的幀，這是CAN的硬件特征。更高級的CAN端口，即使你用軟件下達了發(fā)送命令，實際執(zhí)行時，也會自己進入等待狀態(tài)，等總線掛起后（正在發(fā)送的幀結束）才會執(zhí)行發(fā)送。
你要更深入地了解CAN通訊的特點，了解它的優(yōu)缺點。

ID:378659 · 發(fā)表于 2023-8-9 15:05

yzwzfyz 發(fā)表于 2023-8-8 14:01
1、CAN的硬件系統(tǒng)中有一個8字節(jié)的數(shù)據(jù)緩沖器，必須寫滿8個字節(jié)才能發(fā)送出去（當指令成8字節(jié)時）。不存在發(fā) ...

不是，我的意思是假設有個低優(yōu)先級的需要發(fā)送15個字節(jié)，can特性8個最多，就先發(fā)8個字節(jié)，此時正常后面會拆分發(fā)剩下7個字節(jié)，若此時有高優(yōu)先級的節(jié)點也發(fā)送了，那我接收端的不就容易錯亂嗎

ID:378659 · 發(fā)表于 2023-8-9 15:12

yzwzfyz 發(fā)表于 2023-8-8 14:01
1、CAN的硬件系統(tǒng)中有一個8字節(jié)的數(shù)據(jù)緩沖器，必須寫滿8個字節(jié)才能發(fā)送出去（當指令成8字節(jié)時）。不存在發(fā) ...

舉個例子有三個節(jié)點abc，a往b節(jié)點發(fā)送 1 2 3 4 5 6 7 8 9共9個字節(jié)，那么發(fā)送一定是先發(fā)送1 2 3 4 5 6 7 8，然后再發(fā)送一幀9，那么若a往b發(fā)送完1 2 3 4 5 6 7 8后此時恰巧c往b發(fā)送1,2,3優(yōu)先級又更高，can仲裁一定是先讓c發(fā)，那么b節(jié)點接收到的數(shù)據(jù)就會錯亂成 1 2 3 4 5 6 7 8 1 2 3 9

帳號		自動登錄	找回密碼
密碼			立即注冊

欧美极品高清xxxxhd,国产日产欧美最新,无码AV国产东京热AV无码,国产精品人与动性XXX,国产传媒亚洲综合一区二区,四库影院永久国产精品,毛片免费免费高清视频,福利所导航夜趣136

can多包接收解析求解