目录
1、基本介绍
2、准备工作
3、从Can Demo开始
3.1 ASR CAN demo
3.1.1 文件概述
3.1.2 配置说明
3.1.3 文件结构
3.2 Non-ASR can通信
4 总结
1、基本介绍
RTD(Real Time Drivers)是NXP实现的一种复杂软件接口抽象，提供给符合AUTOSAR和非AUTOSAR的产品使用（即这些产品均使用RTD抽象出来的这一套代码）。
其产品基本环境如下，High Level Interface ：符合ASR的接口，以及SDK的功能API，Low Level Interface：高效的直接访问硬件寄存器的API
为什么NXP要做这样？
我们首先从开发流程来看：
- 常规SDK开发流程：使用NXP提供外设配置工具(如S32D)配置外设--->>使用SDK提供的常规API开发-->编译调试；
- AUTOSAR产品开发流程：使用EB或者Davinci配置MCAL→>使用ASR标准接口→>编译调试
那么以发送一帧CAN报文为例，不管是ASR还是Non-ASR，最后都是对同一个CAN硬件进行配置，例如报文ID、payload等；既然最后的目标一致，为什么不把配置这个动作封装为一个标准API，在这个API基础上衍生出符合SDK和ASR标准的接口。
基于这个认识，我们来看RTD的基本结构：
如果开发符合AUTOSAR标准的软件，使用标准接口以保持应用程序之间的可移植性，而使用该接口最终都要实施到具体的IP硬件下，因此，通过IPWrapper这一层进行封装转换；
如果开发Non-AUTOSAR的软件，可以使用ASR接口和RTD扩展的SDK通用接口(IPL)进行开发。
通过这样的方式，就可以使用NXP提供的S32D 完成ASR和非ASR的产品开发。不需要使用EB这样昂贵的MCAL配置工具。
2、准备工作
基于以上简介，我们来看看NXP提供的RTD是如何玩的
首先下载S32D，S32DS.3.5_b220726_win32.x86_64 和RTD代码包，svn路径：Z:\软件库\01通用装机软件\03-开发工具\AUTOSAR工具
参考Getting Started with the Real-Time Drivers (RTD)_NXP 半导体
Ps：安装S32D需要激活码，
安装好S32D之后，
打开程序，选择help→install new sofeware ,安装
如下
这样S32 RTD基本就可以用。那么我们从最基本的CAN demo开始看看如何配置
3、从CAN Demo开始
3.1 ASR CAN demo
首先打开S32DS，new→S32D Project from example，选择CanDemo，这一点就必须要夸夸NXP，不藏私。
3.1.1 文件概述
该demo会轮询发送接收一帧报文，来展示RTD是如何将AUTOSAR和非AUTOSAR驱动代码结合到一起。
新建一个CAN demo工程，此时只有main.c以及基本的启动diamante，如下：
这时候编译肯定是不通过的。
根据这个demo所要展示的效果，那么此时肯定缺少的模块有：AUTOSAR CAN D(.c和.h)，结合RTD架构特点，必然也应该有CAN模块对应的非AUTOSAR 驱动代码；
参考芯片手册，可以发现，该芯片的CAN ip为Flex CAN，因此缺少FlexCan.c/.h。同时，CAN对应的port、MCU的时钟配置等，因此，总结完成CAN_demo需要的模块如下：
- CLC
- FlexCAN
- AUTOSAR CAN
- PORT
3.1.2 配置说明
首先来看S32DS的整体界面：
我们配置代码主要关注右边一排的按钮，如下
红框从左至右为引脚配置，时钟配置，外设配置
打开配置界面，如下：
这个工程初始配置只有一个时钟，因此，首先需要加入CAN模块和基本的Port模块；
打开引脚配置，进入如下界面；
在这里选取FlexCAN_0作为测试对象，因此选取PTA27/28引脚开通CAN功能；
此时生成的代码如下：
可以看到，port已经完成了配置，那么现在就应该搞外设配置了。
打开外设窗口，可以看出，工具已经把基本模块布置好了，但还有很多问题需要确认。
首先是上述模块均提示不会被编译，原因如下：
很明显，需要添加上述模块的源代码；打开SDK功能组，添加上述模块，工具自动加入源码，如下：
此时不更改模块例如CAN、EcuM等的配置，采用默认配置，结构如下：
更新源码后，再次编译，发现是没有头文件。
返回配置界面，添加SIUL2模块，更新代码得到如下源文件：
此时编译成功。
可以看到，在我对S32K这款芯片几乎不怎么熟悉的情况下，通过工具默认配置和引导，以及自身对AUTOSAR的了解，在基本不用修改代码的情况，使用RTD可以有效缩短开发时间，完成CanDemo工程搭建，从而验证控制器can功能。这和EB工具很类似。
3.1.3 文件结构
虽然编译成功了，但我没有板子跑；因此只能看看这个代码结构了，如下：
参考Can.c，梳理出AUTOSAR的MCAL代码如何和FlexCan的Non-AUTOSAR源码有效结合。
基本路径如下：
通过CAN Driver将整个硬件CAN抽象出来，然后通过Wrapper最后再到实际的Driver层进行寄存器级别的操作。 下图为NXP的MCAL和RTD对于CAN的处理。
3.2 Non-ASR can通信
如果不使用Autosar，那么直接配置driver，也可以验证can通信，功能组件结构如下：
意味着可以直接使用FlexCan的API，省却了MCAL这一步骤。代码如下：
4 总结
- RTD是SDK和AUTOSAR的结合体，在代码中通过IpWrapper的方式有效地将AUTOSAR和硬件访问API结合到一起，这样只需要使用S32D即可完成AUTOSAR MCAL和SDK外设配置的要求；
- 代码开发难点：需要自上而下，理清AUTOSAR标准中驱动配置项，在此基础上优化SDK标准API，以达到用户使用ASR接口和SDK接口都能实现特定功能的目的；例如ASR API Can_Write( )，SDK API FlexCan_Ip_Send( )
- 个人认为，RTD架构是每个汽车芯片厂的必由之路，将整个SDK+AUTOSAR的生态部署好，逐步培养用户习惯；像EB这样的中间商日子可就难过了
