Implementere raskt innebygd Alexa-IoT-design ved hjelp av et mikrostyringsbasert sett

Stemmeassistenter har raskt utviklet seg til å bli en viktig funksjon i ethvert smartprodukt. Blant dagens skybaserte løsninger har Amazons Alexa Voice Service (AVS) stått frem som den dominerende stemmeassistenten, med bruksklare egenskaper som drar nytte av Amazons ressurser i skyen til stemmegjenkjenning og prosessering av naturlig språk.

For utviklere har ytelseskravene og konstruksjonskompleksiteten ved AVS imidlertid vist seg som en betydelig hindring for bruk i mindre mikroprosessorbaserte enheter for tilkoblede hjem og tingenes internett (IoT). Et sett fra NXP Semiconductors, som er konstruert som en ferdigløsning og et referansedesign for tilpassede applikasjoner, tilbyr en Amazon AVS-løsning som er beregnet spesifikt for enheter med begrenset ressursplass.

Denne artikkelen viser hvordan utviklere raskt kan implementere konstruksjoner med innebygd Alexa ved å bruke ferdige løsninger fra NXP.

Hva er AVS?

Siden den kom for et tiår siden, har stemmeassistanseteknologi utviklet seg raskt, og leder an i et vekstmarked for smarthøyttalere som markedsanalytikere anslår at allerede omfatter ca. en tredjedel av USAs befolkning. Blant de konkurrerende løsningene har Amazon Echo-smarthøyttalere fått en dominerende andel ved å utnytte suksessen til Amazon Web Services (AWS) og tilby skybaserte ressurser som støtter tredjeparts Echo-apper eller Skills.

Ved å bruke Alexa Skills Kit (ASK) og de tilknyttede programmeringsgrensesnittene (API-ene) kan utviklerne dra nytte av det raskt økende antallet installerte Echo-smarthøyttalere og levere stemmestyring til tilkoblede enheter. Med denne fremgangsmåten kan tilkoblede produkter som smart-TV-er og termostater som «fungerer med Alexa», svare på brukerens stemmeforespørsler og tilknyttede kommandoer som mottas fra Alexa-skyen (figur 1). Dette oppsummerer AVS og skisserer dets potensiale.

Figur 1: Ved å lage Alexa-apper, eller Skills, kan utviklere gjøre det mulig for tilkoblede produkter å samhandle med brukernes stemmekommandoer gjennom Amazon Echo-produkter. (Bildekilde: Amazon Web Services)

Innebygd Alexa-konstruksjon

I motsetning til produkter som «fungerer med Alexa», oppnår smarte produkter merket «Alexa Built-in» et mer sømløst og raskere grensesnitt mellom den stemmeaktiverte Alexa-enheten og AWS-ressursene. Disse produktene integrerer AVS direkte i et tilkoblet enhetskonstruksjon. Ved å bruke AVS kombinert med AWS IoT Core-plattformen kan utviklere implementere avanserte IoT-applikasjoner som lar brukerne benytte stemmekommandoer med Alexa-aktiverte produkter for både å styre tilkoblede enheter og å motta talerespons fra disse enhetene (figur 2).

Figur 2: Alexa-aktiverte enheter gir brukere et stemmegrensesnitt for å styre enheter (øverst) eller motta varsler fra IoT-enheter (nederst) som er koblet til Amazon Web Services-ressurser via AWS IoT Core. (Bildekilde: Amazon Web Services)

Tidligere har imidlertid konstruksjonene for de Alexa-aktiverte enhetene som er sentrale i denne typen IoT-applikasjon, i seg selv krevd en betydelig konstruksjonsinnsats. For å bruke skybaserte Alexa-tjenester måtte enheten kjøre flere AVS-tjenestebiblioteker via AVS-enhetens programvareutviklingssett (SDK) som kjøres på Android- eller Linux-plattformer for å oppdage oppvåkningsordet, kommunisere med Alexa-skyen og behandle kommandoer for egenskaper som støttes (figur 3).

Figur 3: Dette skjemaet illustrerer komponentene i AVS Device SDK og hvordan data sendes mellom dem. (Bildekilde: Amazon Web Services)

For å kjøre disse tjenestebibliotekene måtte Alexa-aktiverte enhetskonstruksjoner vanligvis ha en applikasjonsprosessor med høy ytelse og minst 50 megabyte (Mbyte) minne for å oppfylle AVS sitt prosesseringskrav. I tillegg måtte disse konstruksjonene ofte ha en digital signalprosessor (DSP) for å utføre de komplekse algoritmene som trengs for å trekke ut lyden av stemmen fra støyende omgivelser og støtte fjernfelts stemmeegenskaper som forventes av stemmeassisterte enheter. Til syvende og sist har systemkravene til konstruksjonen av en fungerende Alexa-aktivert enhet vanligvis overskredet kostnadsnivået og påkrevd kompleksitetsnivå for å lage praktiske IoT-enheter.

Med utgivelsen av AVS Integration for AWS IoT Core har Amazon imidlertid drastisk redusert prosessorbelastningen og monteringsflaten for minne som trengs for å implementere innebygde Alexa-produkter. Med denne tjenesten blir behandlings- og minneintensive oppgaver flyttet fra den Alexa-aktiverte enheten til en tilknyttet virtuell enhet i skyen (figur 4).

Figur 4: AVS for AWS IoT Core flytter minne- og prosessorintensive oppgaver til skyen for å muliggjøre implementering av Alexa-stemmeassisterte-egenskaper på ressursbegrensede IoT-enheter. (Bildekilde: Amazon Web Services)

Den fysiske enhetens prosesseringsansvar reduseres til mer grunnleggende tjenester, f.eks. sikker sending av meldinger, pålitelig levering av lyddata til og fra Alexa, oppgavestyring og hendelsesvarsler innenfor enheten selv og med Alexa. Overføring av data, kommandoer og varsler mellom den fysiske enheten og Alexa foregår gjennom effektiv MQTT-meldingssending (MQ Telemetry Transport), med noen få reserverte emner i MQTT publish-subscribe-protokollen. Endelig finnes det en følgemobilapp som samhandler med Alexa-skyen for enhetsregistrering og eventuell annen brukersamhandling med den Alexa-aktiverte enheten.

Ved å flytte den tunge prosesseringen til skyen lar AVS for AWS IoT Core utviklere lage produkter med Innebygde Alexa-plattformer som er mer kjent for utviklere av innebygde systemer. I stedet for applikasjonsprosessorer med 50 megabyte minne som kjøres på Linux eller Android, kan utviklere implementere disse konstruksjonene med mer beskjedne mikrostyringer med under 1 Mbyte RAM som kjører operativsystemer i sanntid (RTOS). Alexa-aktiverte konstruksjoner som er bygd med AVS for AWS IoT Core, kan faktisk oppnå en reduksjon i materialer på 50 % sammenlignet med konstruksjoner som er lagd for å kjøre alle AVS-tjenestene lokalt.

Selv om AVS for AWS IoT Core støtter en mer kostnadseffektiv kjøretidsplattform, er implementeringen av et sertifisert produkt med innebygd Alexa fortsatt en kompleks oppgave. Utviklere som ikke har noen erfaring med to AVS og IoT Core, kan oppleve en betydelig læringskurve når de skal jobbe seg gjennom AWS sine krav til sikkerhet, kommunikasjon, kontostyring, utforming av brukeropplevelsen (UX) med mer. Uavhengig av hvor kjent de er med AWS-økosystemet, må alle Alexa-produktutviklere sørge for at konstruksjonene deres oppfyller en rekke spesifikasjoner og krav for å oppnå Amazon Alexa-sertifisering.

NXPs mikrostyringsbaserte løsning for Alexa gir en bruksklar systemløsning som fullt ut implementerer kravene til maskinvaren og programvaren på enhetssiden for Amazon AVS for AWS IoT Core.

Mikrostyringsbasert Alexa-løsning

Siden den er bygd rundt NXP i.MX RT106A-mikrostyringen, leverer NXP SLN-ALEXA-IOT AVS-settet bruksklar AWS-tilkobling, AVS-kvalifisert fjernfeltlydalgoritmer, ekkokansellering, mulighet for Alexa-oppvåkningsord og applikasjonskode. Settets i.MX RT106A-mikrostyring er basert på en Arm Cortex-M7-kjerne og er medlem av i NXPs i.MX RT106x-familie av crossover-prosessorer som er beregnet spesielt for IoT edge computing. RT106A er bygd for innebygde stemmeapplikasjoner og tilfører spesialfunksjonalitet til NXP i.MX RT1060-crossover-prosessorfamiliens grunnsett av eksterne grensesnitt, omfattende internminne og bred støtte for eksterne minnealternativer (figur 5).

Figur 5: NXP i.MX RT1060-crossover-prosessorfamilien integrerer en Arm Cortex-M7-mikrostyringskjerne med et komplett sett av eksterne grensesnitt, minne og andre egenskaper som vanligvis kreves i en IoT-enhet. (Bildekilde: NXP)

Med sin integrerte funksjonalitet trenger i.MX RT106A-mikrostyringen bare noen få ekstra komponenter for å tilby maskinvaregrunnlaget som trengs for å implementere AVS for AWS IoT Core. I SLN-ALEXA-IOT-settet integreres NXP i.MX RT106A-mikrostyringen i en systemmodul med 256 megabits (Mb) flashminne, Murata Electronics’ LBEE5KL1DX Wi-Fi/Bluetooth-transceivermodul og Diodes’ AP2202K-3.3TRG1-nedtransformeringsomformere (figur 6).

Figur 6: Konstruksjonen til NXP SLN-ALEXA-IOT AVS-settets systemmodul drar nytte av det enkle maskinvaregrensesnittet som trengs for å integrere NXP i.MX RT106A-mikrostyringen med ekstern flash og en trådløs transceiver. (Bildekilde: NXP)

Som et tillegg til denne systemmodulen tilbyr et stemmekort i SLN-ALEXA-IOT-settet tre Knowles SPH0641LM4H-1 pulstetthetsmodulasjon (PDM) MEMS-mikrofoner, en PUI Audio AS01808AO-høyttaler og en NXP TFA9894D klasse-D audioforsterker. Sammen med en USB type C-kontakt for å gi strøm til settet og kjøre en skallkonsoll fra en datamaskin, tilbyr stemmekortet hoder til Ethernet, serielt periferiutstyr og i.MX RT106A-mikrostyringens inngang/utgang til generell bruk (GPIO). Endelig omfatter kortet brytere for grunnleggende kontrollsignaler i tillegg til lysdioder for visuelle meldinger som er i samsvar med Amazon AVS UX Attention System-kravene, med forskjellige farger på lysdiodene og på/av-sirkuleringsmønstre.

Med systemmodulen og stemmekortet tilbyr SLN-ALEXA-IOT-maskinvaren en komplett plattform til enhetsbasert prosessering av AVS for AWS IoT Core-programvaren. Men, som nevnt tidligere, er Alexa-aktiverte IoT-enhetskonstruksjoner like avhengig av optimalisert programvare som maskinvare. Det å utvikle denne programvaren fra bunnen av med Amazons AVS for AWS IoT-API, kan forsinke prosjekter betydelig, siden utviklerne jobber seg gjennom prosessen med å bygge de påkrevde dataobjektene og å implementere de tilknyttede protokollene. Ytterligere forsinkelser kan dukke opp når utviklerne, som jobber mot en sertifisering for innebygd Alexa prøver å etterkomme kravene til AVS UX Attention System, AWS-sikkerhetsmetodene og andre krav som berører hvert aspekt av brukernes samhandling med Alexa-tjenestene i konstruksjonen. NXP imøtekommer disse bekymringene med sitt omfattende kjøretidsmiljø for stemmestyringsprogramvare som er basert på Amazon FreeRTOS, bygd på et lag av programvaredrivere for execute-in-place (XIP) flash, tilkoblingsmuligheter og andre maskinvarekomponenter (figur 7).

Figur 7: Med bakgrunn i Amazon FreeRTOS tilbyr NXPs systemmiljø for stemmestyring et omfattende sett av mellomvaretjenester, blant annet firmwarerutiner for maskinlæring av inferens og audio front-end-prosessering. (Bildekilde: NXP)

Under dette programvaremiljøets egenskaper for stemmeprosessering tilbyr NXPs Intelligent Toolbox-firmware optimaliserte funksjoner for alle lydoppgaver, blant annet den maskinlærende (ML) inferensmotoren og ML audio front-end for forsterkning og optimalisering av lydsignaler. Andre mellomvaretjenester støtter sikker tilkobling, AWS-kommunikasjon og lydegenskaper. Over dette omfattende tjenestelaget håndterer programvare for AWS IoT Core, onboarding og andre applikasjonsstyringsegenskaper oppstarten fra en totrinns bootloader med støtte for trådløse (OTA) oppdateringer som er bygd på AWS IoT OTA-tjenesten og Amazon FreeRTOS OTA-klienten.

Ved å benytte den fabrikkinstallerte programvaren som kjøres i dette miljøet, kan utviklere umiddelbart få opp SLN-ALEXA-IOT-maskinvaresettet med en fullstendig Alexa-aktivert applikasjon som er konstruert for å bruke en NXP-demonstrasjonskonto for AWS IoT. NXP-dokumentasjonen gir en detaljert gjennomgang av fremgangsmåten for å få opp settet, klargjøre Wi-Fi-legitimasjon og fullføre autentiseringen av AWS-enheten med demonstrasjonskontoen. Som en del av denne prosessen samhandler utviklerne med settet og AWS med en Android-mobilapp som følger med programvaredistribusjonspakken, som er tilgjengelig fra NXP-nettstedet ved å benytte en aktiveringskode som leveres med hvert SLN-ALEXA-IOT-sett. Etter noen enkle trinn kan utviklerne umiddelbart begynne å bruke settet gjennom den samme typen Alexa-stemmesamhandling som i Echo-smarthøyttalere.

For raskt å lage produktprototyper med Alexa-egenskaper leverer SLN-ALEXA-IOT-settet og den fabrikkinstallerte programvaren en klargjort plattform. Samtidig fungerer settets maskinvare og programvare som en rask utviklingsplattform for å lage tilpassede, Alexa-aktiverte konstruksjoner som er basert på i.MX RT106A-mikrostyringen.

Egendefinert utvikling

Programvaren for i.MX RT106A-baserte Alexa-løsninger drar nytte av egenskapene i NXPs kjøretidsmiljø for stemmestyring gjennom NXP MCU Alexa Voice IoT SDK, som tilbys som en del av programvaredistribusjonspakken som er tilgjengelig ved aktivering av produktet. Denne SDK-en, som er utformet som et tillegg til NXPs Eclipse-baserte MCUXpresso integrerte utviklingsmiljø (IDE), kombinerer full kildekode til eksempelapplikasjoner, drivere og mellomvare med hoder for binære distribusjoner av spesialiserte firmwareegenskaper så som NXP Intelligent Toolbox, ML inferensmotor og ML audio front-end.

Utviklere som raskt må distribuere et Alexa-aktivert produkt, kan i prinsippet bruke den komplette Alexa-demonstrasjonsapplikasjonen med små endringer. I de enkleste tilfellene vil disse endringene ganske enkelt endre applikasjonens mål til utviklerens egen AWS-konto med sin egen sikkerhetslegitimasjon. NXP tilbyr en trinnvis beskrivelse for å gjennomføre denne prosessen.

For egendefinert utvikling tilbyr eksempelapplikasjonene som følger med programvaredistribusjonen, utførbare eksempler som viser hvordan man jobber med NXP MCU Alexa Voice IoT-SDK-en. I stedet for å gå rett inn i den fullstendige Alexa-demonstrasjonsapplikasjonen, kan utviklerne utforske eksempelapplikasjoner som lar dem fokusere mer på bestemte egenskaper, blant annet audio front-end, Wi-Fi- og Bluetooth-tilkobling, bootloading og annet. For eksempel viser eksempelapplikasjonen for audio front-end de grunnleggende konstruksjonsmønstrene for å gjennomføre en oppdagelse av oppvåkningsord ved hjelp av Amazon FreeRTOS-oppgaver.

I eksempelapplikasjonen for audio front-end demonstrerer hovedrutinen hvordan utviklere kan initialisere maskinvare- og programvareundersystemene og deretter bruke FreeRTOS xTaskCreate-funksjonen til å starte oppgaven i hovedapplikasjonen (appTask) og en konsollskalloppgave (sln_shell_task) før styringen gis til FreeRTOS-planleggeren (programmeringskode 1). (Merk: vTaskStartScheduler-kallet for å starte FreeRTOS-planleggeren returnerer bare hvis planleggeren ikke har nok minne.)

Copy
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();
.
.
.
}

Programmeringskode 1: Et eksempel på en audio front-end-applikasjon som følger med i NXP MCU Alexa Voice IoT SDK-distribusjonen, som demonstrerer grunnleggende initialiseringskrav og opprettelse av FreeRTOS-oppgaver for hovedapplikasjonsoppgaven og en konsollskalloppgave. (Kodekilde: NXP)

Etter initialisering av audio-undersystemet, starter hovedapplikasjonsoppgaven appTask deretter et par FreeRTOS-oppgaver. Den ene oppgaven kjører en tjenesterutine, audio_processing_task, som behandler lydinnmatingen, mens den andre oppgaven håndterer konvertering av mikrofon-PDM-utgangen til pulskodemodulasjon (PCM). Etter ytterligere opprydding går appTask over til en evig sløyfe mens den venter på et RTOS-varsel som betyr at oppvåkningsordet ble oppdaget (programmeringskode 2).

Copy
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;
    }
}

Programmeringskode 2: I eksempelapplikasjonen for audio front-end starter hovedapplikasjonsoppgaven, appTask, oppgaver for å håndtere lydbehandling og mikrofondatakonvertering, og venter deretter på et FreeRTOS-varsel (taskNotification) om at oppvåkningsordet er oppdaget (kWakeWordDetected). (Kodekilde: NXP)

Deretter initialiserer lydbehandlingsoppgaven i denne eksempelapplikasjonen firmwarefunksjonen for oppvåkningsordet og initialiserer deteksjonsparametre for oppvåkningsordet, før den deretter går inn i en uendelig sløyfe der den venter på et FreeRTOS-varsel fra oppgaven for mikrofondatakonvertering om at behandlede mikrofondata er tilgjengelige. På dette trinnet kaller lydbehandlingsoppgaven opp Intelligent Toolbox-firmwarefunksjonene som behandler lyddataene og utfører oppvåkningsorddeteksjon ved hjelp av ML-inferensmotoren (programmeringskode 3).

Copy
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);
        }
    }
}

Programmeringskode 3: I eksempelapplikasjonen for audio front-end initialiserer lydbehandlingsoppgaven oppvåkningsordmotoren i firmwaren, venter på et FreeRTOS-varsel om at mikrofondata er tilgjengelige og kaller til slutt opp NXP Intelligent Toolbox-firmwarens analoge front-end (SLN_Voice_Process_Audio) og ML-inferensmotoren (SLN_AMAZON_WAKE_ProcessWakeWord) for deteksjon av oppvåkningsordet. (Kodekilde: NXP)

Etter at oppvåkningsordet er oppdaget, sender lydbehandlingsoppgaven et FreeRTOS-oppgavevarsel for å varsle hovedapplikasjonsoppgaven, appTask, om denne hendelsen. Ved mottak av dette varselet, blinker appTask midlertidig blått med lysdioden (se programmeringskode 2 igjen).

Den fullstendige Alexa-eksempelapplikasjonen bruker de samme mønstrene som er beskrevet for de enklere applikasjonen for audio front-end, men utvider denne grunnkoden betydelig for å støtte full Alexa-funksjonalitet. For eksempel: Etter at ML-inferensmotoren oppdager oppvåkningsordet i Alexa-eksempelapplikasjonen, utfører lydbehandlingsoppgaven en serie FreeRTOS-varsler som er knyttet til hvert trinn i Alexa-prosesseringssekvensen (programmeringskode 4).

Copy
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);
.
.
.
    }
}

Programmeringskode 4: I den fullstendige Alexa-applikasjonen utvider lydbehandlingsoppgaven prosesseringstrinnene som utføres i applikasjonen for audio front-end med mer kode for å håndtere de påfølgende lydbehandlingstrinnene i Alexa-sekvensen. (Kodekilde: NXP)

Etter lokal ML-oppvåkningsorddeteksjon, varsler den fullstendige Alexa-applikasjonens lydbehandlingsoppgave hovedapplikasjonsoppgaven, som beskrevet tidligere. I tillegg må den nå håndtere lydbehandlingstilstander der mikrofonen forblir åpen for å fange opp hele lydinnmatingen for taleprosessering i Alexa-skyen uten å miste den opprinnelige datastrømmen som inneholder det lokalt oppdagede oppvåkningsordet. Hele datastrømmen sendes til Alexa-skyen for å verifisere oppvåkningsordet i tillegg til ytterligere taleprosessering.

Ved hvert trinn i denne prosesseringssekvensen sender lydbehandlingsoppgaven ut tilsvarende FreeRTOS-varsler til hovedapplikasjonsoppgaven. Som med lydbehandlingsoppgaven, utvider den fullstendige Alexa-applikasjonen hovedapplikasjonens oppgavemønster som presenteres i enklere form i applikasjonen for audio front-end. Her genererer den fullstendige Alexa-applikasjonens hovedapplikasjonsoppgave, appTask, både hendelser for overføring til Alexa-skyen og for håndtering i settets lysdioder i henhold til kravene i Amazon AVS UX Attention System. For eksempel: Når mikrofonen holdes åpen etter oppdagelse av oppvåkningsordet, varsler lydbehandlingsoppgaven hovedapplikasjonsoppgaven, som stiller inn egnet UX-oppmerksomhetstilstand (fast turkis lysdiodeindikator) (se de gule uthevingene i programmeringskode 5 og tilsvarende utheving i programmeringskode 4).

Copy
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;
        }
.
.
.

Programmeringskode 5: I den fullstendige Alexa-applikasjonen styrer hovedapplikasjonsoppgaven Alexa-prosesseringssekvensen, som styrer lysdiodene i henhold til kravene for Alexa-sertifisering. (Kodekilde: NXP)

Hovedrutinen i den komplette Alexa-applikasjonen utvider på samme måte mønsteret som vises i enklere form i applikasjonen for audio front-end. I dette tilfellet lager hovedapplikasjonen også ekstra FreeRTOS-oppgaver for en mer solid initialiseringsprosedyre, i tillegg til oppgaver for å håndtere settets knapper og for å støtte OTA-oppdateringer.

Ved å bygge videre på disse eksempelapplikasjonene kan utviklere trygt implementere innebygd Alexa-funksjonalitet ved hjelp av NXP MCU Alexa Voice IoT SDK i sine egne i.MX RT106A-baserte konstruksjoner. Siden den drar full nytte av AVS for AWS IoT Core, gjør denne eksekveringsplattformen utviklere i stand til å distribuere Alexa-aktiverte løsninger bredere i lavprisenheter med begrensede ressurser, som grunnlag i stadig mer avanserte IoT-applikasjoner.

Konklusjon

Amazon Alexa Voice Service har gjort utviklere i stand til å implementere den samme stemmeassistentfunksjonaliteten som ligger til grunn for den hurtige veksten av Echo-smarthøyttalere. Tidligere krevde produkter som kunne oppnå den ettertraktede innebygd Alexa-sertifiseringen, eksekveringsplattformer med omfattende lokalt minne og prosesseringskraft med høy ytelse. Et sett fra NXP, bygd med AVS for AWS IoT Core, tilbyr en ferdiglløsning for innebygd Alexa-funksjonalitet ved hjelp av en mikrostyring og et tilknyttet programvareeksekveringsmiljø.