简述对can，lin协议栈的理解以及其代码实现的基本逻辑

1.汽车ecu的开发过程中，汽车网络通信的软件开发是比较重要的一环，目前CAN总线和LIN总线仍然是各个供应商使用非常频繁的总线，其中CAN总线更是出现了autosar等高级软件架构的支持，lin总线因为其成本十分廉价，市面上所有的mcu基本都可以使用lin总线，故而也是汽车总线的重要组成部分。

2.在通信的开发中，协议栈是必不可少的软件组成部分，虽然市面上已有不少，国外诸如autosar，vector，国内诸如恒润等等公司均拥有可以生成协议栈代码的工具链，但是在使用工具链或者自己开发项目之前，我们还是需要对协议栈的原理进行梳理和理解。

3.我的理解：can，lin协议栈一共分为3层:driver底层驱动层，TP中转层，应用层（诊断层）。

其中，应用层可以理解就是诊断层， 我这里使用的uds iso14229-1协议，其诊断报文基本用于刷写bootloader，读取did信息，19服务读取DTC等等。driver层就是底层驱动层，这一层的实现条件本身是由硬件来完成的，在驱动软件方面，很多芯片都拥有can，lin驱动的sdk mdk以及相应demo，在大部分的sdk内，用来发送或者接收一帧8字节长度的报文的函数往往会有一个对应的发送数组和接收数组，这些数组内的数即是我们接收到的数据和想发出去的数据，这里暂记为Tx,Rx

4.tp层则是实现协议栈的重点和关键，其中单帧，多帧，连续帧，流控帧等等概念在iso15765协议当中已经定义明确，这里对概念不过多描述，推荐大家看相应得文章。我们定代码中诊断层使用的收发数组为TP_Rx和TP_Tx.这里先举例一个CAN诊断报文的收发例子，首先是发送,我们可以理解最下面一行报文为数组TP_Tx内的数据：

这是ecu需要回复的22服务，这里可以看到一共发出了11帧报文为一个多帧报文，但是在底层driver中对应的sdk函数中的Tx只支持发送最大八字节的数据。那么诊断层发送数据的过程很简单：判断TP_Tx数组的数据的长度，若在1到7之间，则报文为单帧，将数据填入Tx并设置Tx的第一个字节为单帧的pci。若报文为多帧，则按照网络协议规定的方式将数据填入Tx并计算出首帧的pci还有连续帧的pci。

了解了发送，接收就更好理解了，我们可以理解最下面一行报文为数组TP_Rx内的数据：

 判断底层接收数组Rx数组的长度，将数组刨析开来，可以得到他是一帧单帧或者多帧，然后根据协议得规则，将对应得pci丢掉，然后把剩下的数据放进数组TP_RX，之后就可以在诊断层使用TP_RX了。

5.ISO-15765中除了定义了tp层和底层报文之间的转化规律，还有一些时间的定义，这一块的代码大概是使用一些mcu的定时器中断以及滴答定时器来实现，具体的内容需要对应完成。

6.说完了CAN的我们再说说LIN的协议栈：两个协议栈的实现过程完全一样，不同的是在LIN的诊断中需要nad节点号，并且也没有流控帧的需要。即在一帧报文原本的pci之前，还需要加入一个nad号，这样底层一帧八字节报文诊断传输的数据又少了一字节，但是这样做的目的也很简单，就是让主节点能够识别各个ecu发出的诊断报文。

7.总结：在开发过程中，大部分的软件是使用工具链生成的，但我们如果理解了协议栈做的事情那就会事半功倍，找到应用层对应的数组TP_RX，TP_Tx，我们就可以完成应用层的报文收发开发，找到协议栈的底层数组RX,TX，切换芯片的时候也不用担心了，汽车ecu网络通信的开发需要阅读的15765和14229两个协议我们应重点查看并在开发中做相应的记录，如果无法理解，我们可以多看看诊断报文。