在1.写在前边之前，我测试过CAN总线，包括物理层、数据链路层、TP层和诊断层。 虽然对总线相关协议11898、15765和14229有一些很深的了解，但对于代码实现，即CAN协议栈是如何实现的，最近有些无知。
**
2 .什么是协议栈*
众所周知，CAN网络基于7层协议实现，但不支持7层协议的各层，实际上CAN (应用消息)在只有物理层、数据链路层、APP应用层这3层的诊断消息中
其中，物理层和数据链路层是硬件的工作，也就是说，硬件已经可以实现，不用在编写CAN驱动的基础上进行管理。 中，协议栈部分实际实现了网络层和诊断层的内容。 当然诊断和应用并不完全分开，有些诊断与应用有相互作用，这一部分也要考虑。 例如车速、发动机状态等与诊断相关，一般判断。
总之，协议栈狭义上是网络层和诊断的代码实现。
**
3 .协议栈功能整理*
ECU中的协议栈与诊断设备中的协议栈配合使用。 也就是说，我们是下级机器，只要实现接收部分的协议栈就可以了。 诊断装置和ECU之间的交换大致总结如下3种。1.诊断仪请求单帧，ECU响应单帧
例如，会话切换、28，85服务等2.诊断仪请求单帧，ECU响应多帧
例如，如果诊断装置要求22个服务读取VIN码，则ECU将读取8字节以上3.诊断仪要写入多个字节，ECU响应单帧
例如，为了写fingerprint，ECU只要有正响应就可以有负响应。
展开后，它实际上从数据链路接收一帧消息，即从CAN驱动RX中断接收的消息，确定是一帧还是多帧，从数据字段中提取N_PDU并发送到诊断层，然后将它发送到诊断层(APP应用层接收的提取过程就像剥洋葱，响应的时候，用相反的操作，就相当于穿马甲。 如果不知道，这两个操作可以引用7层协议的传输过程。
关于每一层的PDU概念，可以看到协议，每一层的PDU都不同，请参考下图。
另一种情况是，在接收到第一帧之后，ECU必须向发送方传达自己的接收能力，即需要发送帧。 这项工作在网络层进行，与APP应用层无关。
有关时间参数的相关内容，请参照标准。
**
4 .总结*
ISO15765-2为网络层的书写提供了一些服务原语，最初看起来很难理解，但实际上定义了各个层间的函数接口和条目。 实际上看，完全按照规格的写法也很少。 就个人而言，理解概念是最重要的，在实现时可以灵活应对，但也可以参考规格的代码。
我收下。