那些在传感器领域工作的人都在深入研究设备的底层细微差别和复杂性。如何精确，如何线性，如何连接，如何读取数据，如何融合数据…-如果你用心思考，有很多事情要考虑。
当然，你为之服务的用户——手机、平板电脑、医疗设备和工业传感器的用户——根本不关心这些东西。他们想要睡得安稳，知道这些传感器正在通过各种方法准确地检测他们分配的现象，系统正在正确地读取这些数据，并将它们转换成任何必要的形式，以在应用程序级别上提供简单而有意义的结果。
而且，在您和用户之间的是操作系统(OS)。操作系统现在对传感器的工作方式非常了解，它们正在制定一些道路规则。我们已经了解了Microsoft的人机接口设备(HID)需求之前但有一个皱纹对传感器的影响比其他东西更大。
大多数HID设备通过USB与计算机交互。最初的想法是，我们将通过键盘、鼠标等外围设备与计算机交互，这在很大程度上是正确的。这些外设使用USB。但是传感器现在是HID家族的一部分，而且它们不在USB上:它们通常在I上2C或SPI。Windows最初并不理解这些路径。
然而，其中一条途径已经打开;它被称为“HID over I”2C”(不包括SPI)。事实上，它从2012年就开始实施了，尽管现在对它的实际支持开始逐渐减少。但是，就像所有好的事情一样，有一个问题:握手要求。
Windows希望能够从传感器本身获得有关传感器的特定信息，而许多传感器并没有设置为与Windows协议交互。那你该怎么处理呢?
这是另一个角色传感器中心可以接受。我和微芯片公司谈过他们的新产品SSC7102传感器枢纽，为HID over I提供支持2C.这引出了一个显而易见的问题，那是什么意思?
这意味着它可以根据协议被Windows查询。你可能会觉得奇怪，因为它本身并不是一个传感器。但它可以作为附加传感器的代理。即使这些单独的传感器不直接支持Windows，集线器也可以维护一个表来跟踪它们，以及Windows可能在任何时候作为协议的一部分请求的必要的点滴信息。当被请求时，中心会代表传感器进行响应，而Windows对此一无所知。
当然，Windows期望看到的许多“传感器”实际上并不对应于任何特定的“真实”传感器。它们是虚拟或“复合”传感器，通过进一步的数据处理或传感器融合的魔法而创建。例如，“方向”被看作是一个传感器，但事实上，它是加速度计和陀螺仪的融合，可能还有磁力计的数据。指南针读数也是如此:你可能认为它只是传递磁力计数据，但它也需要使用加速度计数据来补偿手机(或其他设备)的倾斜，因此它也是一个复合读数。
传感器集线器的主要作用之一是执行生成这些复合传感器的计算。一个带有HID / I的传感器中心2C支持可以承担对Windows的所有附加的硬传感器和它生成的虚拟传感器进行计费的责任。在Microchip的情况下(可能还有其他情况)，你不需要编写代码来实现这一点;它们提供了开箱即用的功能。
与此同时，在谷歌领域，Android似乎没有同样的需求，或者至少它通过硬件抽象层(HAL)对它们进行了不同的管理。但这暗示了一些微妙而令人惊讶的事情。
Movea的Bob Whyte提出，Android Kit Kat版本(4.4)可能需要硬件传感器集集器。他指给我看他注意到的那个地方。这涉及到Android低功耗传感器的概念。
Android要求某些传感器能够在AP保持清醒状态的情况下运行。一个明显的例子是计步器传感器:如果你要跑一个小时，他们不希望AP一直开着。但无论何时AP启动，它都应该能够获得最新的、准确的步数。所以这些传感器必须是半自动运行的。指定为低功耗的传感器有:
- 地磁旋转矢量
- “重大运动”
- 一步探测器
- 步进计数器
这些都必须保持自己运行，并将结果存储在FIFO缓冲区中，这样当AP返回给它们时，就不会丢失任何东西。(虽然我认为有一个限制，因为缓冲区必须有有限的大小…)
所有的低功耗传感器都是复合传感器。通过要求它们是低功耗的，规范说你不能在AP上进行创建传感器值的计算;你需要使用AP外部的一些东西，这样AP就可以进入睡眠状态以节省电力。您可以在与AP相同的芯片上的其他核心上进行这些操作，尽管许多设计人员选择基于外部微控制器的集线器，因为它们可以构建在不那么激进的硅节点上，从而减少泄漏和降低功耗。
但是，如果您查看步进检测器传感器的描述，例如，您会注意到一个有趣的语句:“此传感器必须是低功率的。也就是说，如果不能在硬件中进行步长检测，则不应定义该传感器。”
传感器需要在硬件上完成。
这不是一个小要求，如果它意味着它看起来意味着什么。不久前，我们看了各种实现传感器集线器的方法．它们涉及硬件和软件解决方案的混合。虽然有硬件解决方案，但绝大多数使用软件——这主要是因为算法仍然在不断变化，即使部署到最终系统中也可能会发生变化。
那么谷歌是否要求在硬件中实现传感器集线器以兼容?也就是说，硬件是否意味着“门”——ASIC或FPGA?看起来确实是这样。(至少对于一个一辈子都在考虑硬件门的人来说……)
然而，有些事情说不通。这些东西不需要硬件提供的原始性能——与硅设计人员习惯处理的时间相比，所涉及的时间实际上是地质上的。而且，正如刚才提到的，大多数现有的集线器实现都是软件，涉及低功耗微控制器。
那么，谷歌真的会告诉每个人放弃他们基于mcu的集线器，转而使用fpga或asic吗?我的意思是，他们是打算收购一家FPGA公司还是什么?＊
硬件还有另一种可能的解释:传感器本身。加速度计是一种硬件传感器;而eCompass则不是，因为它是一个融合在软件中的组合。这就是他们的意思吗?
不，这也说不通，因为列表上的所有东西都是复合传感器，根据定义，复合传感器不是硬件。
我四处打听了一下，我惊讶地发现，这里的很多事情都是非常保密的，受到保密协议的保护。这是一个公共规范，但具体如何解释它，显然是不公开的。有一些只有受邀者才能参加的会议讨论这些事情，但没有人愿意公开明确说明这些话的含义。即使是和那些应该确切知道这些词的意思的人有过直接对话的人，也不愿意公开说他们有过这样的对话。
也就是说，我有一种强烈的感觉，上面的两个硬件解释——看起来有问题的——确实是有问题的。微控制器集线器似乎不太可能被弃用。也许编写该规范的人认为“硬件”是“除AP之外的任何东西”。
所以，假设你可以满足HAL关于传感器和中心如何处理AP的期望，按你想要的方式来做。软件，硬件，蒸汽，好吧，不是蒸汽，但是其他的任何组合都很好。我和怀特先生一起回顾了这个结论，只是为了让讨论回到原点，他同意了。
最后，补充一些观点:就在文章发表之前，怀特先生指出，微软在这方面似乎也不太严格地使用“硬件”一词。在他的建议下，我看了他们的“硬件认证”计划，其中包括很多在软件中完成的事情，“硬件”的含义包括软件开始变得更有意义了。
对他们来说，只要在PC(运行在主CPU上)上安装软件，任何事情都是“软件”。任何需要插入其他设备的东西，即使该设备包含运行软件的处理器，都是“硬件”。这与将“硬件”解释为“AP之外的任何东西，即使是在软件中实现的”是一致的。
这让我想起了多年前参加的一次客户会议(当时我在一家真正的硬件公司工作)。事情变得很紧张，直到我们意识到我们在用同样的词来描述不同的事情。有点像美国和英国…
*免责声明:为了记录，为了那些现在可能把内裤都拧成一团的法律人士，不，我不是说他们是。如果仅仅是巧合，谷歌正在计划收购一家FPGA公司，我对此一无所知(你必须用“它”这样的词来称呼律师)，这不是泄露或内幕信息。这纯粹是巧合。你现在可以退下了。
更多信息:
您如何看待操作系统需求对传感器的影响?它们有用吗?疼吗?