※ 引述《dces4212 ()》之铭言：
: 内葛阿
: 我在研究 CAN 的规格的时候遇到个想不通的点，
: 我们知道，在 CAN bus 里面，当一个 sender 收到与自己正在传输的位元不一样的准位
: 的信号时，也就是它原本正在送 1，结果收到 0，它会知道发生碰撞，并且让出 bus 给
: 正在传输的节点。
: 问题来了！
: 如果 header 已经传完了，当下正在传输的是 payload，并且正在传送 1 的资料，这时
: 刚好其他节点开始说话了，并且发送 0。这样不就造成即便 can_id 是最小的 frame，
: 也就是优先序最高的 frame，也会失去这次发送资料的机会？！？！
: 还是说，transceiver 的实做会在收完 header 的那几个位元之后，就停止自己这个节点
: 的发送，直到其他节点传送完资料，才会再次发送待传送的资料，以避免上述情况发生？
: 蛤？
自己回一下，
后来发现是，当 arbitration field (我所谓的 header) 已经传完，并且正在传送后续
payload 等内容时，其他节点在这个时间是不会说话的，因为这时 bus 不是 idle 状态
。
什么时候才可以说话呢？答案是等这个 frame 传完，并且已经过了 intermission field
(frame 之间的间隔，由 3 个 intermission bit 以及 1 个 recessive bit 构成) 之后
，其他节点才可说话。
如此一来，我们就解开了上述问题：payload 在传送时是不会被打断的。
参考资料：
- http://wiki.csie.ncku.edu.tw/embedded/CAN
- https://copperhilltech.com/blog/controller-area-network-can-bus-bus-
arbitration/
成大 wiki 应该接近第一手资料了吧！？jserv 别搥我R