大家好，又见面了，我是你们的朋友全栈君。
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时客户端期望对此请求做出响应。
- 可以从JSON定义中获取所有端点的ID。 可以通过从端点0读取获得JSON定义。
- 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 进行交流。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/126675.html原文链接：https://javaforall.net
![mysql handlersocket_HandlerSocket介绍[通俗易懂]](https://javaforall.net/wp-content/uploads/2020/11/2020110817443450-480x300.jpg)
