通常，傳感器系統設計會將微控制器(MCU)與更多的模擬電路與數字控制邏輯相結合，后者用于準確可靠地獲取并發送傳感器數據（圖1）。SBC可通過提供結合軟硬件與傳感器應用開發工具的測試平臺，來加快這些系統的設計。開發人員可以專注于優化所需的特性與功能以滿足其獨特應用的特定要求，而不必花時間重新創建眾多傳感器設計所通用的基本系統。

圖1：大多數傳感器系統都采用共同的設計，其中包含用于傳感器信號采集的微控制器(MCU)和模擬前端(AFE)、用于將傳感器數據發送至其他設備或主機系統的通信子系統

TexasInstruments和NXP推出的專業板級系統專門用于傳感器應用，結合了無線傳感器硬件和專業軟件庫，以及能幫助加快設計和測試這些應用的完整開發環境。

緊密集成的SBC

TexasInstrumentsSensorTag提供一種緊密集成的解決方案，可以在僅5x6.7x1.4cm的封裝內提供全面的傳感器處理系統。SensorTag基于TICC2650無線MCU的功能構建，并增加了一些必要的元器件，用于連接CC2650與在SensorTag板上構建的多個傳感器和用戶接口備（圖2）。

圖2：TexasInstrumentsSensorTag利用TICC2650無線MCU的無線通信及傳感器處理的集成功能，為傳感器應用的快速開發提供多個傳感器和接口

TISensorTag專門用于所連接傳感器應用的快速開發，是一個全面的、可支持許多不同開發風格的開發套件。實際上，開發人員使用其默認模式就可以開始快速處理傳感器數據。在以默認模式啟動后，SensorTag會向智能手機等支持低功耗藍牙的核心設備廣播自己。開發人員通過云端從SensorTag即可訪問傳感器數據，或者使用JavaScript和jQuery直接訪問數據。在此模式下，開發人員可以使用Android或iOS移動應用作為起點，或根據與套件一起提供的網絡應用項目樣例中的源代碼寫入獨立于HTML5平臺的代碼。

對于更復雜的定制應用，SensorTag硬件會提供一個基于開放式硬件解決方案構建的高級開發平臺。其中，開放式硬件解決方案旨在展示如何使用多樣化低功耗傳感器。開發人員可以使用稱為DevPack的子卡進一步擴展SensorTag，這使設計和測試其他類型的傳感器和致動器變得容易。需要特別說明的是，SensorTag和可用的DebugDevPack結合后，可提供一個實惠、全面的平臺，用于為傳感器應用開發定制軟硬件（圖3）。

圖3：TexasInstruments的SensorTagDebuggerDevPack用于為SensorTag增加測試和調試功能，包括JTAG調試功能、可簡化硬件添加的Grove連接焊盤（例如添加SeeedTechnology的Grove指紋傳感器時）

對于無線部署，SensorTag套件包括低功耗藍牙(BLE)堆棧，進而在TI實時操作系統(TI-RTOS)軟件環境中運行。TI-RTOS是一個實時、先占式、多線程操作系統，可以同步執行應用程序與BLE協議棧，此二者皆在RTOS內作為單獨任務運行。在此，BLE堆棧按最高優先順序運行，以幫助確?？煽客ㄐ拧?/p>

在SensorTag中，無線事務本身利用CC2650的集成RF核心，其中包括與模擬RF及基帶電路集成的ARM?Cortex?-M0處理器。盡管工程師無法對RF核心的M0處理器進行編程，但TI提供高級別、基于命令的應用編程接口(API)，可實現從主處理器上運行的代碼發布命令至RF核心。RF核心轉而使用其專用的4KBSRAM（用于數據）和ROM（用于代碼），以自主方式處理無線協議的時間關鍵型部分——減輕主CPU的負載，并保留資源供應用本身使用。

簡化的軟件開發

借助CC2650中的集成自主處理器——傳感器控制器引擎(SCE)，傳感器信號的處理可以同樣高效。正如RF核心可獨立地執行無線事務，SCE可獨立于主處理器控制傳感器和關聯的外設。因此，SCE可以運行模數轉換器(ADC)或通過集成的串行外設接口(SPI)輪詢數字傳感器而不用喚醒主處理器，從而消除了采集傳感器數據所需的的額外功耗和喚醒時間。

與RF核心不同，工程師可以對SCE進行編程。通過使用類C語言，開發人員可以編寫定制代碼來執行傳感器輪詢或應對特殊條件和處理要求。因此，開發人員可以創建更多動態傳感器處理功能，而不必依靠為傳感器數據采集設置外設時常用的這種靜態配置。TI針對傳感器代碼部署提供SensorControllerStudio(SCS)，這是一種用于為SCE編寫、測試和調試代碼的特殊軟件工具（圖4）。

圖4：開發人員使用TISensorControllerStudio軟件開發工具和類C語言對CC2650的集成傳感器控制器引擎進行編程。這會生成C源代碼，以納入專門在CC2650無線MCU上運行的主要應用中

SCS會生成傳感器控制器接口驅動程序，即一組C源文件。開發人員會轉而使用TICodeComposerStudio(CCS)編譯這些C源文件，其中的任何其他定制代碼專門作為主要應用的一部分在CC2650的ARMCortex-M3主機處理器上運行。

CCS是一個基于Eclipse的集成開發環境(IDE)，為TIMCU系列的應用開發和調試提供給了全套工具。在其開發功能中，CodeComposerStudio包括一個不斷優化的C/C++編譯器、源代碼編輯器、項目構建環境、調試器和分析器——全部通過IDE的單用戶接口訪問，該接口旨在方便開發人員完成應用程序開發的每個階段。

靈活的傳感器解決方案

NXP為其OM13078傳感器處理運動解決方案(SPM-S)采取了不同的方法。SPM-S以NXPLPC54102MCU為基礎，結合了NXP的OM13077LPCXpresso板與通過LPCXpresso的擴展接口連接的傳感器擴展板（圖5）。如圖所示，傳感器擴展板包括一個用于無線通信的BLE模塊(AMS0002)和多個用于溫度、壓力、環境光和距離的傳感器，以及用于更復雜的運動檢測應用的加速計、陀螺儀和磁力儀傳感器。

圖5：NXP提供了一種傳感器解決方案。該方案結合了LPC54102LPCXpresso板與裝載多個傳感器的擴展板，以及包括完整傳感器軟件庫的全套開發環境。

對于隨附的運行時間軟件環境，NXP提供其LPC傳感器框架，其中包括系統軟件和傳感器處理軟件（圖6）。正常操作期間，LPC54102MCU會對傳感器進行采樣，并使用BoschSensortecBSXLite庫處理傳感器數據。通過無線BLE通信或LPCXpresso板支持的多個主機接口中的任一接口，可將結果進一步發送至其他設備或主機處理器。

圖6：開發人員在NXP的LPC傳感器框架上構建傳感器應用，該框架提供全面的運行時間環境，包括系統服務和傳感器信號處理，以及通過BoschSensortecBSXLite庫對傳感器融合應用的內置支持功能

傳感器融合架構

除了從多個傳感器收集數據的基本功能外，SPM-S解決方案還具有通過專為高級情境感知應用而設計的傳感器融合算法合并多個傳感器輸出的能力，因此在眾多解決方案中脫穎而出。傳感器融合功能結合了多個傳感器的結果，可提供無法從任何單個傳感器獲得的信息。例如，專門識別方向的應用需要加速計、磁力儀和陀螺儀傳感器的組合結果。NXP專門設計了SPM-S系統，以使用系統中包括的傳感器融合軟件來匯總多個實體傳感器的數據。

SPM-S架構中深度嵌入了對傳感器融合的支持功能。正如典型的傳感器系統那樣，SPM-S架構會將傳感器設備識別為連接至SPM-S硬件的獨特實體設備。軟件使用sensors.h傳感器頭文件中提供的唯一ID訪問每個設備（圖7）。

圖7：每個實體傳感器都可以通過傳感器頭文件sensors.h中的PhysSensorId計數器中定義的唯一傳感器ID來識別

要在應用層級支持傳感器融合，SPM-S架構可利用其在底層軟件層支持虛擬傳感器來擴展此基本概念。單個虛擬傳感器包含多個物實體傳感器，這些傳感器的結果按照傳感器融合算法合并后產生新信息。

例如，對計算方向信息所需的加速度計、磁力儀和陀螺儀傳感器數據進行合并而產生的傳感器融合結果，會由虛擬方向傳感器傳回。在SPM-S開發環境中，開發人員可以指定系統的SensorMap陣列中的虛擬傳感器（圖8）。在此陣列中，會將每個虛擬傳感器列為單個條目，并由該條目指定該虛擬傳感器使用哪些實體傳感器。

圖8：SensorMap陣列描述了向虛擬傳感器提供數據的物理傳感器。例如，方向的虛擬傳感器使用加速計、磁力儀和陀螺儀等實體傳感器

SPM-S架構中的另一個深度嵌入功能，可以在一個虛擬傳感器中結合多個傳感器的結果時幫助維持同步。

準確的傳感器融合結果需要準確計時，以確保按傳感器融合算法只合并相同“時間點”的樣本。在SPM-S中的中斷驅動采樣期間，傳感器會按預先定義的速率自主采樣并在結果就緒時產生中斷。每個中斷驅動的傳感器都有關聯的中斷處理程序，中斷處理程序只是在發生中斷時存儲時間戳；實際的傳感器結果讀取在后續服務程序中執行。此方法有助于維護所需的準確時序數據，以從多個單獨物理傳感器的數據生成準確的虛擬傳感器結果。

結論

基本無線傳感器系統的設計可能會形成影響項目時間表，以及不利于應用本身的重大挑戰。專業的單板計算機為傳感器處理提供成熟可靠的軟硬件基礎，讓各公司可以將資源更明確地集中于差異化的傳感器應用。通過使用SBC及其關聯的開發環境，工程師可以快速開發傳感器應用，甚至擴展基本的軟硬件以打造滿足更復雜要求的定制解決方案。