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