你们中任何一个和我一样喜欢公路旅行的人都会在卡车停靠站停过很多次。你就会知道根本就没有安静的卡车停靠站。即使所有的交通停止了，燃油泵停止了，车内单调的音乐停止了，它也不会安静下来。
当其他一切都消失后，你只剩下柴油发动机连续空转数小时的嗡嗡声。你可能会想，这不是在浪费燃料吗?如果他们要离开十多分钟，为什么不直接关掉引擎呢?
好吧，当涉及到这样的无聊问题时，互联网是所有知识的源泉，它会为他们这样做提供一些原因。对此的解释通常分为两大阵营:一是驾驶室舒适——司机们经常穿着它们睡觉——二是柴油车很难启动，尤其是在寒冷的时候。我不止一次看到的一个未经证实的事实是，空转十分钟比重新启动消耗的燃料更少。
所以这些事情都是有道理的，但你(或者，至少我)会有一种唠叨的感觉，让一个能够承载巨大负荷的巨型柴油发动机仅仅为了让加热器运行8小时，似乎有点过分了。显然，经济性并不差(否则他们就不会这么做)，但情况可能会发生变化，尾气也会加剧问题，所以，在这里就不详细说明了，我们正在努力提供辅助方法来卸载这些小任务，让主机承担主要的负载任务。
因此，这意味着电子产品并不是唯一存在功耗、卸载和休眠模式问题的领域。特别是当涉及到智能手机等电池驱动设备时，这种情况在过去几年的演变中与柴油卡车的例子惊人地相似。
智能手机与普通智能手机的区别之一，是各种应用中传感器数量的迅速增长。以前没有这么多，而且也没那么难对付。但随着传感器数量的爆炸式增长以及对计算的期望相应地提高，更有效地管理传感器成为了一种积极的趋势，从而产生了“传感器中心”的概念。
你可能会把传感器集线器想象成一个类似于微控制器的东西——它可以是，但它并没有那么简单。让我们往回看，看看问题是什么，以及我们是如何走到今天这一步的。我不会直接宣称这是对历史上发生的事情的准确再现，但这是一个逻辑流程，至少我能理解。
管理负载
最早的传感器只是提供数据，然后由处理器读取这些数据。您可以想象一个轮询循环，它以传感器规定的或与传感器协商的频率检查数据。虽然这样的“繁忙”循环听起来很忙，嗯，繁忙，但您必须意识到所涉及的频率是数百赫兹或数千赫兹的数量级-读取之间的时间就像纳米级处理器的一生。
要简化这个问题，最明显的答案是提供一个中断。至少，中断可以告诉处理器新数据已经准备好了，这样处理器就不必为传感器计时了。
在最基本的层面上，一些应用程序(甚至是操作系统)将请求传感器数据，然后使用这些数据来计算或做一些事情。这种计算所带来的结果是既增长又下降(正如我们将看到的那样)。
真正有趣的东西来自“传感器融合”——从多个传感器获取数据，并将其混合在一起，以提供更准确的融合数据或任何单独传感器无法提供的更高级别的信息。其中很多都是计算密集型的。即使是使用加速度计为eCompass提供倾斜补偿等相对基本的东西，也涉及许多人多年前就忽略的数学问题。
但是如果你开始添加越来越多的传感器，那么你的处理器就必须对各种各样的中断做出响应:这就开始消耗带宽，特别是如果每次都要融合数据的话。然而，部分负荷被推回到传感器上。虽然任何传感器都将提供对原始数据的访问，但许多传感器都在传感器内部提供一定程度的计算(可能是通过联合封装的ASIC)。
因此，例如，操作系统可能想知道它是否需要旋转屏幕，因为手机本身正在旋转。一种方法是监视加速度计数据，这样，如果达到特定的角度，操作系统就可以旋转屏幕。这可能涉及到在手机可能静止的长时间内进行大量监控(即使是通过中断进行的)。
另一种选择是将该逻辑构建到传感器中，这样除了“数据就绪”中断之外，还会有“旋转”或“倾斜”事件中断。如果这就是您所关心的(不太可能，但为了讨论的目的)，那么其他中断可以被禁用、掩盖或忽略，只有当感兴趣的事件发生时，处理器才会从它正在做的其他事情中分心。您可以对许多不同的事件进行此操作，具体取决于预期的应用程序。例如，除了“倾斜”事件外，Kionix还提供了“点击”和“双击”事件。
通过写入传感器中的特定寄存器，可以在有限的范围内配置此类事件，但用户可能希望添加更多智能来定制感兴趣的事件。例如，Kionix正在将状态机集成到他们的一些传感器中。这使得用户在定义导致中断的事件以及呈现给处理器的数据形式方面具有更大的灵活性。在Kionix的例子中，有两个状态机，允许的状态轨迹相当简单(单个下一个状态或重置)，但它提供了超出工厂定义事件的卸载级别。
管理电源
这些高级事件有助于解决带宽问题，但是依赖于主应用程序处理器来处理中断(即使选择得更明智)会产生更大的影响。如果手机上的处理器必须不断地监视传感器，那么它就永远无法入睡。这就像一个大的柴油发动机:即使它只处理像检查传感器这样的小事，它也必须在那里空转几个小时。这是一种过度杀戮和能量浪费。你想让处理器休眠，但如果处理器负责决定是否唤醒自己，那就不太好了。
显而易见的答案是卸载唤醒处理器所需的决策(或不真正需要处理器的事情)。最明显的解决方案是使用低功耗微控制器作为“传感器中心”，尽管SiliconBlue(现在是Lattice)正在定位他们的移动友好型fpga(别笑了-是的，他们曾经是-现在也是?)-将fpga放入小型消费品)到传感器中心应用程序中。
有一百万个微控制器可供选择，各种形状和大小。有些有更多的中断输入;有些则更少。大多数人说I2C和SPI(尽管似乎有一个明确的倾向于I2C -下次再说)。但现在微控制器被明确宣布为传感器集线器。爱特梅尔公司例如，苹果公司最近发布了一款集成了触摸和其他传感器功能的传感器集线器(他们声称这是首款包含触摸功能的单芯片解决方案)。今年夏天，我在谷歌上搜索了“传感器中心”，大多数链接都是关于这个设备的青金石(ROHM的一部分)今年早些时候发布。
所以现在要求较低的微控制器可以保持清醒并监视传感器，只有在重要的时候才唤醒主处理器。这就像在卡车上使用某种辅助动力装置，在卡车处于睡眠模式时为舒适的生物提供动力。
管理空间
当然，这为设计增加了一个组件(要么是板上的另一个芯片，要么是SoC中的另一个核心)。前几天我参加了一个对话，被问到微控制器是否真的可以与传感器集成。我最初的反应是，理论上这很好——如果这个传感器(或带有多个传感器的包)是唯一需要管理的传感器。否则，如果系统中需要额外的外部传感器，那么您仍然需要一个外部传感器集线器来处理这些传感器—最终会出现双集线器，这是一种浪费。
然后我注意到InvenSense提供的一个功能(我不确定它们是唯一的功能，但它们有助于说明这一点)。他们有一个九轴IMU，带有他们所谓的数字运动处理器(DMP)，可以进行我们一直在讨论的一些计算卸载。但他们也允许一个压力传感器-这是不包括在包装-计算工作。外部压力传感器没有连接到I2IMU正在使用的C总线;它直接被驱动到InvenSense IMU上，你可以称之为私有I2C总线。然后，IMU可以将压力数据以及IMU数据显示给处理器或传感器集线器。
在这方面，不是所有的传感器或多或少都是“平等的”，这个IMU开始像一个枢纽一样工作。鉴于此，您可以将其视为逻辑的下一步，即一路集成微控制器，以便其中一个传感器芯片最终也成为集线器。而不是其他传感器连接到I2C总线连接到处理器，它们与连接到超级传感器的总线相连，只有超级传感器与处理器通话。
当然，如果真的有可能像这样增加价值，那么显而易见的问题是，“哪个传感器应该有微控制器?”考虑到大多数集成都是与运动和位置相关的传感器进行的，为我们提供了10轴单元(甚至不包括它们可以提供的温度数据)，使用IMU似乎是最有意义的。
IMU已经巩固了自己作为智能手机传感器团队的永久成员(包括几个传感器)Windows 8要求)．除了这些传感器和其他一些必需的传感器之外，还有很多关于其他可能添加的传感器的讨论。比如湿度、辐射或物质检测(比如手机里的酒精测试仪)。
给定一个IMU也可以作为一个集线器，它就很容易附加其他传感器——只要这个集线器功能足够广泛，可以使用任何随机代码。目前的类似集线器的功能要具体得多(例如，需要一个压力传感器;而不是任何其他随机传感器)。
在整理完这些之后，我回到了另一个最近的传感器中心公告，这个公告来自圣微系统公司．当我第一次看到它时，我的注意力完全集中在它的“枢纽”部分，以及它可以管理各种ST传感器以及它们没有制造的传感器。我没有注意到的是，这些ST传感器是包含在集线器中的。它就在那里:一堆传感器和一个微控制器集成在一个单独的包里
我想到的另一件事是，对传感器的粗略讨论可能会在抽象中处理它们，这表明配置需要允许传感器的任意随机组合。但随着传感器迅速应用于手机和平板电脑等大批量消费品，创建有针对性的配置开始变得有意义。事实上，ST的设备瞄准的是运行Windows 8的平板电脑。它是否可以处理一些不太可能出现在平板电脑上的传感器，这完全是一个学术讨论。
这就把我们带到了现在。从一个或两个传感器直接与应用程序处理器通信，到一个单独的集线器对话器，再到一个传感器/集线器组合。采用分布式处理——有些在传感器专用集成电路中，有些在集线器中，有些在主处理器中。我希望看到更多竞争对手之间的竞争，看看这些配置如何继续发展。
但至少，你会看到越来越少的卡车在卡车停靠站空转。
*是的，我现在觉得自己对那次谈话的反应有点像个傻瓜。教育时刻:闭上嘴去听。
更多公司信息:
今天我们来看看传感器中心是如何发展的。空间和时间的限制意味着我们不能覆盖所有的变体和供应商;你还见过其他用于传感器数据管理的设备或方法吗?