AUTOSAR配置中的PostBuild、Precompile、Linktime

>>>点我返回《AUTOSAR专栏》目录

目录

1. 缘由
2. 编译基础知识回顾
3. 为什么需要配置？
4. Pre-compile time
5. Link time
6. Post-build
7. 总结

1.缘由

在AUTOSAR的配置软件中，经常可以见到PostBuild、Precompile、Linktime这三个的影子，所以想搞清楚它们的区别，以及知道大概是干什么的。

1）DaVinciCFG中

2）EB工具中

3）在买AUTOSAR模块时

2. 编译基础知识回顾

在研究之前，先复习一下编译过程的基础知识

注意：

静态库是经过编译的二进制文件。在链接阶段，引用库一旦链接成功，将汇编生成的目标文件与引用的库一起链接打包到可执行文件当中。

预处理Preprocessing：

1、处理一些#开头的预处理指令，比如#if等

2、进行宏定义的替换

3、去除代码注释

编译Compilation：把.C文件编译生成汇编代码.asm

汇编Assemble：把.asm会变成中间文件.o

链接Linking：链接.o，.a，.lib文件生成可执行文件

3. 为什么需要配置

AUTOSAR标准了很多东西，所以在考虑问题方面，需要做的更加全面，以应付不同的使用软件使用场景。那么代码不可避免的就需要配置一些东西，比如使用宏定义来选择哪些模块不需要。再比如，传统的ECU汽车软件开发结束后，不修改代码是无法更新DBC的，即使功能类似，也做不到，只能重新开发，改动比较大，重新开发还要重新测试。因此AUTOSAR提出了Post-build的方案，运行在开发结束后对ECU的参数进行修改，以便于节省维护和测试成本。

按照编译过程的阶段，把配置方法进行分类，分为三类，分别是Pre-compile、Link time和Post-build，下面三类AUTOSR都是支持的。

4. Pre-Compile

实现手段：

1、通过宏定义来Enable和disable一些不需要的模块

2、使用宏定义来定义常量进行配置

在预编译阶段，就会把这些配置项进行宏替换，在实际使用当中，配置项放在单独的.c和.h文件中（*_Cfg.h, *_Cfg.c），比如Spi.c的配置项，放在了Spi_Cfg.c和Spi.h中，并且被配置的文件（比如Spi.c必须有源文件）不能是.o，.a等库文件或者中间文件，因为库已经被预编译过一次了，只能参与到链接。

优势：

1）节省运行时的开销，在预编译阶段就完成了配置

劣势：

1）参数配置是通过宏来实现，要求被配置的C要以源码形式提供，不能以库或者中间文件的形式

2）参数类型更改需要重新编译软件

*_Cfg.h中放宏定义

*_Cfg.c中放const常量

一个示例

eg.使能和关闭一个功能

Spi_Cfg.h:

#define SPI_DEV_ERROR_DETECT ON

Spi_Cfg.c:

const uint8 myconstant = 1U;

Spi.c（必须要有Spi.c的源文件，不能是库）

#include "Spi_Cfg.h" /* for importing the configuration parameters */
extern const uint8 myconstant;
#if (SPI_DEV_ERROR_DETECT == ON)
Det_ReportError(Spi_ModuleId, 0U, 3U, SPI_E_PARAM_LENGTH); /* only one instance available */
#endif

5. Link-time

eg.

Dem_Cfg.h

typedef uint16 Dem_EventIdType; /* total number of events = 380 => uint16 required */
#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_0 1U
#define DemConf_DemEventParameter_FLS_E_ERASE_FAILED_1 2U
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_0 3U
#define DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1 4U
#define DemConf_DemEventParameter_NVM_E_REQ_FAILED 5U
#define DemConf_DemEventParameter_CANSM_E_BUS_OFF 6U

Fls_Lcfg.c

#include "Dem_Cfg.h" /* for providing access to event symbols */
const Dem_EventIdType Fls_WriteFailed[2] = {DemConf_DemEventParameter_FLS_E_WRITE_FAILED_1,
DemConf_DemEventParameter_FLS_E_WRITE_FAILED_2};

File Fls.c (available as object code):

#include "Dem.h" /* for reporting production errors */
extern const Dem_EventIdType Fls_WriteFailed[];
Dem_SetEventStatus(Fls_WriteFailed[instance], DEM_EVENT_STATUS_FAILED);

6. Post-build

适合的场景：

1）适合ECU适配ECU的数据配置，比如产线出产后的一些标定和校准参数（这些参数事先在开发期间，不知道这些参数，一般每一台机器的因为硬件的微小差异导致每台机器的参数都不一样），或者每台机器的序列号、版本配置，都是属于Post-build time配置。

2）跨不同汽车版本（相同应用，不同配置）的ECU的可重用性，例如 与豪华版轿车的ECU相比，低配版轿车的ECU在总线上传输的信号更少，其他配置一样。

Post-build概述

就是单独把配置的参数放到一个内存区域，这个区域可以单独被刷写（通过flash擦写工具，通过UDS服务，通过Bootloader修改参数），这样做的一个好处是，OEM不需要知道代码逻辑，甚至不需要编译器（有些符合功能安全的编译器是要license才能使用的），也能修改BSW总的部分配置参数。

Post-build的工作流

如前面所说Post-build time是在链接得到二进制后，再进行修改的，下面是Vector给出的一个Post-build的工作流：

1）分为两大块，左边是TIER 1（零部件厂商，一般只做单个ECU的公司）的工作流，右边是OEM（整车厂，比如大众等）的工作流。

2）TIER 1通过Vector的两个工具Davinci Developer和Dabinci Configrator Pro配置完，开发后，再用编译器，编译链接，生成HEX文件。

3）OEM使用Dabinci Configrator可以更改软件的部分配置（不是全部），然后通过Post Build Tool生成二进制文件，单独更新配置到ECU

4）Tier1和OEM的主要区别是，OEM不需要编译器，并且只能配置部分参数。

Post-build分为两种

1）Post-Build Loadable：配置参数只有一份，单独保存在flash的一个固定区域（特定地址），可以修改参数配置，可以单独被更新。

2）Post-Build Selectable：配置参数预先配置好了几份放在flash的一个固定区域（特定地址），不能修改参数配置，只能从预先放好的配置中选择一份配置。

Post-build与Link time的区别

1）时间上的不同：Link time是链接时配置好，Post-build是编译链接完成后，再需要修改参数

2）Link time完成后，不支持单独修改参数，要想修改参数需要重新编译链接，Post-build支持单独修改参数（通过flash擦写工具，通过UDS服务，通过Bootloader修改参数）

7.总结

注意事项：

1）如果需要使用Post-Build中的Loadable或者Selectable，在购买AUTOSAR时需要选择，就是说要多给钱。

2）配置参数不是多有的BSW参数都可以配置，哪些参数可以配置，哪些不可以配置需要和OEM沟通好，在AUTOSAR标准中也有定义，比如《AUTOSAR_SWS_COM.pdf》第129页。

X：表示支持

–：表示不支持

>>>点我返回《AUTOSAR专栏》目录
扫描下方的二维码关注“汽车软件攻城狮”可第一时间获取更新！