如何使用NXP RTD技术来完成AUTOSAR与NON-AUTOSAR的结合--以S32K3系列为例

目录

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要做这样？

我们首先从开发流程来看：

1. 常规SDK开发流程：使用NXP提供外设配置工具(如S32D)配置外设--->>使用SDK提供的常规API开发-->编译调试；
2. 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 总结

1. RTD是SDK和AUTOSAR的结合体，在代码中通过IpWrapper的方式有效地将AUTOSAR和硬件访问API结合到一起，这样只需要使用S32D即可完成AUTOSAR MCAL和SDK外设配置的要求；
2. 代码开发难点：需要自上而下，理清AUTOSAR标准中驱动配置项，在此基础上优化SDK标准API，以达到用户使用ASR接口和SDK接口都能实现特定功能的目的；例如ASR API Can_Write( )，SDK API FlexCan_Ip_Send(  )
3. 个人认为，RTD架构是每个汽车芯片厂的必由之路，将整个SDK+AUTOSAR的生态部署好，逐步培养用户习惯；像EB这样的中间商日子可就难过了