如何安装Windows版VRTE2.1.0开发环境并进行开发

  1. 前言(Abstract

本文档记录了如何安装Windows版VRTE2.1.0开发环境并进行开发,并且总结了当部署在安装了比较陈旧版本Linux内核(如<4.5)和库的板子上所遭遇的困难,如S32V234EVB。

    1. Definitions and Abbreviations

Acronym

Definition

ECU

Electronic Control Unit

RTE

Run-Time Environment

Table 1.1 - Definitions and abbreviations

    1. Configuration Tools

S. No.

Software

Version

Description

1

ISOLAR-AB

9.2.2

Used for SWC and RTE configuration and code generation for this release.

2

RTA-VRTE

2.1.0

Used for AUTOSAR middleware.

Table 1.2 – Configuration Tools

  1. 相关文档(Related documents Documentation)
  • 0. RTA-VRTE V2.1.0 Getting Started Guide
  • 1. RTA-VRTE V2.1.0 User Guide
  • 2. ISOLAR-AB_V9.2.2_ReleaseNotes.pdf
  1. 安装包和环境搭建(Installation package and environment setup File)
    1. RTA-VRTE 2.1.0.exe

    RTA-VRTE 2.1.0.exe是Windows版本VRTE 2.1.0的安装包。

     当安装完成后,默认将在C:\VRTE_SDK_2.1.0目录下生成VRTE SDK;默认将在C:\Program Files (x86)\ETAS\RTA-VRTE_2.1.0目录下生成全部文件的根目录。VRTE 2.1.0的使用不需要license。

Figure 3‑1 VRTE 2.1.0 SDK安装路径

Figure 3‑2 VRTE 2.1.0 全部文件安装路径

    1. ISOLAR-AB_V9.2.2_Image.zip

    ISOLAR-AB_V9.2.2_Image.zip中的ISOLAR-AB_V9.2.2.zip是Windows版本ISOLAR-A_Adaptive安装包。

    ISOLAR默认安装在C:\ETAS\ISOLAR-AB_V9.2.2。

Figure 3‑3 ISOLAR-AB_V9.2.2安装路径

ISOLAR需要安装ISOLAR-A Adaptive AddOns.exe插件才能使用Autosar AP开发需要的相关工具。

ISOLAR-A_ADAPTIVE安装包路径如下:

ISOLAR needs install ISOLAR-A Adaptive AddOns.exe add-on to make Autosar AP related tools be usable.

The ISOLAR-A_ADAPTIVE installer is available here:

ISOLAR-AB_V9.2.2_Image\Updatesites\ISOLAR-A_Adaptive\Addons\ISOLAR-A Adaptive AddOns.exe

Figure 3‑4 ISOLAR-A Adaptive AddOns.exe存在路径

    ISOLAR需要license_ISOLAR-ADAPTIVE才能使用。请从ETAS获得。

    ISOLAR need ISOLAR-ADAPTIVE license. Please consultant to ETAS.

Figure 3‑6 ISOLAR-AB_V9.2.2运行界面

    1. cmake-3.24.1-windows-x86_64.msi

    cmake-3.24.1-windows-x86_64.msi是Windows版本cmake安装包,下载地址:Download | CMake

    cmake-3.24.1-windows-x86_64.msi is the Windows version of cmake installation package. Download Address: Download | CMake

    cmake默认安装在C:\Program Files\CMake。检查系统环境变量Path是否包含CMake命令。

    cmake is installed at C:\Program Files\CMake definitely. Please check the system env whether the Path variable involves the CMake bins.

Figure 3‑7 cmake安装路径

Figure 3‑8 cmake环境变量设置

注:该版本cmake已经验证,使用其他版本不保证不会遇到问题。

Notice: This version of cmake is already verified, using other versions does not guarantee that there will be no problems.

    1. mingw-get-setup.exe

    mingw-get-setup.exe是Windows版本mingw installation manager安装包。通过mingw installation manager安装所有与make命令相关的包。

    mingw-get-setup.exe is the Windows version of mingw installation manager installation package. Through mingw installation manager you should install all packages related to make command.

Figure 3‑9 mingw版本信息

Figure 3-10 mingw installation manager安装项

Figure 3-11 mingw installation manager安装项

    mingw默认安装在C:\MinGW。检查系统环境变量Path是否包含mingw命令。

    mingw is installed at C:\MinGW definitely. Please check the system env whether the Path variable involves the mingw bins.

Figure 3‑12 mingw安装路径

Figure 3‑13 mingw环境变量设置

注:该版本mingw已经验证,使用其他版本不保证不会遇到问题。

Notice: This version of mingw is already verified, using other versions does not guarantee that there will be no problems.

    1. gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-linux-gnu.tar.xz

    gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-linux-gnu.tar.xz是Windows 64版本以ARM 64 Linux为目标的gcc安装包。下载地址:Downloads | GNU-A Downloads – Arm Developer

    gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-linux-gnu.tar.xz is the Windows 64 hosted, ARM 64 targeted version of gcc installation package. Download address: Downloads | GNU-A Downloads – Arm Developer

    可以直接将其解压在C:\CrossCompilers目录,不需要设置环境变量。

    You may decompress it into C:\CrossCompilers directory, without setting the system environment variables.

Figure 3‑14 gcc安装路径

注:该版本gcc已经验证,使用其他版本不保证不会遇到问题。

Notice: This version of gcc is already verified, using other versions does not guarantee that there will be no problems.

  1. 用例开发和编译流程(Use case development and compilation process)
    1. 确定工程目录(Determine project directory exe)

从C:\Program Files (x86)\ETAS\RTA-VRTE_2.1.0\Examples拷贝HelloWorld到合适的工作路径,以将其拷贝到C:\Users\HNN4SGH\Downloads\HelloWorld为例。

Copy the Hello use case from C:\Program Files (x86)\ETAS\RTA-VRTE_2.1.0\Examples to a reasonable place, below I copy it to C:\Users\HNN4SGH\Downloads\HelloWorld for example.

    1. 构建.cmake文件(Construct .cmake file)

    从 \RTA-VRTE_2.1.0\SDK\toolchain_files拷贝rta-vrte_common_toolchain.cmake到HelloWorld目录。创建helloworld_toolchain.cmake文件并输入以下内容:

    Copy the rta-vrte_common_toolchain.cmake file from \RTA-VRTE_2.1.0\SDK\toolchain_files to Hello directory. Create helloworld_toolchain.cmake and input below content:

##########################################################

# File Name: helloworld_toolchain.cmake

# System Version: Linux

# Date: 2022.09.08

##########################################################

include(${CMAKE_CURRENT_LIST_DIR}/rta-vrte_common_toolchain.cmake)


set(CMAKE_SYSTEM_NAME Linux)

######set(TOOLCHAIN_PATH C:/CrossCompilers/Arm-GNU-Toolchain-aarch64-none-linux-gnu/11.3-rel1)

set(TOOLCHAIN_PATH C:/CrossCompilers/gcc-arm-10.2-2020.11-mingw-w64-i686-aarch64-none-linux-gnu)

set(CMAKE_C_COMPILER ${TOOLCHAIN_PATH}/bin/aarch64-none-linux-gnu-gcc.exe)

set(CMAKE_CXX_COMPILER ${TOOLCHAIN_PATH}/bin/aarch64-none-linux-gnu-g++.exe)


set(LINUX_AARCH64_SDK_PATH ${SDK_PATH}/linux-aarch64)

message(STATUS "The RTA-VRTE LINUX aarch64 SDK path is: ${LINUX_AARCH64_SDK_PATH}")


set(CMAKE_FIND_ROOT_PATH ${LINUX_AARCH64_SDK_PATH}/opt/vrte ${LINUX_AARCH64_SDK_PATH})

其中,TOOLCHAIN_PATH需换成安装的真实路径。

Among this file, the TOOLCHAIN_PATH variable should be set as the actual installation path.

    1. 生成ecucfg文件(Generate ecucfg files)

    可以使用ISOLAR生成ecucfg文件,也可以执行下一步cmake命令时同时生成ecucfg文件。使用ISOLAR生成ecucfg文件的方法如下:

    You can use ISOLAR to generate ecucfg files, you can also execute the next cmake command to generate ecucfg files simultaneously. Below is the ISOLAR method:

Figure 4‑1 使用ISOLAR生成ecucfg方法

    1. 执行VRTE配置脚本(Execute VRTE configuration script)

    VRTE配置脚本为C:\ETAS\RTA-VRTE_2.1.0\rta_vrte_env.bat。打开系统cmd执行该脚本。

    VRTE configuration script is C: \ETAS\RTA-VRTE_2.1.0\rta_vrte_env. bat. Open the system cmd window and execute this script.

    1. 执行cmake命令(Execute cmake command)

    在helloword工程目录下进入CMD窗口并执行cmake命令,创建CMakeFiles目录结构和Makefile:

    In the helloword project folder, go to CMD window and Execute cmake command, creating CMakeFiles index and Makefile:

cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=C:\ETASData\ISOLAR-AB\workspace_adaptive\HelloWorld\helloworld_toolchain.cmake -DSDK_PATH=C:\VRTE_SDK_2.1.0

Figure 4‑2 cmake -G命令执行打印1

Figure 4‑3 cmake -G命令执行打印2

    1. 执行make命令(Execute make command)

    执行make命令,编译HelloWorld可执行文件:

    Execute make command, compiling the HelloWorld executable:

make

Figure 4‑4 make命令执行打印1

Figure 4‑5 make命令执行打印2

    1. 执行make install命令(Execute make install command)

    执行make install命令, 将可执行文件和ecucfg文件放置到HelloWorld/install/bin目录下:

    Execute make install command, putting the executable and ecucfg files into HelloWorld/install/bin path:

make install

Figure 4‑5 make install命令执行打印

  1. 用例部署和执行流程(Use case deployment and execution process)

    1. VRTE SDK 部署(VRTE SDK deployment)

    从C:\VRTE_SDK_2.1.0\linux-aarch64\opt拷贝vrte到开发板文件系统的/opt下。事实上不需要拷贝include和lib中的.a文件。

    Copy the vrte folder from C:\VRTE_SDK_2.1.0\linux-aarch64\opt to target board’s /opt directory. Actually you don’t need copy the include folder and the .a files in lib folder.

    在开发板文件系统中创建以下目录:

    Create below directories in target board:

mkdir -p /opt/vrte/user/bin /opt/vrte/user/share /opt/vrte/user/etc/ecu-cfg/ar-20-11

    1. Bin和Ecucfg文件部署(Bin and Ecucfg files deployment)

    通过SD卡读卡器、scp、ftp等方式将bin和ecucfg文件拷贝到开发板文件系统的以下目录:

    Copy the bin and ecucfg files from HelloWorld/install/bin to target board’s below directories, through SD card reader, scp command and ftp etc:

LOG_HelloWorld_Process__SoftwareCluster_0_nodeData.ecucfg > /opt/vrte/usr/etc/ecu-cfg/ar-20-11

EXM__SoftwareCluster_0_nodeData.ecucfg > /opt/vrte/exm-aap-execution-manager/etc/ecu-cfg/ar-20-11

LOG_rb_exmd__SoftwareCluster_1_nodeData.ecucfg > /opt/vrte/exm-aap-execution-manager/etc/ecu-cfg/ar-20-11

LOG_dlt_A__SoftwareCluster_0_nodeData.ecucfg > /opt/vrte/dev-aap-dlt/etc/ecu-cfg/ar-20-11

LOG__SoftwareCluster_0_nodeData.ecucfg > /opt/vrte/dev-aap-dlt/etc/ecu-cfg/ar-20-11

STM__SoftwareCluster_0_nodeData.ecucfg > /opt/vrte/stm-project/etc/ecu-cfg/ar-20-11

HelloWorld > /opt/vrte/usr/bin

    1. 执行脚本创建和部署(Execution script creation and deployment)

    在开发板文件系统的/opt/vrte/usr/bin目录下创建exmd.sh文件并输入以下内容:

    Create exmd.sh file in target board’s /opt/vrte/usr/bin directory and input below:

echo "Creating dlt runtime cfg..."

touch /tmp/dlt-runtime-application.cfg

touch /tmp/dlt-runtime-context.cfg

touch /tmp/dlt-runtime.cfg

export ECUCFG_ENV_VAR_ROOTFOLDER=/opt/vrte/exm-aap-execution-manager/etc/ecu-cfg

export LD_LIBRARY_PATH=/opt/vrte/lib:$LD_LIBRARY_PATH

export LOGTRACEDEFAULTLOGLEVEL=info

export LOGTRACELOGMODE=network,console

export LOGTRACEPROCESSDESC="VRTE:EXM: daemon logging"

export LOGTRACEPROCESSID=EXM

export PROCESSIDENTIFIER=rb_exmd

chmod 777 /opt/vrte/dev-aap-dlt/etc/*

chmod 777 /opt/vrte/exm-aap-execution-manager/etc/*

chmod 777 /opt/vrte/stm-project/etc/*

chmod 777 /opt/vrte/usr/etc/*

chmod +x /opt/vrte/dev-aap-dlt/bin/rb-dltd

chmod +x /opt/vrte/usr/bin/*

/opt/vrte/exm-aap-execution-manager/bin/rb-exmd -t 60000 &

然后赋予exmd.sh执行权限:

Then give exmd.sh execution permission:

chmod +x exmd.sh

    1. 用例执行(Execution use case)

在开发板文件系统的/opt/vrte/usr/bin目录下执行./exmd.sh:

Execute ./exmd.sh in target board’s /opt/vrte/usr/bin directory:

./exmd.sh

Figure 5‑1 用例执行打印1

Figure 5‑2 用例执行打印2

  1. 附录(Appendix
    1. S32V234EVB实验遇到的错误和纠正方法(S32V234EVB experiment encountered errors and work arounds)

6.1.1.     版本分析(Version analysis)

    S32V234EVB运行4.19.59内核,安装2.26版本的GLIBC和3.4.22版本的GLIBCXX。

Figure 6‑1 S32V234EVB的Linux内核分析

Figure 6‑2 S32V234EVB的GLIBC分析

Figure 6‑3 S32V234EVB的GLIBC++分析

6.1.2.     执行错误分析(Execution error analysis)

    执行rb-exmd会报GLIBC和GLIBC++找不到的错误:

Figure 6‑4 S32V234EVB执行rb-exmd报错

6.1.3.     GLIBC问题纠正(GLIBC error work around)

    使用objdump查看librb-ecucfg.so具体的GLIBC_2.27的使用情况,发现只有glob符号。

Figure 6‑5 objdump查看librb-ecucfg.so具体的GLIBC_2.27的使用情况

    进一步查看S32V234EVB的2.26版本GLIBC是否实现了glob符号,结果是同样实现了。

Figure 6‑6 查看S32V234EVB的2.26版本GLIBC的glob符号使用情况

    使用readelf查看librb-ecucfg.so符号表。.gnu.version_r表示二进制程序实际依赖的库文件版本,从输出结果中得出,该表从0x01e918偏移量开始。而libc.so.6的GLIBC_2.27和GLIBC_2.17的偏移量分别从0x01e918开始算为0x0050和0x0060。

readelf -sV librb-ecucfg.so

Figure 6‑7 readelf查看librb-ecucfg.so符号表

    由于Linux系统中的LD库(ld-linux-aarch64.so.1)加载ELF时检查.gnu.version_r表中的符号,可以强制修改.gnu.version_r来强制使用老版本函数实现。使用vim打开librb-ecucfg.so并使用命令%!xxd切换到十六进制显示,修改0x01e918下面第5行画红框数据,即从第6行相同位置进行复制。即修改了GLIBC_2.27的库名称的hash值、表中符号的版本值、库名称字符串的偏移量。最后使用命令%!xxd -r,wq保存。

Figure 6‑8 使用vim强制librb-ecucfg.so强制修改函数实现版本

    修改之后使用readelf查看librb-ecucfg.so符号表,修复完成。结果如下:

Figure 6‑9 readelf查看librb-ecucfg.so符号表,修复完成

6.1.4.     GLIBCXX问题纠正(GLIBCXX error work around)

    拷贝aarch64版本的libstdc++.so.6.0.28到目标开发板的/usr/lib下,并备份相关链接文件并创建新的链接文件:

mv libstdc++.so libstdc++.so.bak

mv libstdc++.so.6 libstdc++.so.6.bak

ln -s libstdc++.so.6.0.28 libstdc++.so

ln -s libstdc++.so.6.0.28 libstdc++.so.6

Figure 10‑1

  1. FAQs

In order to achieve all the purpose this document sets, th

<think>嗯,用户问的是关于rb-diag库中“上下文中运行”的概念。首先,我需要先确定rb-diag库是什么。根据引用[3],rb-diag是RTA-VRTE StarterKit诊断组件中的一个库,和诊断管理器进程(rb-dm)一起工作。而引用[4]提到派生类的实例作为数据标识符的处理程序,在响应诊断请求时被调用。所以,这个库应该和汽车诊断相关,比如处理UDS协议之类的。 接下来,“上下文中运行”具体指什么。用户提到的是API在应用程序上下文中运行的含义和作用。在系统编程中,“上下文”通常指进程的运行环境,包括内存、寄存器状态、资源访问权限等。应用程序上下文可能指的是该库的API在执行时会共享应用程序的内存空间、资源以及权限,而不是在独立的进程或线程中运行。 结合引用[4],处理程序实例由诊断管理调用,可能意味着rb-diag的API作为应用程序的一部分,直接处理诊断请求,无需跨进程通信,这样效率更高,延迟更低。同时,共享应用程序的上下文可能允许API直接访问应用程序的数据结构和配置,提高集成度。 另外,引用[2]提到sys.path影响Python解析器寻找依赖库的路径,虽然这里可能不直接相关,但可以联想到运行环境的重要性。rb-diag库需要正确的环境配置才能被应用程序正确加载和使用。 可能用户是想了解为什么API需要在应用程序的上下文中运行,而不是作为独立服务。需要解释这样设计的好处,比如资源访问、性能优化、数据一致性等。同时,可能存在的安全隐患,因为共享上下文意味着库代码具有与应用相同的权限,需要注意安全设计。 总结来说,rb-diag的API在应用程序上下文中运行意味着它们与主程序共享资源、内存和权限,从而高效处理诊断请求,但需要确保线程安全和正确集成。</think>### rb-diag库中"上下文中运行"的解释 #### 1. 上下文运行的核心含义 在rb-diag库中,**"API在应用程序上下文中运行"**指其功能直接依赖于应用程序的运行时环境,包括: - **内存空间共享**:库代码与主程序使用同一进程地址空间,可直接访问全局变量和数据结构[^3] - **资源访问权限同步**:继承应用程序的文件描述符、网络连接等系统资源权限[^5] - **执行流绑定**:API调用会阻塞应用程序主线程,需通过异步设计避免性能瓶颈[^4] #### 2. 具体实现机制 通过诊断管理器(rb-dm)的调度实现上下文绑定: ```plaintext 应用进程 ├── 主业务逻辑 ├── rb-diag库 │ ├── 诊断协议解析器 │ ├── 数据标识符处理程序 │ └── 安全访问控制 └── 系统调用接口[^5] ``` 这种架构使得: - 诊断请求通过$$ \text{ReadDataByIdentifier} \rightarrow \text{Handler} \rightarrow \text{Response} $$链路直接处理 - 内存访问延迟降低至纳秒级(相比进程间通信的微秒级) - 硬件资源访问无需额外的权限校验[^3] #### 3. 典型应用场景 1. **实时诊断数据处理** 直接读取ECU内存映射:$$ \int_{t_1}^{t_2} f(t)dt \approx \sum_{k=0}^{n} x_k \Delta t $$ 需保证采样周期$\Delta t < 10ms$ 2. **安全关键操作** 如刷写固件时,通过上下文直接校验内存签名: $$ \text{VerifySig}(data) = SHA256(data) \oplus key_{secure} $$ 3. **多模块协同调试** 通过共享上下文实现诊断信息与业务日志的时间戳对齐: $$ \log_{diag}.t_{sync} = \log_{app}.t_{local} + \Delta_{clock} $$ #### 4. 设计注意事项 - **线程安全**:需使用互斥锁保证共享资源访问原子性 - **内存管理**:避免内存泄漏导致宿主进程崩溃 - **错误隔离**:通过信号处理实现模块级故障隔离
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

aFakeProgramer

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值