Legg til kontinuerlig Wi-Fi-tilkobling uten det går utover batterilevetiden

Wi-Fi tilbyr høy båndbredde og allestedsnærværende, og er fortsatt et primært tilkoblingskrav for mange IoT-enheter (tingenes internett). Men for kroppsbårne enheter (wearables) og andre batteridrevne IoT-enheter har strømkravene til konvensjonelle Wi-Fi-løsninger gjort kontinuerlig Wi-Fi-tilkobling upraktisk, noe som vanligvis krever at utviklere kompromitterer noen aspekter av enhetens funksjonalitet, ytelse eller batterilevetid.

Selv om utforming av en tilpasset Wi-Fi-løsning for å optimalisere for lav effekt kan være et alternativ for noen team, kan dette være et dyrt og tidskrevende foretak, spesielt med tanke på mangelen på kvalifiserte RF-designere. Det kreves en mer komplett løsning som også gjør kontinuerlig Wi-Fi praktisk for IoT-enheter med lav effekt.

Denne artikkelen viser hvordan utviklere kan implementere kontinuerlig Wi-Fi-tilkobling ved hjelp av funksjoner med lav effekt innebygd i en trådløs system-på-brikke-enhet (system-on-chip – SoC) fra Dialog Semiconductor.

Utfordringene med å støtte Wi-Fi-tilkobling for mobile enheter

Wi-Fi gir vanligvis kombinasjonen av allment utbredte karakterestikker for tilstedeværelse og ytelses som kreves i et bredt spekter av IoT-applikasjoner som er bygget opp rundt systemer for personlige mobilprodukter, smarte hjemmeenheter og byggautomatisering, bare for å nevne noen få. Tidligere tvang imidlertid det relativt høye strømforbruket av Wi-Fi-delsystemer utviklere til gå ned på batterilevetiden eller signalstyrken i batteridrevne IoT-enheter.

De høye strømkravene til tradisjonelle Wi-Fi-løsninger gir IoT-utviklere ytterligere utfordringer. For eksempel kan krav til både Wi-Fi-tilkobling og forlenget batterilevetid legge til designstørrelse og kompleksitet for å imøtekomme større batterier. For bærbare enheter eller mange IoT-enheter der større batterier kanskje ikke er et alternativ, er forsøk på å forlenge batterilevetiden ved å redusere Wi-Fi-signalstyrke (og tilhørende strømforbruk) kanskje ikke mulig.

I tillegg til disse bekymringene, står IoT-utviklere overfor praktiske begrensninger i det typiske Wi-Fi-signalmiljøet der signalstyrken kan variere betydelig på grunn av flerbaneinterferens og andre radiofrekvenssignalegenskaper (RF). I programmer som bærbare datamaskiner kan en forbruker ganske enkelt flytte en bærbar datamaskin til et annet sted med et bedre Wi-Fi-signal. Derimot trenger en smart lås eller et husholdningsapparat å opprettholde pålitelig tilkobling og robust ytelse, uavhengig av hvor den er installert.

For å støtte både forlenget batterilevetid og robust Wi-Fi-signalstyrke, utnytter utviklere vanligvis dvalemoduser med lav effekt som er tilgjengelige i de fleste avanserte prosessorer, radioer og andre komplekse maskinvarekomponenter. Ved å maksimere mengden tid strømhungrige enheter bruker i sine respektive laveffektmodus, kan utviklere implementere design som forlenger batterilevetiden til deres systemdesign, vanligvis med liten innvirkning på systemfunksjonaliteten. I disse utformingene kan en tidtaker med lav effekt periodisk vekke systemet kort for å lese sensorer, så trådløst overføre sensordata før du går tilbake til dvalemodus.

For noen IoT-applikasjoner må IoT-enheten imidlertid opprettholde en kontinuerlig tilkobling til Wi-Fi-nettverket for å sikre rask respons på brukerkommandoer utstedt via mobilapper, PC-programvare eller til og med andre enheter. Smartlåser, lys og brytere som finnes i smarte hjem, må for eksempel forbli koblet til for å gi øyeblikkelig respons på brukerkommandoer. Å vente på at en tidsbasert enhet til slutt skal våkne, detektere kommandoen og til slutt låse opp en dør eller slå på et lys, ville rett og slett være uakseptabelt for brukerne.

Dialog Semiconductor sin SoCDA16200 og tilhørende moduler gir en laveffektsløsning med høy virkningsgrad som kan støtte krav til både kontinuerlig Wi-Fi-tilkobling og utvidet batterilevetid.

Implementere Wi-Fi-tilkobling med en trådløs SoC

Designet spesielt for batteridrevne IoT-design, kombinerer SoC-en DA16200 en Arm® Cortex®-M4F med et komplett Wi-Fi-radioundersystem som kjører en full nettverksstakk, noe som eliminerer behovet for en ekstern nettverksprosessor eller en vertsprosessor for å gi stabelfunksjonalitet. Sammen med radiodelsystemet integrerer enheten et komplett sett med funksjonelle blokker og grensesnitt som vanligvis kreves i IoT-utformingen (figur 1).

Figur 1: Dialog Semiconductor sin SoC DA16200 gir en komplett Wi-Fi-løsning som kan levere kontinuerlig Wi-Fi-tilkobling mens den bruker minimalt med strøm. (Bildekilde: Dialog Semiconductor)

Sammen med flere standardgrensesnitt inkluderer enheten et 4-kanals, 12-bits suksessivt approksimasjonsregister (SAR) analog til digital-omformer (ADC) for å støtte analog signalinnsamling.

For programutførelse inneholder DA16200 flere interne minner, inkludert:

• skrivebeskyttet minne for en oppstartslaster, systemkjerne, nettverksstakk og drivere.
• statisk tilfeldig tilgangsminne (SRAM) for programdata. programkode kjører på plass (executes in place – XIP) på serielt flashminne som er tilgjengelig gjennom enhetens eksterne serielle flashminnegrensesnitt.
• engangsprogrammerbart minne (OTP) som brukes til å lagre enhetsinformasjon så vel som kryptografiske nøkler og en sikker oppstartslaster. OTP-data forblir sikre fordi de bare kan nås gjennom OTP-styringsenheten og ellers forblir usynlige for normal datatilgang gjennom systembussen.

For å hjelpe utviklere med å møte den økende etterspørselen etter sikkerhet for tilkoblede enheter, integrerer SoC-en DA16200 et bredt sett med sikkerhetsmekanismer, inkludert en kryptografimotor for Advanced Encryption Standard (AES), Secure Hash Algorithms (SHA) og andre krypteringsmekanismer samt støtte for protokollen Transport Layer Security (TLS). Enheten inkluderer også Arm TrustZone CryptoCell-312 (CC312) som er sikret for immaterielle rettigheter. CC312 er utviklet for laveffektenheter, støtter sikker oppstart og muliggjør en RoT (root of trust) for sikre programmer.

Enheten forenkler Wi-Fi-tilkoblingen takket være en omfattende RF-blokk. Sammen med innebygde 802.11 kontrolladresse for nettverkstilgang (media access control – MAC) og 802.11b/g/n PHY-lag (physical layers), inkluderer radiodelsystemet med en integrert transceiver med integrerte effektforsterkere (PA-er) og lavstøyforsterkere (low-noise amplifier – LNA) som eliminerer behovet for eksterne aktive komponenter. Under drift eksekverer DA16200 sin Arm Cortex-M4F-prosessor en innebygd TCP/IP-stakk) for å avlasting av tilkoblingsoperasjoner fra et systems vertsprosessor.

For å drive sine forskjellige blokker, inkludert RF-blokken, integrerer SoC-en DA16200 en DC–DC-omformer, regulatorer med lav fallspenning (LDO) og strømbrytere. Administrert av enhetens sanntidsklokkeblokk (RTC block) genererer omformeren og LDO-ene alle nødvendige forsyningsskinner fra en enkelt VBAT-batteriforsyning. Mens DC–DC-omformeren genererer 1,4 volt for RF-blokken og digital LDO fra VBAT, genererer I/O-LDO 1,8 volt som kreves for eksternt flashminne og enhetens generelle I/O-funksjon (GPIO) (figur 2).

Figur 2: SoC-en DA16200 sin strømstyringsenhet styrer enhetens integrerte strømkomponenter som leverer spenning til dens separate strømdomener. (Bildekilde: Dialog Semiconductor)

SoC-en DA16200 sin strømstyringsenhet styrer forsyningen til disse separate strømdomenene som en del av dens funksjon for å administrere enhetens tre laveffektmoduser (dvalemoduser):

• Dvale 1 tilbyr den laveste effektoperasjonen ved 0,2 mikroampere (μA): I denne modusen er enheten i stor grad slått av, men våkner innen 150 millisekunder (ms) som respons på en ekstern utløser levert til SoC sine to vekkepinner eller til en av flere digitale I/O-er, eller når et analogt inngangssignal overskrider en forhåndsdefinert terskel.
• Sleep 2 forbruker bare 1,8 μA mens RTC-funksjonaliteten beholdes: I denne modusen våkner SoC-en på mindre enn 100 ms som respons på eksterne oppvåkningshendelser eller ved fullføring av en programmert intern timer.
• Sleep 3 gir en unik kontinuerlig tilkoblet Wi-Fi-modus som kan forbruke minimal strøm og våkner på mindre enn 2 ms ved oppdagelse av innkommende Wi-Fi-datapakker: Som beskrevet nedenfor, bruk av Sleep 3 med konvensjonell TCP-keepalive-funksjonalitet gir grunnlaget for å implementere en kontinuerlig Wi-Fi-tilkoblingskapasitet som forbruker mindre enn 50 μA gjennomsnittlig strøm.

Dynamisk strømstyringsteknologi muliggjør kontinuerlig Wi-Fi-tilkobling

Bak disse dvalemodusene med lav effekt ligger Dialog Semiconductors proprietære Dynamic Power Management (DPM)-teknologi som slår av ubrukte mikroelementer integrerte på brikken, noe som resulterer i minimalt strømforbruk når enheten ikke sender eller mottar data. Under Wi-Fi-operasjoner minimerer DPM-en strømforbruket under sende- og mottaksradiooperasjoner ved hjelp av avanserte algoritmer for å vekke nødvendige mikroelementer akkurat når de trengs.

Dialog Semiconductors programvareutviklingssett DA16200 (SDK) betrakter separat detaljene om strømstyring og DPM-drift med DPM Manager-grensesnittet for API-programmering (application programming interface). SDK gir tilgang til DA16200-programvarestakken med applikasjons- og systemtjenester for utvikling av tilpasset programvare (figur 3).

Figur 3: SoC-en DA16200 sin programvarearkitektur gir et komplett sett med system- og applikasjonstjenester som kreves for å støtte standard Wi-Fi-tilkobling i IoT-enheter. (Bildekilde: Dialog Semiconductor)

Implementering av kontinuerlig Wi-Fi-tilkobling kombinerer bruk av DPM Manager og NetX Duo TCP/IP-biblioteket. NetX Duo-biblioteket har en TCP-keepalive-funksjon som sender en TCP-pakke uten data til en Wi-Fi-ruter, som sikrer at ruteren holder Wi-Fi-tilkoblingen aktiv. Utviklere starter denne funksjonen bare ved å sette gjeldende TCP-sokkelalternativ, keepalive_enabled, til true, og oppgi antall sekunder, keepalive_timeout, mellom keepalive pakker. NetX Duo overfører automatisk keepalive-rammene etter behov.

Mens keepalive-pakker opprettholder nettverkstilkoblingen med en ruter eller en annen vert, er DA16200 sin evne til å våkne fra dvalemodus 3 avhengig av deteksjon av standard Traffic Indication Map (TIM) eller DTIM (Delivery Traffic Indication Map) informasjonselementer innebygd i 802.11-styringsrammer, og brukes til å varsle nettverksstasjoner, for eksempel et DA16200-basert system, om at nettverkstrafikk er tilgjengelig for det. Når DA16200 er plassert i dvalemodus 3, sikrer DA16200 sin DPM-teknologi at radioundersystemet bruker minimal strøm på jakt etter TIM/DTIM-elementer. Når DA16200-radiodelsystemet oppdager TIM/DTIM-elementer, vekker det SoC-en for å begynne å behandle normal Wi-Fi-trafikk, som enhver nettverksstasjon.

Ved hjelp av DA16200 sin DPM Manager-API trenger utviklere bare å foreta noen få intuitive anrop for å implementere denne funksjonaliteten. Etter å ha definert den nødvendige DPM-konfigurasjonen, inkludert parametere og tilbakekall, bruker utviklere DPM Manager API-funksjonsanrop til å starte og på annen måte samhandle med DPM Manager. Inn- og utgang fra Sleep 3 håndteres åpent av DA16200-en sin DPM-teknologi.

Eksempel på applikasjoner som er inkludert i SDK, viser de grunnleggende designmønstrene som er nødvendige for å implementere denne rekkefølgen av operasjoner (oppføring 1).

Kopi
#define TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT            55
[lines deleted]
void tcp_client_ka_dpm_sample_wakeup_callback()
{
    PRINTF(GREEN_COLOR " [%s] DPM Wakeup\n" CLEAR_COLOR, __func__);
 
    dpm_mng_job_done(); //Done operation
}
[lines deleted]
void tcp_client_ka_dpm_sample_recv_callback(void *sock, UCHAR *rx_buf, UINT rx_len,
                                            ULONG rx_ip, ULONG rx_port)
{
    int status = NX_SUCCESS;
 
    //Display received packet
    PRINTF(" =====> Received Packet(%ld) \n", rx_len);
 
    tcp_client_ka_dpm_sample_hex_dump("Received Packet", rx_buf, rx_len);
[lines deleted]
    dpm_mng_job_done(); //Done operation
}
[lines deleted]
void tcp_client_ka_dpm_sample_init_user_config(dpm_user_config_t *user_config)
{
[lines deleted]
    //Set DPM wakeup init callback
    user_config->wakeupInitCallback = tcp_client_ka_dpm_sample_wakeup_callback;
[lines deleted]
    //Set Recv callback
    user_config->sessionConfig[session_idx].session_recvCallback =
        tcp_client_ka_dpm_sample_recv_callback;
[lines deleted]
    //Set KeepAlive timeout
    user_config->sessionConfig[session_idx].session_ka_interval =
        TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT;
[lines deleted]
}
[lines deleted]
void tcp_client_ka_dpm_sample(ULONG arg)
{
[lines deleted]
    //Register user configuration
    dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config);
 
    //Start TCP Client Sample
    dpm_mng_start();
 
    return ;
}

Listing 1: Ved bruk av SoC-en DA16200 kan utviklere implementere kontinuerlig Wi-Fi-tilkobling ved hjelp av konfigurasjoner og noen få DPM API-funksjonsanrop. (Kodekilde: Dialog Semiconductor)

Som vist i Liste 1, implementerer utviklere denne evnen i stor grad ved hjelp av bare en initialiseringsfunksjon (tcp_client_ka_dpm_sample_init_user_config () som angir ulike konfigurasjonsparametre, inkludert keepalive-intervall (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT), og gir ulike tilbakekall, inkludert de for DMP oppvåkning (tcp_client_ka_dpm_sample_wakeup_callback ()) og for behandling av innkommende datapakker (tcp_client_ka_dpm_sample_recv_callback ()). For å begynne TCP-keepalive og DPM-oppvåkningssekvens, en separat funksjon (tcp_client_ka_dpm_sample()) bare starter en konfigurasjonsrutine (dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config)) og DMP Manager (dpm_mng_start()).

Som nevnt tidligere, resulterer hele denne sekvensen, inkludert standard TCP-keepalive-pakker og DPM-aktivert Wi-Fi-overvåking av DA16200, i en kontinuerlig Wi-Fi-tilkoblingsevne som vanligvis bruker mindre enn 50 μA gjennomsnittsstrøm.

Dette samme designmønsteret kan brukes til å vekke SoC-ena dvalemodusene for å håndtere andre operasjoner. Et eksempelprogram viser for eksempel bruk av DA16200-ens RTC for å vekke SoC-en for å behandle data (oppføring 2).

Kopi
#define    SAMPLE_FOR_DPM_SLEEP_3        // Sleep Mode 3
 
#define    MICROSEC_FOR_ONE_SEC        1000000
#define    RTC_TIMER_WAKEUP_ONCE        5    // seconds
#define    RTC_TIMER_WAKEUP_PERIOD        10    // seconds
static void rtc_timer_dpm_once_cb(char *timer_name)
{
[lines deleted]
static void rtc_timer_dpm_periodic_cb(char *timer_name)
{
    /*
     *Caution : Don't spend a lot of time in the calback function called by timer.
     */
    dpm_app_sleep_ready_clear(SAMPLE_RTC_TIMER);
 
    PRINTF("\nWakeup due to Periodic RTC timer!!!\n");
    tx_thread_sleep(10);
 
    dpm_app_sleep_ready_set(SAMPLE_RTC_TIMER);
}
[lines deleted]
void rtc_timer_sample(ULONG arg)
{
[lines deleted]
        /* Periodic timer */
        status = dpm_timer_create(SAMPLE_RTC_TIMER,
                                  "timer2",
                                  rtc_timer_dpm_periodic_cb,
                                  RTC_TIMER_WAKEUP_PERIOD,
                                  RTC_TIMER_WAKEUP_PERIOD);
[lines deleted]
        dpm_app_sleep_ready_set(SAMPLE_RTC_TIMER);
[lines deleted]
    }
 
    while (1)
    {
        /* Nothing to do... */
        tx_thread_sleep(100);
    }
}

Listing 2: Utviklere kan implementere timerbasert funksjonalitet med lav effekt med DA16200 ved hjelp av noen få DPM-ens API-funksjonkall for å sikre minimalt strømforbruk i dvaleperioder med DA16200. (Kodekilde: Dialog Semiconductor)

Som vist i Liste 2, kaller utvikleren en DPM Managers API-funksjon (dpm_timer_create ()) for å opprette en timer (SAMPLE_RTC_TIMER) og en annen DPM Manager API-funksjon (dpm_app_sleep_ready_set ()) for å indikere at systemet er klar til å gå tilbake i dvale. DPM-motoren vil deretter bestemme hvor raskt systemet kan gå tilbake til dvalemodus med lav effekt basert på gjeldende aktivitet. Senere, når timeren går ut, utfører systemet utviklerens tilbakekallingsfunksjon, rtc_timer_dpm_periodic_cb (), som utfører de nødvendige operasjonene - i dette tilfellet skriver du bare ut et varsel til konsollen. Når operasjonen er fullført, utfører den samme tilbakekallingsfunksjonen dpm_app_sleep_ready_set () for å varsle DPM-motoren om at systemet er klar til å gå tilbake i dvale. Som tidligere fullfører DPM-motoren overgangen til dvalemodus når det er aktuelt.

Ferdige (drop-in) moduler forenkler Wi-Fi-design

Mens DA16200-ens SDK forenkler programvaredesign, oversettes enhetens omfattende funksjonalitet på brikken til en relativt enkel maskinvaregrensesnittdesign. Bruke SoC-en DA16200 sammen med en ekstern flash-enhet, for eksempelWinbond Electronics 'W25Q16JVSNIQ 16 megabit (Mbit) NOR-minne-IC og bare noen få tilleggskomponenter, kan utviklere implementere en Wi-Fi-aktivert, sikker IoT-design (figur 4).

Figur 4: Med sin omfattende integrerte funksjonalitet krever Dialog Semiconductor SoC-en DA16200 bare et eksternt, serielt flashminne og minimalt med tilleggskomponenter for å implementere et komplett Wi-Fi-system. (Bildekilde: Dialog Semiconductor)

Utviklere som ønsker å fremskynde utviklingen av sine egne design basert på SoC-en DA16200, kan benytte seg av til Dialog Semiconductor-moduler som eliminerer behovet for at de implementerer SoCs maskinvaregrensesnitt. Sammen med SoC-en DA16200 inkluderer modulene 4 megabyte (Mbyte) flashminne, RF-komponenter og valg av en integrert antenne på brikken (DA16200MOD-AAC4WA32) eller u.FL-kontakt for en ekstern antenne (DA16200MOD-AAE4WA32). Fullstendig sertifisert av FCC, IC, CE og andre reguleringsorganer, gir 13,8 x 22,1 x 3,3 mm modulene en ferdig maskinvareløsning for implementering av kontinuerlig Wi-Fi-tilkobling med lav effekt.

Utviklere som ønsker å utforske kontinuerlig Wi-Fi-tilkobling og raskt prototype IoT-design basert på SoC-en DA16200, kan benytte av Dialog Semiconductor umiddelbart.DA16200MOD-DEVKT-utviklingssett. Dette settet kombinerer en DA16200MOD-modul med et USB-grensesnitt, nøkler og tilkoblinger for å fremskynde utvikling og feilsøking av DA16200-baserte konstruksjoner.

Konklusjon

Evnen til å opprettholde kontinuerlig Wi-Fi-tilkobling er en rutinemessig funksjon av bærbare datamaskiner og andre tilkoblede produkter. For bærbare og andre batteridrevne IoT-enheter har imidlertid strømkravene til konvensjonelle Wi-Fi-løsninger gjort kontinuerlig Wi-Fi-tilkobling upraktisk, og krever vanligvis at utviklere kompromitterer noen aspekter av enhetsfunksjonalitet, ytelse eller batterilevetid.

En SoC fra Dialog Semiconductor gir en komplett Wi-Fi-løsning som kan levere kontinuerlig Wi-Fi-tilkobling mens den bruker minimal strøm. Som vist, ved bruk av SoC eller tilhørende moduler, kan utviklere raskt implementere sikre batteridrevne enheter som kan gi brukerne fordelene med kontinuerlig Wi-Fi-tilkobling, samtidig som de oppfyller deres forventninger om forlenget batterilevetid.