大家好，又見面了，我是你們的朋友全棧君。
ODrive通訊協定
與ODrive進行通訊需要對通訊端點進行一系列操作。理論上，端點上的資料可以是以任何方式序列化的任何類型的資料。資料包采用預設的序列化方式，對于您自定義的資料包，您必須自己去進行反序列化。未來我們可能會提供序列化功能。可以通過從端點0讀取JSON來枚舉可用的端點，從理論上講，每個接口都可以不同（實際上并沒有這麼做）。每個端點都可以被用來發送和接收位元組資料，有效位元組資料的含義在JSON中進行了定義。
例如，int32端點的輸入和輸出是4位元組的小位元組序表示。 通常，組合的讀/寫請求的約定是交換，即傳回的值是舊值。 自定義的端點可能不符合這種要求。
該協定有基于資料包的版本和基于流的變體。 适當地使用每個變體。 例如，USB預設運作基于資料包，而UART運作基于位元組流。
基于資料包的格式
我們将ODrive稱為“伺服器”，将PC稱為“用戶端”。 請求是從PC到ODrive的消息，響應是從ODrive到PC的消息。
每個請求-響應事務對應于一個端點操作。
請求
- Bytes 0, 1 資料包的序列号, MSB = 0
- 目前，伺服器不進行處理，也不過濾重複發送的資料包。
- Bytes 2, 3 端點ID
-
可以從JSON定義中擷取所有端點的ID。 可以通過從端點0讀取獲得JSON定義。
如果（且僅當）MSB設定為1時用戶端期望對此請求做出響應。
-
- Bytes 4, 5 預期請求傳回的位元組數
- 應該傳回給用戶端的位元組數。 如果用戶端不需要任何響應資料，則可以将該值設定為0。
- Bytes 6 to N-3 有效負載
- 有效負載的長度由資料包大小确定。 有效負載的格式取決于端點類型。 端點類型可以從JSON定義中擷取。
- Bytes N-2, N-1
- 對于端點0：協定版本（目前為1）。 伺服器應忽略具有其他值的資料包。
- 對于所有其他端點：通過JSON定義計算得出的CRC16。 CRC16初始值是協定版本（目前為1）。 伺服器将忽略CRC錯誤的資料包。 有關CRC的詳細資訊，請參見protocol.hpp源碼。
響應
- Bytes 0, 1 資料包的序列号, MSB = 1
- 這是響應請求的序列号。
- Bytes 2, 3 有效負載
- 有效負載的長度，等于請求中訓示的預期位元組數。 伺服器傳回的位元組數不能超過用戶端請求的位元組數大小。
基于流的格式
基于流的格式隻是基于資料包格式的封裝。
- Byte 0 同步位元組
0xAA
- Byte 1 包位元組大小
- 目前，隻能發送/接受0到127個位元組的包大小。
- Byte 2 bytes 0 和 bytes 1的CRC8
- 詳情請參考 protocol.hpp 源碼
- Bytes 3 to N-3 包資料
- Bytes N-2, N-1 CRC16
- 詳情請參考 protocol.hpp 源碼
釋出者：全棧程式員棧長，轉載請注明出處：https://javaforall.cn/126675.html原文連結：https://javaforall.cn