Aggiungete connettività Wi-Fi continua senza compromettere la durata della batteria

Grazie a un'elevata larghezza di banda e alla sua ubiquità, il Wi-Fi rimane un requisito di connettività primario per molti dispositivi per Internet delle cose (IoT). Tuttavia, per i dispositivi indossabili e altri di IoT alimentati a batteria, i requisiti di alimentazione delle soluzioni Wi-Fi convenzionali hanno reso poco pratica la connettività Wi-Fi continua, richiedendo in genere agli sviluppatori di compromettere alcuni aspetti della funzionalità, delle prestazioni o della durata della batteria del dispositivo.

Se la progettazione di una soluzione Wi-Fi personalizzata e ottimizzata per la bassa potenza potrebbe essere un'opzione, può risultare costosa e dispendiosa in termini di tempo, soprattutto data la scarsità di progettisti RF qualificati. È necessaria una soluzione più completa che renda pratico il Wi-Fi continuo anche per i dispositivi IoT a bassa potenza.

Questo articolo spiega agli sviluppatori come implementare la connettività Wi-Fi continua utilizzando le caratteristiche di bassa potenza integrate in un dispositivo wireless system-on-chip (SoC) di Dialog Semiconductor.

Le difficoltà del supporto della connettività Wi-Fi per i dispositivi mobili

Il Wi-Fi fornisce tipicamente una combinazione di caratteristiche di onnipresenza e di prestazioni necessarie in una vasta gamma di applicazioni IoT create intorno a prodotti mobili personali, dispositivi di domotica e sistemi di automazione degli edifici, tanto per citarne alcuni. In passato, tuttavia, il consumo di corrente relativamente elevato dei sottosistemi Wi-Fi aveva costretto gli sviluppatori a compromettere la durata della batteria o l'intensità del segnale nei dispositivi IoT alimentati a batteria.

Gli elevati requisiti di potenza delle soluzioni Wi-Fi tradizionali comportano ulteriori sfide per gli sviluppatori di IoT. Ad esempio, i requisiti sia per la connettività Wi-Fi che per l'estensione della durata della batteria possono aumentare le dimensioni e la complessità del progetto per accogliere batterie più grandi. Per i dispositivi indossabili o per molti dispositivi IoT in cui le batterie più grandi potrebbero non essere un'opzione, i tentativi di prolungare la durata della batteria riducendo l'intensità del segnale Wi-Fi (e il relativo consumo energetico) potrebbero non essere fattibili.

Insieme a queste preoccupazioni, gli sviluppatori di IoT si trovano ad affrontare i limiti pratici del tipico ambiente del segnale Wi-Fi, dove l'intensità del segnale può variare sensibilmente a causa di interferenze multipercorso e altre caratteristiche del segnale a radiofrequenza (RF). In applicazioni come i laptop, l'utente può semplicemente spostarsi con il laptop in un punto diverso dove abbia un segnale Wi-Fi migliore. Per contro, una serratura intelligente o un elettrodomestico deve mantenere una connettività affidabile e prestazioni robuste, indipendentemente dal luogo in cui è installato.

Per supportare sia una durata della batteria più estesa sia la robustezza del segnale Wi-Fi, gli sviluppatori sfruttano tipicamente i vantaggi delle modalità di sospensione a bassa potenza disponibili nei processori più avanzati, nelle radio e in altri componenti hardware complessi. Massimizzando la quantità di tempo che i dispositivi energivori trascorrono nelle rispettive modalità a bassa potenza, gli sviluppatori possono implementare progetti che prolungano la durata della batteria dei sistemi, tipicamente con un impatto minimo sulla funzionalità. In questi modelli, un timer a bassa potenza potrebbe periodicamente riattivare il sistema per leggere brevemente i sensori e trasmettere i dati dei sensori in modalità wireless prima di tornare in sospensione.

Per alcune applicazioni IoT, tuttavia, il dispositivo IoT deve mantenere una connessione continua alla rete Wi-Fi per garantire una risposta rapida ai comandi impartiti dall'utente tramite app mobili, software desktop o anche altri dispositivi. Ad esempio, le serrature, le luci e gli interruttori intelligenti che trovano impiego nelle installazioni domotiche devono rimanere connessi per fornire una risposta immediata ai comandi dell'utente. Aspettare che un dispositivo basato su un timer si riattivi, rilevi il comando e infine apra una porta o accenda una luce sarebbe semplicemente inaccettabile.

Il SoC DA16200 e i moduli associati di Dialog Semiconductor offrono un'efficace soluzione a bassa potenza in grado di supportare i requisiti sia per la connettività Wi-Fi continua sia per l'estensione della durata della batteria.

Implementazione della connettività Wi-Fi con un SoC wireless

Progettato specificamente per i progetti IoT alimentati a batteria, il SoC DA16200 combina un Arm® Cortex®-M4F con un sottosistema radio Wi-Fi completo che gestisce un intero stack di rete, eliminando la necessità di un processore di rete esterno o di un processore host per fornire la funzionalità di stack. Insieme al sottosistema radio, il dispositivo integra una serie completa di blocchi funzionali e interfacce tipicamente richiesti nei progetti di IoT (Figura 1).

Figura 1: Il SoC DA16200 di Dialog Semiconductor è una soluzione Wi-Fi completa in grado di fornire una connettività Wi-Fi continua con un consumo minimo di corrente. (Immagine per gentile concessione di Dialog Semiconductor)

Insieme a molteplici interfacce standard, il dispositivo include un convertitore analogico/digitale (ADC) con registro ad approssimazioni successive (SAR) a 4 canali e 12 bit per supportare l'acquisizione di segnali analogici.

Per l'esecuzione dell'applicazione, DA16200 contiene varie memorie interne tra cui:

• Memoria di sola lettura per bootloader, kernel di sistema, stack di rete e driver.
• Memoria statica ad accesso casuale (SRAM) per i dati del programma. Il codice di programma viene eseguito localmente (Execute-in-Place (XIP) sulla memoria flash seriale accessibile attraverso l'interfaccia della memoria flash seriale esterna del dispositivo.
• Memoria programmabile una sola volta (OTP) utilizzata per memorizzare le informazioni del dispositivo, nonché chiavi di crittografia e un bootloader sicuro. I dati OTP rimangono sicuri perché vi si può accedere solo attraverso il controller OTP e rimangono altrimenti invisibili al normale accesso ai dati attraverso il bus di sistema.

Per aiutare gli sviluppatori a soddisfare la crescente domanda di sicurezza dei dispositivi connessi, il SoC DA16200 integra un'ampia serie di meccanismi di sicurezza tra cui un motore di crittografia Advanced Encryption Standard (AES), Secure Hash Algorithms (SHA) e altri cifrari, oltre al supporto per il protocollo Transport Layer Security (TLS). Il dispositivo include anche la proprietà intellettuale (IP) di sicurezza di Arm TrustZone CryptoCell-312 (CC312). Progettato per dispositivi a bassa potenza, CC312 supporta l'avvio sicuro e abilita una radice di attendibilità per applicazioni sicure.

Il dispositivo semplifica la connettività Wi-Fi grazie a un blocco RF completo. Insieme a un MAC (Media Access Controller) 802.11 integrato e agli strati fisici (PHY) 802.11b/g/n, il sottosistema radio comprende un transceiver su chip con amplificatori di potenza (PA) integrati e amplificatori a basso rumore (LNA) che eliminano la necessità di componenti attivi esterni. Durante il funzionamento, il processore Arm Cortex-M4F di DA16200 esegue uno stack TCP/IP (Transmission Control Protocol/Internet Protocol) per scaricare le operazioni di connettività dal processore host di un sistema.

Per alimentare i vari blocchi, compreso il blocco RF, il SoC DA16200 integra un convertitore c.c./c.c., regolatori a bassa caduta di tensione (LDO) e interruttori di alimentazione. Gestiti dal blocco del clock in tempo reale (RTC) del dispositivo, il convertitore e gli LDO generano tutti i rail di alimentazione necessari da una singola alimentazione a batteria VBAT. Mentre il convertitore c.c./c.c. genera 1,4 V per il blocco RF e l'LDO digitale da VBAT, l'LDO I/O genera gli 1,8 V necessari per la flash esterna e l'I/O per uso generale (GPIO) (Figura 2).

Figura 2: L'unità di gestione della potenza del SoC DA16200 controlla i componenti di potenza integrati del dispositivo che forniscono la tensione ai suoi domini di potenza separati. (Immagine per gentile concessione di Dialog Semiconductor)

L'unità di gestione della potenza del SoC DA16200 controlla l'alimentazione di questi domini di potenza separati come parte della sua funzione di gestione delle tre modalità a bassa potenza (sospensione) del dispositivo:

• Sleep 1 offre la più bassa potenza di funzionamento a 0,2 μA: in questa modalità, il dispositivo è in gran parte spento ma si riattiva entro 150 millisecondi in risposta a un trigger esterno sui due pin di riattivazione del SoC o su uno dei vari I/O digitali, oppure quando un segnale di ingresso analogico supera una soglia predefinita.
• Sleep 2 consuma solo 1,8 μA mantenendo la funzionalità RTC: in questa modalità, il SoC si riattiva in meno di 100 ms in risposta a eventi di riattivazione esterni o al completamento di un timer interno programmato.
• Sleep 3 offre un'esclusiva modalità Wi-Fi connessa in modo continuativo che può consumare una corrente minima e si riattiva in meno di 2 ms al rilevamento di pacchetti di dati Wi-Fi in entrata. Come descritto di seguito, l'uso di Sleep 3 con la funzionalità convenzionale TCP keepalive fa da base per implementare una capacità di connettività Wi-Fi continua che consuma in media meno di 50 μA di corrente.

La tecnologia di gestione dinamica della potenza assicura una connettività Wi-Fi continua

Alla base di queste modalità di sospensione a bassa potenza c'è la tecnologia proprietaria Dynamic Power Management (DPM) di Dialog Semiconductor che spegne i microelementi non utilizzati del chip, con il risultato di ridurre al minimo il consumo di energia quando il dispositivo non trasmette o non riceve dati. Durante le operazioni Wi-Fi, il DPM riduce al minimo il consumo di energia durante la trasmissione e la ricezione radio utilizzando algoritmi avanzati per attivare i microelementi necessari solo quando servono.

Il kit di sviluppo software DA16200 (SDK) di Dialog Semiconductor estrae i dettagli della gestione della potenza e del funzionamento del DPM con la sua interfaccia di programmazione delle applicazioni (API) DPM Manager. Per lo sviluppo di software personalizzato, l'SDK dà accesso allo stack di applicazioni e servizi di sistema del software DA16200 (Figura 3).

Figura 3: L'architettura software del SoC DA16200 fornisce un set completo di servizi di sistema e di applicazione necessari per supportare la connettività Wi-Fi standard nei dispositivi IoT. (Immagine per gentile concessione di Dialog Semiconductor)

L'implementazione della connettività Wi-Fi continua combina l'uso di DPM Manager e della libreria TCP/IP NetX Duo. La libreria NetX Duo fornisce una funzione TCP keepalive che invia un pacchetto TCP senza dati a un router Wi-Fi, assicurando che il router mantenga attiva la connessione Wi-Fi. Gli sviluppatori invocano questa caratteristica semplicemente impostando l'opzione corrente del socket TCP, keepalive_enabled, su true, e indicano il numero di secondi, keepalive_timeout, tra i pacchetti keepalive. NetX Duo trasmette automaticamente i frame keepalive secondo necessità.

Mentre i pacchetti keepalive mantengono la connessione di rete con un router o un altro host, la capacità di DA16200 di riattivarsi dalla modalità Sleep 3 si basa sul rilevamento degli elementi informativi standard Traffic Indication Map (TIM) o Delivery Traffic Indication Map (DTIM) incorporati nei frame di gestione 802.11 e viene utilizzata per notificare alle stazioni di rete (es. un sistema basato su DA16200) che è disponibile il traffico di rete. Quando DA16200 è in modalità Sleep 3, la tecnologia DPM assicura che il sottosistema radio utilizzi una potenza minima alla ricerca di elementi TIM/DTIM. Quando il sottosistema radio DA16200 rileva elementi TIM/DTIM, attiva il SoC per iniziare a elaborare il normale traffico Wi-Fi, come qualsiasi stazione di rete.

Utilizzando l'API DPM Manager DA16200, gli sviluppatori devono solo programmare alcune chiamate intuitive per implementare questa funzionalità. Dopo aver definito la configurazione DPM richiesta, inclusi i parametri e i callback, gli sviluppatori utilizzano le chiamate alle funzioni API di DPM Manager per invocare e interagire in altro modo con DPM Manager. L'entrata e l'uscita da Sleep 3 sono gestite in modo trasparente dalla tecnologia DPM di DA16200.

Le applicazioni di esempio incluse nell'SDK illustrano i modelli di progettazione di base necessari per implementare questa sequenza di operazioni (Listato 1).

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

Listato 1: Utilizzando il SoC DA16200, gli sviluppatori possono implementare la connettività Wi-Fi continua utilizzando le configurazioni e alcune chiamate di funzioni API DPM. (Codice per gentile concessione di Dialog Semiconductor)

Come mostrato nel Listato 1, gli sviluppatori implementano questa capacità utilizzando in gran parte solo una funzione di inizializzazione (tcp_client_ka_dpm_sample_init_user_config()) che imposta vari parametri di configurazione tra cui l'intervallo keepalive (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT), e fornisce vari callback, compresi quelli per la riattivazione DMP (tcp_client_ka_dpm_sample_wakeup_callback()) e per l'elaborazione dei pacchetti di dati in entrata (tcp_client_ka_dpm_sample_recv_callback()). Per iniziare la sequenza di riattivazione TCP keepalive e DPM, una funzione separata (tcp_client_ka_dpm_sample()) richiama semplicemente una routine di configurazione (dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config)) e DMP Manager (dpm_mng_start())).

Come accennato in precedenza, l'intera sequenza, compresi i pacchetti standard TCP keepalive e il monitoraggio Wi-Fi abilitato DPM DA16200, si traduce in una capacità di connettività Wi-Fi continua che consuma tipicamente meno di 50 μA di corrente media.

Questo stesso schema di progettazione può essere usato per riattivare il SoC dalle sue modalità di sospensione per gestire altre operazioni. Ad esempio, un'applicazione di esempio mostra l'uso dell'RTC di DA16200 per riattivare il SoC ed elaborare i dati (Listato 2).

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

Listato 2: Gli sviluppatori possono implementare funzionalità basate su timer a bassa potenza con DA16200 utilizzando alcune chiamate di funzione API DPM per garantire un consumo energetico minimo durante i periodi di sospensione di DA16200. (Codice per gentile concessione di Dialog Semiconductor)

Come mostrato nel Listato 2, lo sviluppatore chiama una funzione API di DPM Manager (dpm_timer_create()) per creare un timer (SAMPLE_RTC_TIMER) e un'altra funzione API di DPM Manager (dpm_app_sleep_ready_set()) per indicare che il sistema è pronto pet tornare in sospensione. Il motore DPM determinerà quindi la velocità con cui il sistema può tornare alla modalità di sospensione a bassa potenza in base all'attività corrente. Più tardi, quando il timer si esaurisce, il sistema esegue la funzione di callback dello sviluppatore, rtc_timer_dpm_periodic_cb(), che esegue le operazioni richieste, in questo caso, semplicemente stampando una notifica alla console. Quando l'operazione è stata completata, la stessa funzione di callback esegue dpm_app_sleep_ready_set() per notificare al motore DPM che il sistema è pronto per tornare in sospensione. Come prima, il motore DPM completa il passaggio alla modalità di sospensione quando opportuno.

I moduli drop-in semplificano la progettazione del Wi-Fi

Mentre l'SDK DA16200 semplifica la progettazione del software, l'ampia funzionalità su chip del dispositivo si traduce in un'interfaccia hardware relativamente semplice da progettare. Usando il SoC DA16200 insieme a un dispositivo flash esterno, come il CI di memoria NOR a 16 Mbit W25Q16JVSNIQ di Winbond Electronics e pochi altri componenti aggiuntivi, gli sviluppatori possono implementare un progetto IoT sicuro abilitato per il Wi-Fi (Figura 4).

Figura 4: Con la sua ampia funzionalità integrata, il SoC DA16200 di Dialog Semiconductor richiede solo una flash seriale esterna e pochi altri componenti aggiuntivi per implementare un sistema Wi-Fi completo. (Immagine per gentile concessione di Dialog Semiconductor)

Gli sviluppatori che desiderano accelerare lo sviluppo di progetti basati sul SoC DA16200 possono guardare ai moduli Dialog Semiconductor che eliminano la necessità di implementare l'interfaccia hardware del SoC. Insieme al SoC DA16200, i moduli includono 4 Mbyte di flash, componenti RF e la scelta di un'antenna in chip su scheda (DA16200MOD-AAC4WA32) o di un connettore u.FL per un'antenna esterna (DA16200MOD-AAE4WA32). Completamente certificati da FCC, IC, CE e da altri enti normativi, i moduli di 13,8 x 22,1 x 3,3 mm sono una soluzione hardware drop-in per implementare la connettività Wi-Fi continua a bassa potenza.

Gli sviluppatori interessati alla connettività Wi-Fi continua e a realizzare rapidamente prototipi di progetti IoT basati sul SoC DA16200 possono sfruttare immediatamente il kit di sviluppo DA16200MOD-DEVKT di Dialog Semiconductor. Questo kit combina un modulo DA16200MOD con un'interfaccia USB, chiavi e connessioni per aiutare a velocizzare lo sviluppo e il debug di progetti basati su DA16200.

Conclusione

La capacità di mantenere connettività Wi-Fi continua è una caratteristica tipica dei laptop e di altri prodotti connessi. Tuttavia, per i dispositivi indossabili e altri di IoT alimentati a batteria, i requisiti di alimentazione delle soluzioni Wi-Fi convenzionali hanno reso poco pratica la connettività Wi-Fi continua, richiedendo in genere agli sviluppatori di compromettere alcuni aspetti della funzionalità, delle prestazioni o della durata della batteria del dispositivo.

Un SoC di Dialog Semiconductor è una soluzione Wi-Fi completa in grado di fornire una connettività Wi-Fi continua con un consumo minimo di corrente. Come mostrato, utilizzando il SoC o i moduli associati, gli sviluppatori possono implementare rapidamente dispositivi sicuri alimentati a batteria in grado di fornire agli utenti i vantaggi di una connettività Wi-Fi continua, soddisfacendo al contempo le loro aspettative di una maggiore durata della batteria.