一、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 文档
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
