之所以使用 CDBUS 协议是因为它实现了自动仲裁的功能，而且是开源的，也就是说使用 RS-485 多个设备同时发送数据也不用担心数据冲突的问题了，所以效率可以提升很多，下面传视频的场景 640x480 16 帧每秒只用了 10Mbps 的 1/3 都不到，而且由于有优先级保证，所以即便传视频也不会影响电机的实时控制。
场景中树莓派可同时输出预览画面及控制数据，用户可在电脑上监控识别过程，遇到问题的时候可以很方便的知道原因及调整参数，且断开电脑也不会影响设备运作。
完整视频：
http://v.youku.com/v_show/id_XMzUxNzA5NjkzNg==.html
场景由以下几部分组成：
CDBUS 协议的详细介绍：
https://github.com/dukelec/cdbus_doc/blob/master/intro_zh.md （协议介绍）
https://github.com/dukelec/cdbus_ip （协议说明及开源 IP 核）
顺便提一下另外一个虚拟串口的场景，可以把产线各种设备挂在一条总线上，不用再头痛乱七八糟的布线问题了。
这个场景有些人用串口转以太网的盒子来实现，
然而以太网没法满足实时性，而且网线布线会很麻烦，大家如果有见过线槽里面成百上千条网线，就应该能理解我的意思，而且网线也没法解决冲突问题，还是要靠交换机来避免冲突，所以最终的结果就是一堆的网线、一堆的交换机。
所以反而是应该用 RS485 来替代网线，而不是用网线代替 RS485.
# 最理想的 RS485 多主 / 无主 解决方案

这个是不是串行专TCP,,

CDBUS,第一次听说

相当于用 RS485 替代网线（以太網），但 RS485 上不是纯粹的 TCP/IP 协议，因为 MCU 跑起来太吃力，太麻烦，实时性也没有保证，所以我这个：
最底层是 RS485, 往上一层是 CDBUS 协议，再往上一层是 CDNET 协议，再往上是 IPv4/v6, 传视频走的是 IPv4 或者
IPv6, 控制电机是 IPv6, 因为 IPv6 一个接口支持多个 IP 地址，通过不同的 IPv6 地址选择是与 PC 通讯（走 CDNET L2）还是映射到底层的 CDNET L0/1 方便与 MCU 通讯，MCU 只用跑 CDNET L0/1 协议就非常简单了。
其实也可以不使用任何 TCP/IP 技术，直接 C 语言跑 CDNET 协议通讯也是可以，协议很简单，也能保证实时性。
CDNET 协议也不是必须的，你也可以只使用最底层硬件实现的 CDBUS 协议，只是不建议重复造轮子。

先暂一个，可能有这方面需求。

补充一份之前的 CDBUS 实际使用的一个调试图片，使用的场景是两台电脑通过 CDBUS Bridge 盒子通讯，下载文件、连续几天上网播放 MV 视频：
/dev/ttyUSB1 对应的设备优先级较低，所以在完成单向发送了一千六百多万个数据包的时候，一共顺利主动避让了 9753 次数据冲突，除此以外，无一错包、丢包发生。
测试的 RS485 波特率为 1Mbps + 10Mbps, 用 2 米多的杜邦线连接。
而且就算短路总线、断开总线等人为破坏测试，上层 CDNET 协议也会自动重传出错的数据包，以保证用户数据完整性。

CDBUS协议没太看明白是哪个层面的协议

OSI 资料连接层，跟 CAN 协议在同一层
实际上很简单，很多私有串口协议都是 55 AA 这种开头，CDBUS 也差不多，它有 3 个字节头：
[发送地址、接收地址、数据长度]
然后是变长的用户数据，最后是两个字节 CRC 校验。
CDBUS 核心在于要配合硬件控制器使用，控制器在发送第一个字节，也就是发送方地址的时候，会半驱输出并按位回读，跟 CAN 一样防止冲突。
CDBUS 也可以用在普通串口，发送地址和接收地址通常小心选取并且固定，譬如电脑发给设备是 AA 55 开头，设备返回数据就反过来 55 AA 开头了，其它格式不变。

这个太复杂，看不懂。以后会不会像猫吧屎一样很多人用？

好像640x480x16x8差不多是50mbit/s了吧？这个10mbps的1/3都不到是怎么得到的呢？