大家好，又见面了，我是你们的朋友全栈君。

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 源码

如果您有任何问题或疑问，欢迎您加入ODrive社区或QQ群 851421965 进行交流。