Tilføj kontinuerlig Wi-Fi-forbindelse uden at gå på kompromis med batteriets levetid

Wi-Fi, der tilbyder høj båndbredde og allestedsnærværende, er stadig et primært tilslutningskrav til mange IoT-enheder (Internet of Things). For wearables og andre batteridrevne IoT-enheder har strømkravene til konventionelle Wi-Fi-løsninger imidlertid gjort kontinuerlig Wi-Fi-forbindelse upraktisk, hvilket typisk kræver, at udviklere kompromitterer et eller andet aspekt af enhedens funktionalitet, ydeevne eller batterilevetid.

Mens design af en brugerdefineret Wi-Fi-løsning til optimering til lav strøm kan være en mulighed for nogle hold, kan dette være en dyr og tidskrævende opgave, især i betragtning af manglen på kvalificerede RF-designere. Der kræves en mere komplet løsning, der også gør kontinuerlig Wi-Fi praktisk til IoT-enheder med lav effekt.

Denne artikel viser, hvordan udviklere kan implementere kontinuerlig Wi-Fi-forbindelse ved hjælp af funktioner med lav effekt, der er indbygget i en trådløs system-on-chip (SoC) -enhed fraDialog Semiconductor .

Udfordringerne ved at understøtte Wi-Fi-forbindelse til mobile enheder

Wi-Fi giver typisk en kombination af allestedsnærværende tilstedeværelse og ydeevneegenskaber, der kræves i en bred vifte af IoT-applikationer bygget omkring personlige mobile produkter, smart home-enheder og bygningsautomationssystemer, for blot at nævne et par stykker. Tidligere tvang det relativt høje strømforbrug af Wi-Fi-undersystemer udviklere til at kompromittere batteriets levetid eller signalstyrke i batteridrevne IoT-enheder.

De høje strømkrav ved traditionelle Wi-Fi-løsninger medfører yderligere udfordringer for IoT-udviklere. For eksempel kan krav til både Wi-Fi-forbindelse og forlænget batterilevetid øge designstørrelsen og kompleksiteten for at rumme større batterier. For wearables eller mange IoT-enheder, hvor større batterier muligvis ikke er en mulighed, er det måske ikke muligt at forsøge at forlænge batteriets levetid ved at reducere Wi-Fi-signalstyrken (og tilhørende strømforbrug).

Sammen med disse bekymringer står IoT-udviklere over for praktiske begrænsninger i det typiske Wi-Fi-signalmiljø, hvor signalstyrken kan variere markant på grund af intervejsinterferens og andre radiofrekvenssignalkarakteristikker (RF). I applikationer som bærbare computere kan en forbruger simpelthen flytte en bærbar computer til et andet sted med et bedre Wi-Fi-signal. I modsætning hertil skal en smart lås eller et husholdningsapparat opretholde pålidelig forbindelse og robust ydeevne, uanset hvor det er installeret.

For at understøtte både forlænget batterilevetid og robust Wi-Fi-signalstyrke drager udviklere typisk fuld fordel af dvaletilstand med lav effekt, der er tilgængelig i de fleste avancerede processorer, radioer og andre komplekse hardwarekomponenter. Ved at maksimere den tid, strømkrævende enheder bruger i deres respektive tilstande med lav strøm, kan udviklere implementere designs, der forlænger batteriets levetid for deres systemdesign, typisk med ringe indflydelse på systemets funktionalitet. I disse designs kan en timer med lav effekt muligvis med jævne mellemrum vække systemet for at læse sensorer og overføre sensordata trådløst, før det vender tilbage til dvaletilstand.

For nogle IoT-applikationer skal IoT-enheden imidlertid opretholde en kontinuerlig forbindelse til Wi-Fi-netværket for at sikre et hurtigt svar på brugerkommandoer udstedt via mobilapps, desktop-software eller endda andre enheder. For eksempel skal smarte låse, lys og kontakter, der findes i smarte hjem, forblive forbundet for at give et øjeblikkeligt svar på brugerkommandoer. At vente på, at en timerbaseret enhed til sidst vågner, opdager kommandoen og til sidst låser op for en dør eller tænder et lys, ville simpelthen være uacceptabelt for brugerne.

Dialog Semiconductor'sDA16200 SoC og tilknyttede moduler giver en effektiv løsning med lavt strømforbrug, der kan understøtte krav til både kontinuerlig Wi-Fi-forbindelse og forlænget batterilevetid.

Implementering af Wi-Fi-forbindelse med en trådløs SoC

DA16200 SoC er designet specielt til batteridrevne IoT-designs og kombinerer enArm® Cortex®-M4F med et komplet Wi-Fi-radio-undersystem, der kører en fuld netværksstak, hvilket eliminerer behovet for en ekstern netværksprocessor eller en værtsprocessor for at give stakfunktionalitet. Sammen med radioundersystemet integrerer enheden et komplet sæt funktionelle blokke og grænseflader, der typisk kræves i IoT-design (figur 1).

Figur 1: Dialog Semiconductor DA16200 SoC giver en komplet Wi-Fi-løsning, der er i stand til at levere kontinuerlig Wi-Fi-forbindelse, mens den bruger minimal strøm. (Billedkilde: Dialog Semiconductor)

Sammen med flere standardgrænseflader inkluderer enheden en 4-kanals 12-bit successiv tilnærmelsesregister (SAR) analog-til-digital-konverter (ADC) til understøttelse af analog signaloptagelse.

Til udførelse af applikationer indeholder DA16200 flere interne hukommelser, herunder:

• Skrivebeskyttet hukommelse til en boot loader, systemkerne, netværksstak og drivere.
• Statisk tilfældig adgangshukommelse (SRAM) til programdata. Programkoden udføres på plads (XIP) på seriel flashhukommelse, der fås via enhedens eksterne serielle flashhukommelsesinterface.
• Engangsprogrammerbar (OTP) hukommelse, der bruges til at gemme enhedsoplysninger såvel som kryptografitaster og en sikker boot loader. OTP-data forbliver sikre, fordi de kun kan tilgås via OTP-controlleren og ellers forbliver usynlige for normal dataadgang via systembussen.

For at hjælpe udviklere med at imødekomme den voksende efterspørgsel efter tilsluttet enhedssikkerhed integrerer DA16200 SoC et bredt sæt sikkerhedsmekanismer, herunder en kryptografimotor til Advanced Encryption Standard (AES), Secure Hash Algorithms (SHA) og andre krypteringer samt support til Transport Layer Security (TLS) protokol. Enheden inkluderer også Arm TrustZone CryptoCell-312 (CC312) sikkerhedsintellektuel ejendomsret (IP). CC312 er designet til enheder med lav effekt og understøtter sikker opstart og muliggør en tillidsrod for sikre applikationer.

Enheden forenkler Wi-Fi-forbindelse takket være en omfattende RF-blok. Sammen med indbyggede 802.11 medieadgangskontrol (MAC) og 802.11b/g/n fysiske (PHY) lag inkluderer radioundersystemet en on-chip transceiver med integrerede effektforstærkere (PA'er) og støjsvage forstærkere (LNA'er), som eliminere behovet for eksterne aktive komponenter. I drift udfører DA16200's Arm Cortex-M4F-processor en indbygget transmissionsstyringsprotokol/internetprotokol (TCP/IP) -stak for at aflaste tilslutningsoperationer fra et systems værtsprocessor.

For at drive sine forskellige blokke, herunder RF-blokken, integrerer DA16200 SoC en DC-DC-konverter, LDO-regulatorer (low dropout) og strømafbrydere. Administreret af enhedens realtidsur (RTC) -blok genererer konverteren og LDO'erne alle de nødvendige forsyningsskinner fra en enkelt VBAT-batteriforsyning. Mens DC-DC-konverter genererer 1,4 volt til RF-blokken og digital LDO fra VBAT, genererer I/O LDO de 1,8 volt, der kræves til ekstern flash og enhedens generelle I/O (GPIO) (figur 2).

Figur 2: DA16200 SoCs strømstyringsenhed styrer enhedens integrerede strømkomponenter, der leverer spænding til dets separate strømdomæner. (Billedkilde: Dialog Semiconductor)

DA16200 SoCs strømstyringsenhed styrer forsyningen til disse separate strømdomæner som en del af dens funktion til styring af enhedens tre lavtydende (dvaletilstand):

• Sleep 1 tilbyder den laveste strømdrift ved 0,2 mikroampere (μA): I denne tilstand er enheden stort set slukket, men vågner inden for 150 millisekunder (ms) som reaktion på en ekstern trigger, der leveres til SoC's to wake-up pins eller til en af flere digitale I/O'er, eller når et analogt indgangssignal overstiger en foruddefineret tærskel.
• Sleep 2 forbruger kun 1,8 μA, mens RTC-funktionaliteten bevares: I denne tilstand vågner SoC på mindre end 100 ms som reaktion på eksterne vågnehændelser eller ved afslutningen af en programmeret intern timer.
• Sleep 3 giver en unik kontinuerlig tilsluttet Wi-Fi-tilstand, der kan forbruge minimal strøm og vækker på mindre end 2 ms ved påvisning af indkommende Wi-Fi-datapakker: Som beskrevet nedenfor giver brug af Sleep 3 med traditionel TCP keepalive-funktionalitet grundlaget for implementering af en kontinuerlig Wi-Fi-tilslutningsmulighed, der bruger mindre end 50 μA gennemsnitlig strøm.

Dynamisk strømstyringsteknologi muliggør kontinuerlig Wi-Fi-forbindelse

Under disse lavtydende dvaletilstand ligger Dialog Semiconductors proprietære Dynamic Power Management (DPM) -teknologi, der lukker ubrugte on-chip-mikroelementer ned, hvilket resulterer i minimalt strømforbrug, når enheden ikke transmitterer eller modtager data. Under Wi-Fi-operationer minimerer DPM strømforbruget under transmission og modtagelse af radiooperationer ved hjælp af avancerede algoritmer for at vække de nødvendige mikroelementer, netop når de er nødvendige.

Dialog Semiconductor'sDA16200 softwareudviklingssæt (SDK) abstraherer detaljerne i strømstyring og DPM-drift med dets DPM Manager applikationsprogrammeringsgrænseflade (API). Til brugerdefineret softwareudvikling giver SDK adgang til DA16200-softwarestakken med applikations- og systemtjenester (figur 3).

Figur 3: DA16200 SoCs softwarearkitektur giver et komplet sæt system- og applikationstjenester, der kræves for at understøtte standard Wi-Fi-forbindelse i IoT-enheder. (Billedkilde: Dialog Semiconductor)

Implementering af kontinuerlig Wi-Fi-forbindelse kombinerer brug af DPM Manager og NetX Duo TCP/IP-biblioteket. NetX Duo-biblioteket leverer en TCP keepalive-funktion, der sender en TCP-pakke uden data til en Wi-Fi-router, hvilket sikrer, at routeren holder Wi-Fi-forbindelsen aktiv. Udviklere påberåber sig denne funktion ved simpelthen at indstille den aktuelle TCP-sokkelindstilling, keepalive_enabled, til true og angive antallet af sekunder, keepalive_timeout, mellem keepalive-pakker. NetX Duo transmitterer automatisk keepalive-rammer efter behov.

Mens keepalive-pakkerne opretholder netværksforbindelsen med en router eller anden vært, er DA16200s evne til at vågne fra Sleep 3-tilstand afhængig af detektering af standardinformationselementer for Traffic Indication Map (TIM) eller Delivery Traffic Indication Map (DTIM) indlejret i 802.11-styringsrammer , og bruges til at underrette netværksstationer såsom et DA16200-baseret system om, at netværkstrafik er tilgængelig for det. Når DA16200 er i slumretilstand, sikrer DA16200's DPM-teknologi, at radioundersystemet bruger minimal strøm på udkig efter TIM/DTIM-elementer. Når radioundersystemet DA16200 registrerer TIM/DTIM-elementer, vækker det SoC til at begynde at behandle normal Wi-Fi-trafik som enhver netværksstation.

Ved hjælp af DA16200 DPM Manager API behøver udviklere kun foretage et par intuitive opkald for at implementere denne funktionalitet. Efter at have defineret den krævede DPM-konfiguration, inklusive parametre og tilbagekald, bruger udviklere DPM Manager API-funktionskald til at påkalde og på anden måde interagere med DPM Manager. Indgang til og udgang fra Sleep 3 håndteres gennemsigtigt af DA16200 DPM's teknologi.

Eksempelapplikationer inkluderet i SDK illustrerer de grundlæggende designmønstre, der kræves for at implementere denne rækkefølge af operationer (liste 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 ;
}

Liste 1: Ved hjælp af DA16200 SoC kan udviklere implementere kontinuerlig Wi-Fi-forbindelse ved hjælp af konfigurationer og et par DPM API-funktionsopkald. (Kode kilde: Dialog Semiconductor)

Som vist i lister 1 implementerer udviklere denne mulighed i vid udstrækning kun ved hjælp af en initialiseringsfunktion (tcp_client_ka_dpm_sample_init_user_config()), der indstiller forskellige konfigurationsparametre, herunder keepalive-intervallet (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT), og giver forskellige opkaldsfrakoblinger (inklusive tilbagekald) behandling af indgående datapakker (tcp_client_ka_dpm_sample_recv_callback()). For at begynde TCP keepalive og DPM vækningssekvensen påkalder en separat funktion (tcp_client_ka_dpm_sample()) simpelthen en konfigurationsrutine (dpm_mng_regist_config_cb (tcp_client_ka_dpm_sample_init_user_config)) og DMP Manager (dpm_mng_start).

Som nævnt tidligere resulterer hele denne sekvens, inklusive standard TCP keepalive-pakker og DA16200 DPM-aktiveret Wi-Fi-overvågning, i en kontinuerlig Wi-Fi-forbindelsesfunktion, der typisk bruger mindre end 50 μA gennemsnitlig strøm.

Det samme designmønster kan bruges til at vække SoC fra dens dvaletilstand for at håndtere andre operationer. For eksempel viser en prøveapplikation anvendelse af DA16200's RTC til at vække SoC til at behandle data (lister 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);
    }
}

Liste 2: Udviklere kan implementere timerbaseret funktionalitet med lav effekt med DA16200 ved hjælp af et par DPM API-funktionsopkald for at sikre minimalt strømforbrug under DA16200-hvileperioder. (Kode kilde: Dialog Semiconductor)

Som vist i liste 2 kalder udvikleren en DPM Manager API-funktion (dpm_timer_create()) for at oprette en timer (SAMPLE_RTC_TIMER) og en anden DPM Manager API-funktion (dpm_app_sleep_ready_set()) for at indikere, at systemet er klar til at gå i dvale igen. DPM-motoren bestemmer derefter, hvor hurtigt systemet kan vende tilbage til dvaletilstand med lav effekt baseret på den aktuelle aktivitet. Senere, når timeren løber ud, udfører systemet udviklerens tilbagekaldsfunktion, rtc_timer_dpm_periodic_cb(), som udfører de nødvendige handlinger - i dette tilfælde skal du blot udskrive en meddelelse til konsollen. Når handlingen er afsluttet, udfører den samme tilbagekaldsfunktion dpm_app_sleep_ready_set() for at underrette DPM-motoren om, at systemet er klar til at gå i dvale igen. Som før afslutter DPM-motoren overgangen til dvaletilstand, når det er relevant.

Drop-in-moduler forenkler Wi-Fi-design

Mens DA16200 SDK forenkler softwaredesign, oversættes enhedens omfattende on-chip-funktionalitet til et relativt simpelt hardware-interface-design. Brug af DA16200 SoC sammen med en ekstern flashenhed, såsomWinbond Electronics ''W25Q16JVSNIQ 16 megabit (Mbit) NOR-hukommelses-IC og kun få ekstra komponenter, udviklere kan implementere et Wi-Fi-aktiveret sikkert IoT-design (figur 4).

Figur 4: Med sin omfattende integrerede funktionalitet kræver Dialog Semiconductor DA16200 SoC kun en ekstern seriel flash og minimale ekstra komponenter for at implementere et komplet Wi-Fi-system. (Billedkilde: Dialog Semiconductor)

Udviklere, der ønsker at fremskynde udviklingen af deres egne designs baseret på DA16200 SoC, kan henvende sig til Dialog Semiconductor-moduler, der eliminerer behovet for, at de implementerer SoC's hardware-interface. Sammen med DA16200 SoC inkluderer modulerne 4 megabyte (Mbytes) flash, RF-komponenter og valg af en indbygget chipantenne (DA16200MOD-AAC4WA32 ) eller u.FL-stik til en ekstern antenne (DA16200MOD-AAE4WA32 ). Fuldt certificeret af FCC, IC, CE og andre regulerende organer giver 13,8 x 22,1 x 3,3 millimeter (mm) moduler en drop-in hardwareløsning til implementering af kontinuerlig Wi-Fi-forbindelse med lav effekt.

Udviklere, der ønsker at udforske kontinuerlig Wi-Fi-forbindelse og hurtigt prototype IoT-design baseret på DA16200 SoC, kan drage fordel af Dialog SemiconductorDA16200MOD-DEVKT udviklingssæt. Dette sæt kombinerer et DA16200MOD-modul med en USB-grænseflade, nøgler og forbindelser for at hjælpe med at fremskynde udvikling og fejlfinding af DA16200-baserede designs.

Konklusion

Evnen til at opretholde kontinuerlig Wi-Fi-forbindelse er en rutinemæssig funktion af bærbare computere og andre tilsluttede produkter. For wearables og andre batteridrevne IoT-enheder har strømkravene til konventionelle Wi-Fi-løsninger imidlertid gjort kontinuerlig Wi-Fi-forbindelse upraktisk, hvilket typisk kræver udviklere at kompromittere et eller andet aspekt af enhedens funktionalitet, ydeevne eller batterilevetid.

En SoC fra Dialog Semiconductor giver en komplet Wi-Fi-løsning, der er i stand til at levere kontinuerlig Wi-Fi-forbindelse, mens du bruger minimal strøm. Som vist kan udviklere ved hjælp af SoC eller tilhørende moduler hurtigt implementere sikre batteridrevne enheder, der er i stand til at give brugerne fordelene ved kontinuerlig Wi-Fi-forbindelse, mens de imødekommer deres forventninger til forlænget batterilevetid.