MTK 展锐 高通 sensorhub架构

一、MTK平台

MTK框架可以分为两部分，AP和SCP。
AP是主芯片，SCP是协处理器，他们一起工作来处理sensor数据。

SCP 是用来处理sensor和audio相关功能和其他客制化需求的一个协处理理器，MTK SCP选择freeRTOS作为操作系统，CHRE是处理传感器相关操作的专门任务。

kernel层负责汇总处理sensor传输上来的数据，以及处理应用层传递下来的指令。

hal层是硬件抽象层，具有硬件供应商实现的标准接口，允许Android不了解低级别的驱动程序实现。sensor service通过动态链接的方式加载hal层模块。经过动态链接，service可以调用hal层的函数，方便将控制传递，也可以从hal层获取数据。这样使用hal就可以在不影响或修改更高级别系统的情况下实现功能。

framework层中sensor service 能创建实例对象，并增加到service manager中，同时可以从驱动中获取原始数据并发送到客户端。

应用层中的应用可以发送调用sensor的指令到下层，同时也可以获得下层传来的传感器数据并进行分析处理。

整个sensor体系中包括：应用层、framework层、jni、hal层、kernel层、SCP/CHRE。

因为对于日常生活来说有一部分sensor是使用频率是很高的，所以必然也伴随着手机功耗的增加如果每次都是CPU进行处理的化，而且CPU一旦休眠还伴随着sensor会停止工作，为了优化手机使用Google和MTK分别开发了CHRE 和SCP 进行sensor控制。

SCP是处理客制化需求的协处理器。

SCP 是用来处理sensor和audio相关功能和其他客制化需求的一个协处理理器，MTK SCP选择freeRTOS作为操作系统，CHRE是处理传感器相关操作的专门任务,它的架构如下

然后是CHRE:

在SCP下，MTK传感器集线器功能是在google CHRE ar上开发的,chre（Context Hub Runtime Environment）是一种事件驱动的体系结构，也可以被视为操作系统。

黄色部分是事件队列，CHRE只有一个while循环来处理事件队列中的头事件。如果以前的调用尚未完成，CHRE将无法调用队列中的一个任务。因此，没有优先级概念，当前事件队列处理只能

被中断中断。默认情况下，CHRE在事件队列中最多支持512个事件。CHRE的目的是实现实时性和轻量级，因此事件队列中调用的所有任务都必须快速运行。CHRE中的驱动程序实现称为nano hub app。

二、 展锐平台

展锐平台 Sensor Hub驱动添加
sensor hub 架构

上图是展锐平台sensor hub 的整体架构图。

sensor hub 分为三部分，AP、sensor hub、sensors。

外部的 sensor IC 通过 I3C、I2C、SPI 挂载于 sensor hub 核，sensor hub 核通过 SIPC 通讯方式与 AP 核进行交互。

对于图中各部分模块的解释：

sensor hub HAL：实现 Android 定义的标准 sensor HAL 接口。
sensor hub driver：将 HAL 层下发的命令传递给 sensor hub；将 sensor hub 反馈的信息及上报的 sensor 事件传递给 HAL 层；提供调试接口。
sensor hub algo：sensor 算法源码，以库方式释放（闭源）。
sensor hub manage：处理 AP 发送的命令；采集和上报 sensor 数据。
sensor driver：sensor 的驱动代码，被 sensor hub manage 调用。

三、高通平台

高通从SDM845平台开始，Sensor使用新的架构SEE（Sensors Execution Environment），和之前架构不同，新的架构有着太多的优点。

首先，先对比下新架构和旧架构的不同。

图1

从上图可以看到，新架构简化太多，SEE充当了Core层的重要角色。负责传送request，接收event。

下面，了解下SEE和旧框架的对比。

图2

接着，我们看下Sensor之间数据如何传输。

先看下see中各部分的定义。

图3

图4

说明：

1. 所有包含 to，from和sensors之间的传输都是通过request和event 消息来完成的。其中，（1）消息被定义成Protocol buffer的格式，通过nano PB generator，encoder和decoder来完成编解码生成Protocol buffer格式的数据。（2）buffer的长度，message ID，和时间戳等等通过SEE框架中metadata来进行传输。
2. Request消息被编码成data stream用来enable、disable或者configure。其中，（1）Request消息会使用一个特定的SUID。（2）一但目标sensor接收到Request消息，它会发送该request给sensor instance来进行相应的处理。（sensor instance表示着每个sensor的实例化，后面会进一步分析）。
3. Event消息被sensor instances 异步发送的它们注册的client中。client即完成接收数据。

接下来，我们要看下sensor和sensor instance。

1. Sensor & instance

(1) Sensor 用来产生 和/或 消费 异步数据。
(2) 每个sensor可实例化一次或多次sensor instances。其中：每个instance使用特殊配置来操作；发给sensor的任何request都会生成一个sensor instance 或者共享已经存在的instance。
(3) sensor instances 是请求式的创建，由sensor来终结。其中：sensors完全掌控他们匹配的instances的生命周期和配置信息，并且负责发送配置更新和初始状态events给他们的clients；Vendors强烈建议所有的clients提供及可能少的实例；stream data通过一个instance产生，并发送给所有激活的clients。
(4)一个单独的sensor instance 可以通过多个sensor来共享和配置。

2. 物理sensor 驱动的主要工作。

Sensor：
（1）在初始化期间查找sensor硬件，并在硬件当前可用的情况publishes availability。
（2）publishes所有相关带有正常参数的attributes；
（3）获取所属的SUID。
（4）获取配置信息并从registry中获取calibration的数据。
（5）管理来自client的requests；
（6）当request进入时，根据不同信息来建立/更新/删除 instances。
（7）管理sensor硬件的用电；
（8）管理COM bus的用电；
（9）在析构过程中释放所有资源。

Instance：
（1）管理COM bus用电，
（2）根据request编程符合自身硬件的code。
（3）当硬件配置改变时Publishes 配置event。
（4）Publishes data event。
（5）Publishes 所有错误的events。
（6） 在析构过程中释放所有资源。

Protocol Buffer 和 Nanopb

Google Protocol buffer是一种可以用在不同语言和平台上序列化数据结构字节流的数据格式。
数据结构信息定义在一个以.proto为后缀的文件中。
.proto后缀的文件可以通过编程的方式将一个Protocol buffer编译生成数据结构（data structures）。
可以通过 https://developers.google.com/protocol-buffers/ 来获取更详细的介绍。

Nanopb是一种用c语言实现google Protocol buffers的工具。详细介绍可以访问：https://jpa.kapsi.fi/nanopb/

高通官网也有对应的855 sensor over 文档