使用以微控制器為基礎的套件,快速實作內建 Alexa 的 IoT 設計

作者:Stephen Evanczuk

資料提供者:DigiKey 北美編輯群

語音助理已快速演進成任何智慧型產品的重要功能。在現有的雲端型解決方案中,Amazon 的 Alexa Voice Service (AVS) 已成為主流的語音助理,能提供立即可用的功能,可利用 Amazon 雲端資源進行語音辨識和自然語言處理。

然而,對開發人員而言,AVS 的效能需求和設計複雜度具有公認的高門檻,因此難以著手開發連網家庭和物聯網 (IoT) 用的更小型微處理器架構裝置。NXP Semiconductors 針對客製化應用設計一個能立即使用的解決方案兼公版設計,這款套件提供專為資源有限的裝置設計的 Amazon AVS 產品。

本文將說明開發人員如何使用 NXP 的開箱即用型解決方案,快速實作內建 Alexa 的設計。

什麼是 AVS?

自十年前問世以來,語音助理技術不斷迅速發展,帶動了智慧型揚聲器市場的成長。市場分析師預估,該市場已覆蓋美國三分之一的人口。在眾多競爭對手中,Amazon Echo 智慧型揚聲器具有領先市佔率。此產品利用 Amazon Web Services (AWS) 的成果來提供雲端型資源,可支援第三方 Echo 應用或 Skills。

藉助 Alexa Skills Kit (ASK) 及相關的應用程式開發介面 (API),開發人員可利用快速擴張的 Echo 智慧型揚聲器安裝版圖,針對其連網裝置增添一定程度的語音控制功能。透過這個方法,「可搭配 Alexa 操作」的智慧電視或恆溫器等連網產品,就可回應使用者的語音請求,以及從 Alexa 雲端接收到的相關指令 (圖 1)。此圖概述 AVS 並一窺其潛力。

使用者的語音請求以及從 Alexa 雲端接收的相關指令示意圖圖 1:建立 Alexa 應用或 Skills,開發人員就可讓連網產品透過 Amazon Echo 產品與使用者的語音指令進行互動。(圖片來源:Amazon Web Services)

內建 Alexa 功能的設計

「內建 Alexa」的智慧型產品,與「可搭配 Alexa 操作」的產品有所不同,可在 Alexa 語音功能裝置和 AWS 資源之間達到更順暢且低延遲的介面。這些產品將 AVS 直接整合到連網裝置的設計之中。使用 AVS 搭配 AWS IoT Core 平台,開發人員即可實作精密複雜的 IoT 應用,能讓使用者使用語音命令,藉由 Alexa 功能產品控制連網裝置並從這些裝置接收語音回應 (圖 2)。

Alexa 功能裝置中的語音介面及 IoT 通知工作流程示意圖圖 2:Alexa 功能裝置可讓使用者透過語音介面來控制裝置 (上方),或者從經由 AWS IoT Core 連至 Amazon Web Services 資源的 IoT 裝置 (下方) 接收通知。(圖片來源:Amazon Web Services)

但在過去,若要在此類 IoT 應用的核心處設計 Alexa 功能裝置,必須自行進行許多設計工作。若要使用雲端型 Alexa 服務,裝置需要運行多個 AVS 服務函式庫 [由 Android 或 Linux 平台上運行的 AVS 裝置軟體開發套件 (SDK) 提供],以便偵測喚醒詞、建立與 Alexa 雲端的通訊並處理指令,以執行支援的功能 (圖 3)。

AVS 裝置 SDK 及其資料流向示意圖圖 3:此圖展示 AVS 裝置 SDK 的組成部分及其資料流向。(圖片來源:Amazon Web Services)

若想支援這些服務函式庫,在設計 Alexa 功能裝置時,通常需要使用高效能的應用處理器以及至少 50 MB 的記憶體,才能符合 AVS 的處理要求。此外,這些設計往往會整合數位訊號處理器 (DSP) 來執行複雜的演算法,才能從吵雜的環境中擷取語音音訊,並支援語音助理裝置所需的遠場語音能力。最後,要建構有效的 Alexa 功能裝置,其系統要求通常已遠遠超過實際 IoT 裝置所需的成本和複雜性程度。

不過,在推出適用於 AWS IoT Core 的 AVS 整合服務後,Amazon 已針對要實作內建 Alexa 的產品,降低其所需的處理器工作負載和記憶體覆蓋區。使用此服務後,需要密集運算及大量記憶體的任務將會從 Alexa 功能裝置轉移至雲端上的相關虛擬裝置 (圖 4)。

AWS IoT Core 的 AVS 在雲端進行記憶體和處理密集型任務示意圖圖 4:AWS IoT Core 的 AVS 會將記憶體和處理密集型任務轉移至雲端,以便在資源受限的 IoT 裝置上實作 Alexa 語音助理功能。(圖片來源:Amazon Web Services)

實體裝置在處理責任減輕後可提供更多基本服務,例如安全傳訊、與 Alexa 可靠地收發音訊資料、任務管理,以及在裝置內部以及透過 Alexa 傳送事件通知等。實體裝置與 Alexa 之間的資料、命令及通知則透過高效的 MQTT (MQ 遙測傳輸) 傳訊功能,使用 MQTT 發佈-訂閱協定的多個保留主題進行傳輸。最後,輔助行動應用程式會與 Alexa 雲端互動,進行裝置註冊,以及需要與 Alexa 功能裝置進行的其他任何使用者互動。

將繁重的處理任務轉移到雲端時,AWS IoT Core 的 AVS 能讓嵌入式系統開發人員使用其更為熟悉的平台來打造內建 Alexa 功能的產品。開發人員可以使用 RAM 不到 1 MB、運行即時作業系統 (RTOS) 軟體的更合適微控制器來實作這些設計,而不是使用記憶體達 50 MB 且在 Linux 或 Android 上運行的應用處理器。事實上,採用AWS IoT Core 的 AVS 所建構的 Alexa 功能設計,比起在本機運行全套 AVS 服務的設計,BOM 可減少 50%。

雖然 AWS IoT Core 的 AVS 支援更高成本效益的執行階段平台,但實作內建 Alexa 功能且通過認證的產品依然是項艱巨的任務。沒用過 AVS 和 IoT Core 的開發人員,可能要花很多功夫理解並符合 AWS 在眾多層面上的要求,包括安全性、通訊、帳戶管理、使用者體驗 (UX) 設計等其他方面。無論是否熟悉 AWS 生態系統,所有 Alexa 產品開發人員都必須確保設計符合眾多規格與要求,才能獲得 Amazon Alexa 認證。

NXP 針對 Alexa 提供的微控制器架構解決方案,是立即可用的系統解決方案,能針對 AWS IoT Core 的 Amazon AVS 完全因應裝置端的軟硬體需求。

以微控制器為基礎的 Alexa 解決方案

NXP 的 SLN-ALEXA-IOT AVS 套件以 NXP i.MX RT106A 微控制器為基礎打造,可提供開箱即用的 AWS 連線能力、符合 AVS 需求的遠場音訊演算法、回音消除、Alexa 喚醒詞功能以及應用程式碼。此套件的 i.MX RT106A 微控制器以 Arm Cortex-M7 核心為架構,屬於 NXP i.MX RT106x 跨界處理器系列的成員之一,專為 IoT 邊緣運算而設計。RT106A 針對嵌入式語音應用而打造,可在 NXP i.MX RT1060 跨界處理器系列的基礎架構上增添特殊功能。此基礎架構更具有全套的周邊裝置介面、高容量的內部記憶體,並支援多種外部記憶體選項 (圖 5)。

NXP 的 i.MX RT1060 跨界處理器系列圖片圖 5:NXP 的 i.MX RT1060 跨界處理器系列整合 Arm Cortex-M7 微控制器核心以及全套的周邊裝置介面、記憶體及 IoT 裝置通常需要的其他功能。(圖片來源:NXP)

有了這些整合功能,i.MX RT106A 微控制器只要再搭配幾個元件,就能提供必要的硬體基礎,以實作 AWS IoT Core 的 AVS。NXP 的 SLN-ALEXA-IOT 套件將 i.MX RT106A 微控制器整合到系統模組中,其中含有 256 MB 的快閃記憶體、Murata ElectronicsLBEE5KL1DX Wi-Fi/藍牙收發器模組,以及 Diodes AP2202K-3.3TRG1 降壓轉換器 (圖 6)。

NXP 的 SLN-ALEXA-IOT AVS 套件系統模組示意圖圖 6:NXP 的 SLN-ALEXA-IOT AVS 套件系統模組在設計中利用簡單的硬體介面,將 NXP i.MX RT106A 微控制器與外部快閃記憶體及無線收發器整合在一起。(圖片來源:NXP)

SLN-ALEXA-IOT 套件具有語音板,能讓此系統模組更加完備,其提供三個 Knowles SPH0641LM4H-1 脈衝密度調變 (PDM) MEMS 麥克風、一個 PUI Audio AS01808AO 揚聲器和一個 NXP TFA9894D D 類音訊放大器。除了有 USB Type C 連接器可供電給套件並從個人電腦運行殼層主控台之外,此語音板還提供排針座,可連接乙太網路、序列周邊裝置以及 i.MX RT106A 微控制器通用輸入/輸出 (GPIO)。最後,此板件含有用於基本控制輸入的開關,以及用於視覺回饋的 LED 燈,可使用不同的 LED 顏色與明滅循環模式來滿足 Amazon AVS UX Attention System 的需求。

SLN-ALEXA-IOT 硬體在其系統模組和語音板的輔助下,可提供完整的平台,以在裝置端達到 AWS IoT Core 的 AVS 軟體處理。但如先前所述,設計 Alexa 功能 IoT 裝置時,除了仰賴硬體,同樣也仰賴經過最佳化的軟體。若使用 Amazon AWS IoT 的 AVS API 從頭開發這種軟體,開發人員需費力建構必要的資料物件並實作相關的通訊協定,因此會嚴重延宕專案進度。若開發人員想取得內建 Alexa 的認證,不僅要在設計中盡力符合 AVS UX Attention System 和 AWS 安全實務的要求,還需要滿足使用者與 Alexa 服務進行互動時的各層面需求,而這些都可能會導致專案進一步延宕。NXP 透過其完善的執行階段語音控制軟體環境解決這些問題。該環境以 Amazon FreeRTOS 為基礎,構建在一層軟體驅動程式上,可用於就地執行 (XIP) 快閃記憶體、連線及其他硬體元件 (圖 7)。

NXP 語音控制系統環境示意圖圖 7:NXP 語音控制系統環境以 Amazon FreeRTOS 為基礎,提供一套豐富的中介軟體服務,包括用於機器學習推論和音訊前端處理的韌體常式。(圖片來源:NXP)

NXP 的 Intelligent Toolbox 韌體奠定了此軟體環境的語音處理能力基礎,能針對所有音訊任務提供最佳化功能,包括機器學習 (ML) 推論引擎和 ML 音訊前端,以進行音訊訊號調整和最佳化。此外,還有其他中介軟體服務可支援安全連線、AWS 通訊及音訊能力。在這層健全的服務層之上,用於 AWS IoT Core、導入及其他應用控制功能的軟體會協調兩階段啟動程式的啟動作業,並支援以 AWS IoT OTA 服務和 Amazon FreeRTOS OTA 用戶端為基礎的空中 (OTA) 更新。

透過在此環境執行的原裝軟體,開發人員可立即啟動 SLN-ALEXA-IOT 硬體套件和全套 Alexa 功能應用程式,即可利用 NXP 示範帳號來存取 AWS IoT。NXP 文件提供詳盡的指引,說明如何啟動套件、佈建 Wi-Fi 憑證以及透過示範帳號完成 AWS 裝置的身份驗證。在此過程中,開發人員可使用軟體發行套裝隨附的 Android 行動應用程式與套件和 AWS 進行互動。此軟體套裝可從 NXP 網站用各個 SLN-ALEXA-IOT 套件提供的啟用代碼進行下載。執行幾個簡單的步驟後,開發人員即可立即透過 Echo 智慧揚聲器提供的同類 Alexa 語音互動方法,開始與套件進行互動。

SLN-ALEXA-IOT 套件和原裝軟體提供現成的平台,可快速開發具有 Alexa 能力的產品原型。此外,此套件的軟硬體也是快速的開發平台,能打造以 i.MX RT106A 微控制器為基礎的客製化 Alexa 功能設計。

客製化開發

以 i.MX RT106A 為基礎的 Alexa 解決方案,其軟體可透過 NXP MCU Alexa Voice IoT SDK 運用 NXP 語音控制執行階段環境的能力。此 SDK 是產品啟用後所取得的軟體發行套裝一部份,也是 NXP 的 Eclipse 架構 MCUXpresso 整合開發環境 (IDE) 的附加項目之一。其含有範例應用程式、驅動程式和中介軟體的完整原始程式碼,以及進行專用韌體能力二進位發行所用的標頭,如 NXP Intelligent Toolbox、ML 推論引擎和 ML 音訊前端等能力。

若需要快速部署 Alexa 功能產品,開發人員原則上可使用完整的 Alexa 展示應用程式,但需要稍作修改。在最簡單的情況中,開發人員只需要使用其專屬的安全憑證,將應用程式重新定位至自己的 AWS 帳戶,即可完成修改。NXP 有提供逐步說明,可協助完成此過程。

若要進行客製化開發,軟體發行版隨附的範例應用程式提供可執行的範例,能展示如何使用 NXP MCU Alexa Voice IoT SDK。開發人員可以先探索相關的範例應用程式,將精力放在特定的功能上,包括音訊前端、Wi-Fi 與藍牙連線、啟動載入等等,而不必直接埋首於完整的 Alexa 展示應用。例如,音訊前端範例應用程式就展示了使用 Amazon FreeRTOS 任務執行喚醒詞偵測的基本設計模式。

在音訊前端範例應用程式中,主要常式展示了開發人員如何初始化軟硬體的子系統,再使用 FreeRTOS xTaskCreate 函數啟動主應用程式任務 (appTask) 及主控台殼層任務 (sln_shell_task),然後才將控制權釋放給 FreeRTOS 排程器 (清單 1)。(請注意:只有在 FreeRTOS 排程器缺乏足夠記憶體時,才會調用 vTaskStartScheduler 啟動排程器。)

複製 void main(void) {     /* Enable additional fault handlers */     SCB->SHCSR |= (SCB_SHCSR_BUSFAULTENA_Msk | /*SCB_SHCSR_USGFAULTENA_Msk |*/ SCB_SHCSR_MEMFAULTENA_Msk);       /* Init board hardware.*/     BOARD_ConfigMPU();     BOARD_InitBootPins();     BOARD_BootClockRUN(); ...   RGB_LED_Init();     RGB_LED_SetColor(LED_COLOR_GREEN);       sln_shell_init();       xTaskCreate(appTask, "APP_Task", 512, NULL, configMAX_PRIORITIES - 1, &appTaskHandle);     xTaskCreate(sln_shell_task, "Shell_Task", 1024, NULL, tskIDLE_PRIORITY + 1, NULL);       /* Run RTOS */     vTaskStartScheduler(); ...} 

清單 1:NXP MCU Alexa Voice IoT SDK 發行版隨附的音訊前端範例應用程式,展示了基本的初始化要求,以及如何建立 FreeRTOS 任務,以進行主應用程式任務和主控台殼層任務。(程式碼來源:NXP)

在初始化音訊子系統後,主應用程式任務 appTask 會依序執行一對 FreeRTOS 任務。一項任務執行服務常式 audio_processing_task 以處理音訊輸入,另一項任務則將麥克風 PDM 輸出轉換成脈衝編碼調變 (PCM)。在執行額外的內務處理後,appTask 會進入無限迴圈,直至 RTOS 通知指出偵測到喚醒詞 (清單 2)。

複製 void appTask(void *arg) { ...// Create audio processing task     if (xTaskCreate(audio_processing_task, "Audio_processing_task", 1536U, NULL, audio_processing_task_PRIORITY,                     &xAudioProcessingTaskHandle) != pdPASS) ...// Create pdm to pcm task     if (xTaskCreate(pdm_to_pcm_task, "pdm_to_pcm_task", 1024U, NULL, pdm_to_pcm_task_PRIORITY, &xPdmToPcmTaskHandle) !=         pdPASS) ...RGB_LED_SetColor(LED_COLOR_OFF);       SLN_AMP_WriteDefault();       uint32_t taskNotification = 0;     while (1)     {         xTaskNotifyWait(0xffffffffU, 0xffffffffU, &taskNotification, portMAX_DELAY);           switch (taskNotification)         {             case kWakeWordDetected:             {                 RGB_LED_SetColor(LED_COLOR_BLUE);                 vTaskDelay(100);                 RGB_LED_SetColor(LED_COLOR_OFF);                   break;             }               default:                 break;         }           taskNotification = 0;     } } 

清單 2:在音訊前端範例應用程式中,主應用程式任務 appTask 會啟動任務來處理音訊並轉換麥克風資料,然後等候 FreeRTOS 通知 (taskNotification),告知偵測到喚醒詞 (kWakeWordDetected)。(原始程式碼:NXP)

而此範例應用程式中的音訊處理任務又會初始化喚醒詞韌體函數和喚醒詞偵測參數,然後也會進入無限迴圈,等待麥克風資料轉換任務發出 FreeRTOS 通知,告知麥克風資料已處理可供使用。此時,音訊處理任務會調用 Intelligent Toolbox 韌體函數,透過 ML 推論引擎來處理音訊資料並執行喚醒詞偵測 (清單 3)。

複製 void audio_processing_task(void *pvParameters) { ...SLN_AMAZON_WAKE_Initialize();     SLN_AMAZON_WAKE_SetWakeupDetectedParams(&wakeWordActive, &wwLen);       while (1)     {         // Suspend waiting to be activated when receiving PDM mic data after Decimation         xTaskNotifyWait(0U, ULONG_MAX, &taskNotification, portMAX_DELAY);   ...// Process microphone streams         int16_t *pcmIn = (int16_t *)((*s_micInputStream)[pingPongIdx]);         SLN_Voice_Process_Audio(g_externallyAllocatedMem, pcmIn,                                 &s_ampInputStream[pingPongAmpIdx * PCM_SINGLE_CH_SMPL_COUNT], &cleanAudioBuff, NULL,                                 NULL);           // Pass output of AFE to wake word         SLN_AMAZON_WAKE_ProcessWakeWord(cleanAudioBuff, 320);         taskNotification &= ~currentEvent;           if (wakeWordActive)         {             wakeWordActive = 0U;               // Notify App Task Wake Word Detected             xTaskNotify(s_appTask, kWakeWordDetected, eSetBits);         }     } } 

清單 3:在音訊前端範例應用程式中,音訊處理任務會初始化韌體喚醒詞引擎,然後等待 FreeRTOS 通知告知有可用的麥克風資料,最後會調用 NXP Intelligent Toolbox 韌體類比前端 (SLN_Voice_Process_Audio) 及 ML 推論引擎 (SLN_AMAZON_WAKE_ProcessWakeWord),進行喚醒詞偵測。(原始程式碼:NXP)

偵測到喚醒詞後,音訊處理任務會發出 FreeRTOS 任務通知,將此事件通知給主應用程式任務 appTask。收到此通知後,appTask 會立即閃爍藍色 LED (再次參見清單 2)。

完整的 Alexa 範例應用程式採用與上述較簡易型音訊前端應用程式相同的模式,但有大幅擴充基本程式碼庫,以支援完整的 Alexa 功能。例如,當 ML 推論引擎在 Alexa 範例應用程式中偵測到喚醒詞後,音訊處理任務會執行一連串與 Alexa 處理序列各個階段有關的 FreeRTOS 通知 (清單 4)。

複製 void audio_processing_task(void *pvParameters) { ...SLN_AMAZON_WAKE_Initialize();     SLN_AMAZON_WAKE_SetWakeupDetectedParams(&u8WakeWordActive, &wwLen);       while (1)     {         // Suspend waiting to be activated when receiving PDM mic data after Decimation         xTaskNotifyWait(0U, ULONG_MAX, &taskNotification, portMAX_DELAY); ...int16_t *pcmIn = (int16_t *)((*s_micInputStream)[pingPongIdx]);         SLN_Voice_Process_Audio(g_w8ExternallyAllocatedMem, pcmIn,                                 &s_ampInputStream[pingPongAmpIdx * PCM_SINGLE_CH_SMPL_COUNT], &pu8CleanAudioBuff, NULL,                                 NULL);               SLN_AMAZON_WAKE_ProcessWakeWord((int16_t*)pu8CleanAudioBuff, 320);         taskNotification &= ~currentEvent;           // If devices is muted, then skip over state machine         if (s_micMuteMode)         {             if (u8WakeWordActive)             {                 u8WakeWordActive = 0U;             }               memset(pu8CleanAudioBuff, 0x00, AUDIO_QUEUE_ITEM_LEN_BYTES);         }           if (u8WakeWordActive)         {             configPRINTF(("Wake word detected locally\r\n"));         }           // Execute intended state         switch (s_audioProcessingState)         {             case kIdle:                   /* add clean buff to cloud wake word ring buffer */                 continuous_utterance_samples_add(pu8CleanAudioBuff, PCM_SINGLE_CH_SMPL_COUNT * PCM_SAMPLE_SIZE_BYTES);                 if (u8WakeWordActive)                 {                     continuous_utterance_buffer_set(&cloud_buffer, &cloud_buffer_len, wwLen);                       u8WakeWordActive = 0U;                     wwLen = 0;                     // Notify App Task Wake Word Detected                     xTaskNotify(s_appTask, kWakeWordDetected, eSetBits);                       // App Task will now determine if we begin recording/publishing data                 }                   break; ...case kWakeWordDetected:                   audio_processing_reset_mic_capture_buffers();                 // Notify App_Task to indicate recording                 xTaskNotify(s_appTask, kMicRecording, eSetBits);                   if (s_audioProcessingState != kMicRecording)                 {                     s_audioProcessingState = kMicCloudWakeVerifier;                 }                   configPRINTF(("[audio processing] Mic Recording Start.\r\n"));                 // Roll into next state               case kMicCloudWakeVerifier:             case kMicRecording:                   micRecordingLen = AUDIO_QUEUE_ITEM_LEN_BYTES;                 if (u8WakeWordActive)                 {                     u8WakeWordActive = 0U;                 }                   // Push data into buffer for consumption by AIS task                 status = audio_processing_push_mic_data(&pu8CleanAudioBuff, &micRecordingLen); ...} } 

清單 4:在完整的 Alexa 應用程式中,音訊處理任務會使用額外的程式碼來擴大音訊前端應用程式中執行的處理步驟,以管理 Alexa 序列中後續的音訊處理階段。(程式碼來源:NXP)

在偵測到本機 ML 喚醒詞偵測後,完整 Alexa 應用程式的音訊處理任務,會如之前所述通知主應用程式任務。此外,該任務現在還必須管理音訊處理狀態,確保麥克風保持開啟,以擷取完整的音訊輸入,以便在 Alexa 雲端進行語音處理,而不會遺失含有本機偵測之喚醒詞的原始資料流。此完整資料流會傳遞至 Alexa 雲端進行喚醒詞驗證,以及進一步的語音處理。

在此處理序列的每個階段,音訊處理任務都會向主應用程式任務發出相應的 FreeRTOS 通知。與音訊處理任務一樣,完整的 Alexa 應用程式會擴大音訊前端應用程式中以更簡單方式呈現的主應用程式任務模式。在這裡,完整的 Alexa 應用程式的主應用程式任務 appTask,不僅會產生 Alexa 雲端傳輸事件,還會產生依照 Amazon AVS UX Attention System 要求進行套件 LED 管理的事件。例如,在偵測到喚醒詞後保持麥克風開啟時,音訊處理任務會通知主應用程式任務,後者則會設定相應的 UX 注意狀態 (LED 指示燈呈亮青色) (請參見清單 5 中的醒目提醒部分,並再次參見清單 4 中對應的醒目提醒部分)。

複製 void appTask(void *arg) { ...// Create audio processing task     if (xTaskCreate(audio_processing_task, "Audio_proc_task", 1536U, NULL, audio_processing_task_PRIORITY, &xAudioProcessingTaskHandle) != pdPASS) ...// Create pdm to pcm task     if (xTaskCreate(pdm_to_pcm_task, "pdm_to_pcm_task", 512U, NULL, pdm_to_pcm_task_PRIORITY, &xPdmToPcmTaskHandle) != pdPASS) ...while(1)     {           xTaskNotifyWait( ULONG_MAX, ULONG_MAX, &taskNotification, portMAX_DELAY );           if (kIdle & taskNotification)         {             // Set UX attention state             ux_attention_set_state(uxIdle);               taskNotification &= ~kIdle;         }           if (kWakeWordDetected & taskNotification)         {             if (reconnection_task_get_state() == kStartState)             {                 if (!AIS_CheckState(&aisHandle, AIS_TASK_STATE_MICROPHONE))                 {                     // Set UX attention state                     ux_attention_set_state(uxListeningStart); ...// Begin sending speech                     micOpen.wwStart = aisHandle.micStream.audio.audioData.offset + 16000;                     micOpen.wwEnd = aisHandle.micStream.audio.audioData.offset + audio_processing_get_wake_word_end();                     micOpen.initiator = AIS_INITIATOR_WAKEWORD;                     AIS_EventMicrophoneOpened(&aisHandle, &micOpen);                       // We are now recording                     audio_processing_set_state(kWakeWordDetected);                 }             }             else             {                 ux_attention_set_state(uxDisconnected);                 audio_processing_set_state(kReconnect);             }               taskNotification &= ~kWakeWordDetected;         } ...if (kMicRecording & taskNotification)         {             // Set UX attention state and check if mute is active             // so we don't confuse the user             if (audio_processing_get_mic_mute())             {                 ux_attention_set_state(uxMicOntoOff);             }             else             {                 ux_attention_set_state(uxListeningActive);             }               taskNotification &= ~kMicRecording;         } ..。 

清單 5:在完整的 Alexa 應用程式中,主應用程式任務會協調 Alexa 處理順序,包括依照 Alexa 認證要求來控制 LED 指示燈。(程式碼來源:NXP)

同樣地,完整 Alexa 應用程式中的主要常式也會擴大音訊前端應用程式中以更簡單方式展現的模式。在此例中,主應用程式也建立其他 FreeRTOS 任務,以執行更大量的初始化程序,並建立處理套件按鈕和支援 OTA 更新的任務。

以這些範例應用程式為基礎,開發人員可以在自己的 i.MX RT106A 架構設計中,使用 NXP MCU Alexa Voice IoT SDK 放心地實作內建 Alexa 功能。由於此執行平台充分利用 AWS IoT Core 的 AVS,因此開發人員可在日益複雜的 IoT 應用中,將 Alexa 功能解決方案更廣泛地部署在低成本且資源有限的裝置中。

結論

語音助理功能助動了 Echo 智慧型揚聲器的快速成長,而 Amazon Alexa Voice Service 能讓開發人員實作此功能。在過去,產品若想取得夢寐以求的內建 Alexa 認證,需要仰賴具有大容量本機記憶體和高效處理能力的執行平台。NXP 以 AWS IoT Core 的 AVS 為基礎推出一款套件,可利用微控制器和相關的軟體執行環境,提供可達到內建 Alexa 功能的立即可用解決方案。

DigiKey logo

聲明:各作者及/或論壇參與者於本網站所發表之意見、理念和觀點,概不反映 DigiKey 的意見、理念和觀點,亦非 DigiKey 的正式原則。

關於作者

Image of Stephen Evanczuk

Stephen Evanczuk

Stephen Evanczuk 撰寫電子產業的相關資訊已有超過二十年的經驗,涉及的主題多元,涵蓋硬體、軟體、系統以及包含 IoT 在內的應用。他以神經元網路為研究主題,取得神經科學博士學位,並且在航太產業,針對廣泛運用的安全系統和演算法加速方法進行研究。目前,在撰寫科技和工程文章之餘,他投入辨識和推薦系統的深度學習應用。

關於出版者

DigiKey 北美編輯群