我的工作是关于汽车车机BSP部分。

汽车车机，其实基本和人们日常所用的手机一样，也是安卓平台的。所谓安卓，就是一层安卓服务包裹着Linux内核所形成的操作系统。

BSP组，主要工作内容就是负责soc的Linux系统部分的驱动移植、调试，及BUG解决。

从毕业到现在，工作也有大半年了。跟着前辈学习GPS模块的移植、调试，和BUG解决也有差不多两个月了。心里想着，是时候写一篇关于GPS驱动移植学习的总结和笔记了。

于是今天，我尝试着动手开始梳理这两个月来的所学所知。

目前汽车车机，所用的GPS都是属于高度集成的模块，所有的功能都在模块内部实现。用户只需要通过串口对数据进行读取与解析，就可以获取GPS信息。

我们公司目前所用的GPS导航模块有三种，这篇文章所要介绍，则是瑞士优北罗股份有限公司所研发制作的一款整合了运动、方向和高度传感器的NEO-M8L汽车惯性导航(ADR, Automotive Dead Reckoning)模块。该模块将陀螺仪和加速度传感器与u-blox领先的GNSS平台 - u-blox M8集成在一起，使其成为市场上性能最佳的室内/室外定位解决方案，是所有道路车辆和高精度导航应用的理想选择。

NEO-M8L模块中内置了u-blox突破性的“3D汽车惯性导航”(3D ADR)芯片技术。它利用车辆的速度信息以及模块的内置传感器，即使当卫星信号完全被遮蔽或终端设备没有安装于水平位置时，仍能提供准确的三维定位信息。此外，基于ADR技术的里程表功能还能提供正确和连续的行驶距离。

该模块能追踪所有可视的GNSS卫星，包括GPS、GLONASS、北斗和所有的SBAS系统 (欧洲的伽利略系统将在未来的固件版本中支持)。该模块目前支持两种GNSS系统的并行接收，并且能以高达每秒20次的速度输出定位信息。

安卓系统，实现了一系列的架构和分层，我们BSP移植驱动，主要完成两部分工作。 - 实现Linux驱动模块，保证Linux驱动对硬件的驱动能力； - 对接安卓hal层架构，实现hal层接口。

因为GPS属于高度集成的一体化模块，所有的功能都在模块内部实现，所以，对GPS的驱动移植，主要是为了匹配和实现安卓系统提供的HAL层接口，然后调用串口驱动的接口去读取对应串口地址的数据即可。

我们先来看一下安卓的GPS架构图。

由图可以知道，安卓的GPS架构由上到下是：app->framework->jni->hidl->hal，我们这篇文章，主要介绍从jni->hidl->hal层。

HAL 可定义一个标准接口以供硬件供应商实现，这可让 Android 忽略较低级别的驱动程序实现。借助 HAL，您可以顺利实现相关功能，而不会影响或更改更高级别的系统。

为了保证 HAL 具有可预测的结构，每个硬件专用 HAL 接口都要具有在 hardware/libhardware/include/hardware/hardware.h 中定义的属性。这类接口可让 Android 系统以一致的方式加载 HAL 模块的正确版本。HAL 接口包含两个组件：模块和设备。

模块代表打包的 HAL 实现，这种实现存储为共享库 (.so file)。hardware/libhardware/include/hardware/hardware.h 头文件可定义一个代表模块的结构体 (hw_module_t)，其中包含模块的版本、名称和作者等元数据。Android 会根据这些元数据来找到并正确加载 HAL 模块。

另外，hw_module_t 结构体还包含指向另一个结构体 hw_module_methods_t 的指针，后面这个结构体包含指向相应模块的 open 函数的指针。此 open 函数用于与相关硬件（此 HAL 是其抽象形式）建立通信。

设备是产品硬件的抽象表示。

设备由 hw_device_t 结构体表示。与模块类似，每类设备都定义了一个通用 hw_device_t 的详细版本，其中包含指向特定硬件功能的函数指针。

hidl的官方标准定义为：HIDL是HAL接口定义语言（简称 HIDL，发音为“hide-l”），是用于指定 HAL 和其用户之间的接口的一种接口描述语言 (IDL)。

安卓官方设计 HIDL 这个机制的目的，主要是想把框架（framework）与 HAL 进行隔离，使得框架部分可以直接被覆盖、更新，而不需要重新对 HAL 进行编译。

HIDL 接口具有客户端和服务器实现：

- HIDL 接口的客户端实现是指通过在该接口上调用方法来使用该接口的代码。

- 服务器实现是指 HIDL 接口的实现，它可接收来自客户端的调用并返回结果（如有必要）。

在从libhardware HAL 转换为 HIDL HAL 的过程中，HAL 实现成为服务器，而调用 HAL 的进程则成为客户端。默认实现可提供直通和 Binder 化 HAL。

上图为HAL的几个发展历程，方式2为目前我的开发环境所使用的直通方式，框架和HAL之间通过HIDL接口实现通信，硬件厂商负责服务器的实现。

下面从系统服务方面介绍一下系统启动，获取gps.ublox.so（gps hal驱动编译生成的文件）流程。

①、首先介绍GNSS的HIDL接口，编译生成"[email protected]"接口共享库，客户端和服务器之间就是通过这些接口来工作的，服务器端需要做的就是实现该接口。

接口编译脚本如下：

②、rc文件启动服务[email protected]

[email protected]启动服务[email protected]

[email protected]文件内容如下：

[email protected]服务由Android.bp编译得到，其次还包含了HIDL接口"[email protected]"，Android.bp文件部分内容如下：

我们看到service.cpp，它将对提供的-impl 库执行dlopen() 操作，并将其作为 Binder 化服务提供，service.cpp代码如下：

③、"[email protected]"是接口的具体实现。

-impl 库也由Android.bp编译而成，其部分内容如下：

④、HIDL_FETCH_IModuleName 函数

为了让 HAL 在直通模式下运行，Gnss.cpp 必须具有 HIDL_FETCH_IModuleName 函数，函数内容如下：

这个函数会加载gps.ublox.so库。

jni是framework与hidl hal之间的一层，为java语言实现的framework调用c++语言实现的hidl hal代码提供接口。

hidl文件位置android/hardware/interface/gnss/1.0/default/Gnss.cpp。

hal层文件位置android/hardware/u-blox/gps/。

由3.2内容，可以知道，系统服务起来之后，hidl层最开始运作起来的地方就是HIDL_FETCH_IModuleName函数了，通过名字，我们可以知道，这个函数的意思是获取模块名，换句话来说，也就是获取3.1提到过的“hw_module_t”和“hw_device_t”这两个结构体。

我们先看到这个HIDL_FETCH_IModuleName函数第5行，这里调用了hw_get_module函数，这个函数会根据GPS_HARDWARE_MODULE_ID去找到对应的“hw_module_t”，hal驱动层“hw_module_t”如下：

可以看到.id和hw_get_module第一个参数相同，也是GPS_HARDWARE_MODULE_ID这个宏。

继续回到HIDL_FETCH_IModuleName函数，看到第8行，这里调用了module->methods->open函数，在函数内部，找到对应device之后，它会对第三个参数进行了填充，从而让HIDL_FETCH_IModuleName函数获取到对应的“hw_device_t”，open函数代码如下：

我们再看到HIDL_FETCH_IModuleName函数第10行，在这里，new了一个名叫Gnss的类对象出来，Gnss类对象就是hidl hal层的具体类。我们知道，一个类对象被new出来之后，它的构造函数就会被调用，构造函数内容如下：

在Gnss的构造函数第11行，它调用了gnssDevice->get_gps_interface函数，在上面hwModuleOpen函数第17行，可以看到有对gnssDevice->get_gps_interface赋值，那我们先来看看这个函数代码内容：

不过，设置回调结构体却是由上而下：jni->hidl->hal。

gps回调结构体在android/hardware/libhardware/inlcude/gps.h中定义，以下代码为非标准结构体：

可以看到，代码第13、14行，这是我们自己添加的回调，用于回调加速度、陀螺仪的信息，在标准结构体中没有这两行。

因为gps hal层驱动上报信息需要用到回调结构体，而这个结构体则需要hidl层定义实现这个结构体，然后再传递给hal层，让hal层得到这个结构体指针。

而hidl回调到jni层，也需要jni定义并传递一个类似的回调结构体。

所以，接下来，我们就来看一下，代码中是如何填充回调函数指针的。

①、hidl hal

可以看到第25行调用了mGnssIface->init函数，mGnssIface就是gps hal层的接口，忘记了的可以回到4.1看一下。

我们继续看mGnssIface->init函数是如何实现的，代码内容如下：

第4行，init函数调用initializeGpsCallbacks函数，而在第14行，initializeGpsCallbacks函数则对s_myIf.m_callbacks（s_myIf就是gps module的类对象）进行了赋值，也就是填充回调函数结构体指针。

到这里，hal到hidl层的回调指针就填充完毕了，接下来看看hidl层到jni层的回调指针。

②、jni

这是jni层中的代码，可以看到上面代码第32行调用了hidl接口的setCallback函数，其中传递的参数就是jni层所定义的回调结构体，我们回到hidl层中的setCallback函数：

可以看到hidl接口的setCallback函数其实就是hidl层为gps hal层填充回调结构体指针的函数。

在这个函数中，有这么一段代码——“sGnssCbIface = callback;”，显然，这就是在设置hidl回调到jni层的回调结构体了。

所谓ACC/GYR就是加速度/陀螺仪。

因为这个项目所带的惯导功能需要将ACC/GYR信息回调给app（地图软件），所以，需要从底层回调这些信息。

这里，我们需要一段详细的流程分析，从开始获取数据到上报数据结束。

gps hal层主线程，在init函数中创建，主要功能就是监测串口是否有数据产生，当有数据到来时，就调用解析函数解析数据，然后通过回调结构体中的各个回调函数，将他们回调到hidl层，然后再在hidl层中的函数中调用jni层的回调函数，从而将数据传递给jni层。

看到以上代码，首先这个init函数就是之前setCallback所调用的init函数。然后，再看到在这个init函数中，它调用了一个名为createGpsThread的函数，在这个函数中就创建了gps的thread，并将ubx_thread这个函数注册为了gps的thread函数。

可以看到，在ubx_thread函数的死循环中，注册了一个select多路复用（不熟悉多路复用的，可以看我另外一篇文章）。

而在上面代码的16行，则是调用了我们自己封装的一个select监测函数，对可读集合进行监控。

依旧是在ubx_thread函数中，首先是第5行，这里调用了一个叫checkRecvInitReq的函数，在这个函数里，调用了openSerial，打开gps和soc传输数据的串口。然后我们看到第18行，当监测到集合内可读事件的时候，就会调用readSerial去读取对应的串口。

这里的fdIsSet由我们调用标准的FD_ISSET函数封装而成，readSerial也是由我们调用read函数封装而成。

上述代码第13行，解析数据，这个解析算法由供应商提供，不需要我们关心。不过，我们需要关心一下第15行，这里调用了一个叫做onNewMsg的函数，函数内容很多，这里就不一一展示给大家看了。在我关注的重点里，这个函数主要是配置了gps模块输出何种数据，没错，gps要输出哪些数据是需要配置的，不配置的话就没有数据输出。比如acc/gry数据是属于UBX-ESF-MEAS数据，所以必须使能它才行。

再看到第16行，这里调用了一个Process函数，在这里，我们进行了gps信息的回调。

可以看到，上述代码第18、23行调用了acc/gyr的回调函数，这里的回调函数会将数据回调给hidl层。

hal层发出回调之后，会来到hidl层，hidl层代码如下：

可以看到，第19行和第42行，分别调用了jni层的回调接口，通过这个接口，就把数据给传递到了jni层。

到这里，安卓平台下的GPS架构介绍及驱动移植记录大概就介绍完了。

实际项目中，还是要结合实际问题进行分析。

要做驱动移植，对代码还是需要熟悉的，虽然大部分代码都会由gps模块供应商提供，但是在调试的时候总不能遇到问题就问gps模块供应商，而且gps模块供应商提供的驱动代码也只是标准代码，并不一定适合你的平台，还是需要部分调整的。

另外，在调试好gps hal层驱动代码之后，还需要对标地图app，需要将我们上传的数据格式和上报频率都更改为地图app所需要的才行。