全部學習彙總：
上次做了位址宣告的部分分析，當時出現了乙份報文互動記錄。當時只注意了源位址和目標位址，沒有注意到資料場。今天沒事兒的時候突然間腦子裡想起了這麼一回事兒，當時的資料場到底是乙個什麼資訊呢？
我找到了前面的報文記錄：
首先，在vector的乙份文件中有如下的描述。
如果位址宣告的時候出現了位址衝突，名字具有更高優先順序的取得相應的位址，而另乙個失去位址的ca則應該以254（空位址）的源位址傳送一條無法宣告位址的報文。
從另乙個網路上的文件找到如下的資訊：
看起來，資料場的8個位元組的資訊是ca的name。我檢視了**資訊，確實是與之一致。
其實，找這種報文格式回去查協議的文件應該是最準確、最穩妥的方式。不過，簡單看了一下這個j1939的文件確實是不少，等到了能夠自由查文件的程度估計還得花點時間去熟悉一下。
zynq CAN中斷傳送J1939資料
1 手冊 認真翻譯上邊的一段話 示例 使用中斷的方式來想txfifo中寫入資料 在中斷模式中，寫操作可以持續直到can.isr txfll 產生乙個中斷。資料能夠持續寫入txfifo直到txfifo被寫滿。當txfifo寫滿的時候，can.isr txfll 和 can.sr txfll 被設定成1...
J1939 多包報文傳輸
以j1939 rc retarder configration 報文為例，19個位元組，需要分3條報文傳送。1 將要傳送多包報文之前先會廣播一條id為0x18ecff 形式的一條報文tpcm 以目前理解最後 為源位址，rc報文的話為0f 資料場會提示接下來將會傳送多少條報文，包含什麼資訊 rc 2 ...
CAN匯流排 J1939 速成指南 1
這是乙個can擴充套件幀的完整結構圖，針對剛入門的小夥伴來說。不需要每乙個元素都理解，思想的套路是讓大家先能看懂報文。至於其他的元素就在實際的工作中進行擴充套件學習。擴充套件幀頭部有32位的仲裁字段，仲裁欄位中對於我們最有用的就是11位的識別符號和18位的拓展識別符號 這29位的資料就組成了我們通常...