全部學習彙總：
在j1939的協議棧中存在乙個佇列的收發機制，其中接收佇列的實現之前在做isr的部分**分析的時候已經看過介面上的互動。對於這個佇列實現，其實應該有乙個具體的實現機制。
關於佇列的機制，在學習資料結構的時候接觸過佇列的實現，這個基本上是基於鍊錶來實現的。但是，鍊錶的實現是需要基於記憶體的動態分配來實現的。在嵌入式系統中，尤其是涉及到高實時性和可靠性相關的系統提供這樣的功能可能需要一定的代價。不過，之前也看過清華嚴老師的資料結構教程，裡面也提供過基於陣列的實現方式。而這次我接觸的這乙份j1939的**其實就是使用的這種方式。
這部分**，相關的**最核心的部分是圍繞對rxqueue陣列的處理。
這是相關的定義，其中有三個變數分別用於標記佇列頭、佇列尾、佇列元素數目。而陣列的大小，則是佇列的深度。
再回到前面的**，佇列接收的時候如何處理呢？接收到報文之後，佇列尾標記往後移動一位，然後填裝佇列元素。如果，佇列尾超過了佇列深度，那麼佇列尾的標記其實是有乙個滾動的動作。這樣的處理都是有乙個前提的：可以允許佇列覆蓋或者佇列沒有滿。這樣，還剩下乙個佇列頭尾狀態的初始化。
這裡的初始化其實是有乙個講究的，佇列尾初始化為0xff之後，第一次的佇列內容填充會讓tail指向陣列的第乙個元素。
其實這麼看，這個機制還是很簡單的。而出隊的方式應該就是乙個反著來的過程，接下來看看具體的介面實現。
這個其實不是很關鍵，但是能夠借鑑學習到一些東西。
關於佇列出隊的方法，其實也比較簡單。還是乙個元素數目，佇列收尾狀態的處理。
這部分跟開始的地方差不多，至此佇列的處理機制基本完成。其實，還有另一種基於陣列的佇列處理方式，資源使用會更少一點，但是可能會增加一點cpu的運算。這個如果有需要，後面再做一下小結。不過，這個對j1939的學習沒有太大的幫助，暫時先不去深入了。
zynq CAN中斷傳送J1939資料
1 手冊 認真翻譯上邊的一段話 示例 使用中斷的方式來想txfifo中寫入資料 在中斷模式中，寫操作可以持續直到can.isr txfll 產生乙個中斷。資料能夠持續寫入txfifo直到txfifo被寫滿。當txfifo寫滿的時候，can.isr txfll 和 can.sr txfll 被設定成1...
456 J1939中普通報文的佇列接收
全部學習彙總 之前研究arduino的時候，看過了arduino開源社群中別人對ecan使用的時候使用了佇列的收發。全都是軟體實現，沒有使用硬體的模式。手裡的這套j1939的 也有這麼乙個類似的功能。接下來，看看手裡這套 的處理。關鍵 都在注釋上面，其實，下面的部分也已經不在同乙個 塊。正好這個函式...
J1939 多包報文傳輸
以j1939 rc retarder configration 報文為例，19個位元組，需要分3條報文傳送。1 將要傳送多包報文之前先會廣播一條id為0x18ecff 形式的一條報文tpcm 以目前理解最後 為源位址，rc報文的話為0f 資料場會提示接下來將會傳送多少條報文，包含什麼資訊 rc 2 ...