oc 协议 回调 静态成员_AUTOSARETH协议栈调试笔记(一)

历时一个月左右的时间，总算是把AUTOSAR的ETH协议栈跑通了，也存在一些BUG需要后续解决。但是Eth->EthIf->TcpIp-SoAd->PduR->LdCom  数据流收发起码是OK的。

主要记录一下调试过程，好记性不如烂笔头。

第一步: 调试aurix397的ETH模块 和 EthTrcv(也就是PHY)。

最好用有OS操作系统的工程来调 ETH。

需阅读的文档: 

AUTOSAR_SWS_EthernetDriver.pdf

AUTOSAR_SWS_EthernetTransceiverDriver.pdf

Aurix_MC-ISAR_UM_ETHDriver.pdf

Vector的技术手册也可以作参考，只是感觉用处对于Eth底层来说一般般,看SWS部分内容就可以了。Mcal里面的ETH的Demo倒是挺好的( 详见 Aurix_MC-ISAR_UM_ETHDriver.pdf  )。

数据发送和数据接收API ：(比较重要,以太网通信的数据链路层基础)。 

Eth_17_EthMac_ProvideTxBuffer 

Eth_17_EthMac_Transmit

Eth_17_EthMac_Receive 

至于PHY，也就是ETH的收发器，这部分一般来说就是TJA1100，TJA1101，比较简单，工具链厂商会提供外设驱动库，自己也可以写这部分驱动。使用的是MII模式，注意MCAL的PORT的驱动能力，最好是增强型，否则有可能后续加协议栈后会挂掉。

具体测试方法: 使用CANOE来测试是否Get到ECU发出的数据。线要接对，切记切记@@@@

因为还没有涉及到上层的TCPIP协议栈，CANOE无需设置TCPIP，直接运行。

板子的远程MAC地址设置为FF:FF:FF:FF:FF:FF ， 广播形式，保证CANOE能接受。

一般来说就OK了，问题不大，而且AUTOSAR的工具链对ETH的支持都很一般，还有很多不完善，MCAL层面上自己需要配置的工作量很少，也就意味着一出问题，百思不得解~

第二步: 集成ETHIF。

需阅读的文档: 

AUTOSAR_SWS_EthernetInterface.pdf

添加EthIf静态代码，使用配置工具配置生成动态代码，加进去做集成，编译报错是免不了的，多调试多排查就OK了。这部分的EthIf代码实现比较简单，也容易看得懂。重点关注依然是

发送和接受API:

EthIf_ProvideTxBuffer

EthIf_Transmit

EthIf_RxIndication

Task 里面不再调用 ETH层的API来收发数据，而是调用EthIf层的API来发送和接受数据。如果调通的话。

CANOE接收到的数据就是 EthIf_ProvideTxBuffer 的 指针参数 BufIdxPtr 指向的数据，CANOE发出的数据会从ECU的底层回调到ETHIF的 EthIf_RxIndication 的

出参 DataPtr 。可以看地址存放的数据是否一致。@$%#@

第三步: 集成TCPIP和SOAD(重点：问题最多最难调,坑比较多@###)。

添加TcpIp和SoAd静态代码，使用配置工具配置生成动态代码，加进去做集成.也会出各种问题，需要不断地修改调整工具生成的动态代码cfg.c 和 cfg.h 等 文件。。。。。

需阅读的文档:

AUTOSAR_SWS_TcpIp.pdf

AUTOSAR_SWS_SocketAdaptor.pdf

这里TCPIP和SOAD的配置最好是也看看 Vector的技术手册，写的蛮好的。

TechnicalReference_TcpIp.pdf

TechnicalReference_SoAd.pdf

这两个最好一起做集成，因为SoAd的目的就是方便人们更好的使用以太网协议栈，TcpIp和SoAd一起集成的调试工作量反而会比单单调试TCPIP容易许多。这两个模块的配置，论配置量而言也不是很大，但是理解会有些困难，东西挺多，需要细化。

需要补充: IP地址，端口，单播、组播、广播。IPV4、Domain、ARP 、udp 、Socket、bind、connect 、listen 、open、close  等等。(TCP可以先不管，根据整车厂ETH技术规范, 实时性要求更高,UDP更具通用性 )等知识。

虽然是调通了，但问题较多，回头得重新理一理。。。。

测试方法: 依然使用CANOE，但是需要添加ETH激励，还要设置正确的IP地址和端口号。跟ECU里面设置的远程IP地址和端口保持一致。如果不一致，会一直发ARP寻址。ECU就是没应答。这里也可以尝试ping。如果能够ping通，说明TCPIP协议栈集成是OK的。

举个例子:

ECU也就是控制器自身的IP地址设置为 192.168.0.12  端口为 32000.

ECU内部设置它的远程IP地址为 192.168.0.14  端口号为 35000.

注意IP地址要在同一个网段。ECU软件设置基本是这样。

CANOE就得配置好 激励Node的IP地址为 192.168.0.14  ，端口号为 35000。

控制器ECU连上CANOE，硬件检查无误，上电运行，CANOE也运行(点击小闪电符号)。

CANOE出现如下画面: 画面太美。。感人。。。。说明控制器和上位机之间能够正常收发UDP通信正常。

TX    ：  ARP ：192.168.0.14 ask for MAC address of 192.168.0.12

RX    :     ARP ：  192.168.0.12 has MAC address . 00:2E:23:00:11:02

balababalalalalla。。。。。。。

数据收发API：vector 源码会存在自定义的类似的API名称变体，注意一下。

TcpIp_RxIndication

TcpIp_UdpTransmit

SoAd_IfTransmit

SoAd_RxIndication

测试Tcpip和SoAd是否调通：

发送正常可以直接通过观察CANOE是否接收到板子发出的UDP报文。

接收可以看 SoAd_RxIndication 的 出参 RemoteAddrPtr 和 BufPtr 

是否是 CANOE的IP地址和CANOE发送的数据。 

第四步: 集成PDUR。

需阅读的文档:

AUTOSAR_SWS_PDURouter.pdf

PDUR对于CAN、LIN、ETH，是通用的，容易实现。AUTOSAR 当前版本的SWS文档好像还没有添加ETH的SOAD到 PDUR的 Sequence diagrams 说明， 但是观察CANIF到PDUR的收发数据流的传递，可以推出SOAD到PDUR的大致的数据流的传递过程的。

第五步: 集成LdCom。

需阅读的文档:

AUTOSAR_SWS_LargeDataCOM.pdf

因为集成Com的时候出了一些问题，稍微有些麻烦，所以尝试用LdCom模块来收发数据。

优势有几下几点:

1、LdCom的源码的代码量也比Com模块的代码量要少，所以调试代码也比较方便，LdCom的API嗖的一下就直接调到PDUR的API，简单粗暴。

2、LdCom模块的配置工具需要配置的地方实在是太少了，工具链添加LdCom模块，仿佛立马就能编译通过的节奏。

3、LdCom 又名 : LargeDataCom 是用来传大数据的，ETH很合适。

调用的API接口：

发送: Std_ReturnType LdCom_Transmit(PduIdType Id , const PduInfoType*PduInfoPtr)

接收: void LdCom_RxIndication (PduIdType RxPduId , const PduInfoType* PduInfoPtr )

发送容易实现，接收要自己配置通往RTE的回调函数。名字自定义。

回调函数的定义 是 需要自己写的，这个要清楚。即使不写，编译也编不过去。

反思：

1、TcpIp和SoAd 需要反复调试练习，尤其SOAD的配置，比较灵活，需要勤加练习。

2、SOMEIP、SD的调试要不要Preevision 工具 ,只有CANOE能不能验证？？？

3、SOMEIP、DOIP还没搞，后续可以研究一下。