读NXP RTD技术有感

shuizhonghua

目录

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代码包

参考链接:

https://www.nxp.com.cn/document/guide/getting-started-with-the-real-time-drivers-rtd:GS-AUTOMOTIVE-RTD

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这样的中间商日子可就难过了。

随着汽车MCU国产化替代的风越吹越大，以前传统模式下芯片厂的角色也会有所变化，直面终端用户，满足其定制需求，才能做出差异化。NXP做出了很好的尝试，那么有NXP背景的几家国产芯片厂自然而然也在这一局比试中抢到了先机。至此，国产MCU与主机厂或者Tier1的合作格局演变成了如下局面：

   

大浪淘沙，商海无情。对于勤劳隐忍的中国人来说，汽车MCU这块肥肉是肯定会被吃下的。

但在当前这种技术迭代飞速的大背景下，想必很多内卷到汽车MCU市场的芯片厂都会起个大早赶个晚集：首先是没有相应技术积累莽莽撞撞切换赛道，其次是没有明确的战略规划，不知道到底想要做什么，然后是作为新人厂商没有一个领路的导师(人话:带你抄近道的家教)，
最后回到最关键的中国人本身自带的权谋和内斗属性，在面临巨大的诱惑时，力气不会拧成一股绳。

路漫漫其修远兮，吾将上下而求索。

fl8111

读完您提供的NXP RTD技术介绍后，我了解到该技术是为了在符合AUTOSAR和非AUTOSAR产品中实现软件接口抽象而设计的。针对该技术的实际应用，我认为它能够有效提高软件的可移植性和复用性，对于汽车行业的软件开发具有重大意义。从Can Demo的介绍中，可以看出RTD技术在CAN通信中的应用十分广泛。总体而言，NXP RTD技术为汽车行业带来了很大的便利，对于推动汽车智能化发展起到了重要作用。在未来的工作中，我们还应不断深入研究该技术的应用和发展趋势，为汽车技术的不断进步做出贡献。