讨论本文问题之前,先聊一个话题:“目前,CP Autosar已经支持Some/IP和DDS(Data Distribution Service),DDS看起来只是另一个协议而已,汽车上,真有必要搞DDS吗?”。针对这个问题,说一下个人理解。在CP Autosar中,Some/IP出现地更早,就目前,量产的车型中,也应该有了Some/IP的身影。可以说,Some/IP专门为汽车量身定制。对于DDS,在其他工控领域早已应用,只是近些年,随着汽车智能化的发展,尤其域控等新技术的应用,DDS逐渐拓展到了汽车领域。如果汽车最终要成为万物互联的一部分,那我更看好DDS,相对于Some/IP,DDS协议在其他工控领域早已应用,这使得万物互联实现更容易。从这个意义上说,DDS不只是比Some/IP丰富了Qos,而是其能更好的接入万物互联。当然,并不能说Some/IP就不用了,在整车设计阶段,会根据不同的场景,选用不同的方案,而不是绝对地只用某种方案。 1、交叉编译是什么
回到主题,最近在移植eProsima Fast DDS,目标机:芯驰的G9H。使用的开发环境:Ubuntu20.4。如上可以看出,在Ubuntu20.4上安装的eProsima Fast DDS,使用默认编译,即使编译出可执行文件,也无法在G9H运行,因为两者的架构不同,运行指令不一样。Ubuntu20.4对应x86_64,而G9H对应Arm aarch64。
所以,如果要在Ubuntu20.4编译出可以在G9H运行的可执行文件,就需要在Ubuntu20.4环境下安装目标机对应的工具链,编译出目标机能运行的可执行文件,这也就是我们常说的“交叉编译”。
对于Makefile,我是一个菜鸟。有需要学习的小伙伴,可以网上查阅资料。本文主要目的:提供一个makefile示例,希望能帮助移植eProsima Fast DDS到ARM架构的小伙伴。 2、Makefile编写
在Ubuntu20.4中,要编译出可以在G9H上运行的可执行文件,有几个问题要解决:
选用G9H对应的编译工具链;
调用Arm aarch64架构的eProsima Fast DDS动态库链接。
本文以HelloWorld为例,文件结构如下(部分),目标:编译出可以在Arm平台运行的可执行文件。
本文的源文件需要使用到eProsima Fast DDS动态库,且eProsima Fast DDS动态库(本文已提前编译好对应架构的动态库)需要是ARM aarch64架构,以便于生成可执行文件时能够有效链接,进而能够生成目标机对应的可执行文件,本文所需要的动态库(ARM aarch64格式)如下所示: