Come massimizzare la durata della batteria nei progetti IoT Wi-Fi/Bluetooth dual-mode

Ai progettisti di dispositivi per Internet delle cose (IoT) alimentati a batteria e di altri prodotti connessi viene chiesto di soddisfare i requisiti, in conflitto tra loro, di connettività wireless continua e durata estesa della batteria. La crescente domanda di connettività Bluetooth 5 e Wi-Fi nello stesso dispositivo contribuisce ad appesantire ulteriormente i vincoli di potenza. Sebbene i protocolli Wi-Fi e Bluetooth forniscano protocolli standard per contribuire a ridurre il consumo di energia, il supporto più diretto si presenta sotto forma di un'architettura che combina sottosistemi radio in grado di alleggerire (offload) le attività di elaborazione della rete con un microcontroller a bassa potenza.

Questo articolo illustrerà l'importanza della connettività Wi-Fi/Bluetooth dual-mode e di come essa complichi i progetti IoT. Mostrerà quindi come sia possibile utilizzare una scheda di sviluppo e il software associato di Cypress Semiconductor per lo sviluppo di dispositivi IoT Wi-Fi/Bluetooth dual-mode in grado di offrire connessione continua e durata estesa della batteria.

La crescente necessità di connettività continua Wi-Fi/Bluetooth dual-mode

La connettività Bluetooth è considerata un requisito standard per molti dispositivi IoT progettati per interagire con gli utenti attraverso smartphone abilitati al Bluetooth e altri dispositivi mobili. Per molte applicazioni IoT, tuttavia, i dispositivi IoT hanno bisogno di connettività Wi-Fi per accedere a una rete WLAN per raggiungere direttamente Internet o per interagire con altri dispositivi peer e sistemi host sulla stessa rete.

Sotto molti aspetti, sarebbe molto più semplice per gli sviluppatori se questi dispositivi IoT avessero bisogno di connettersi solo alla WLAN o all'host Bluetooth quando hanno bisogno di trasmettere i loro dati o altri messaggi. Poiché il ciclo di lavoro attivo per molti dispositivi IoT è tipicamente basso, questi dispositivi potrebbero allungare la durata della batteria funzionando prevalentemente in modalità di sospensione a basso consumo, riattivandosi per il tempo sufficiente a eseguire misurazioni dei sensori, completare le attività di elaborazione correlate e trasmettere i dati risultanti prima di tornare alla modalità a bassa potenza. In realtà, la maggior parte dei dispositivi IoT deve rispondere rapidamente ai comandi asincroni in entrata e ai dati provenienti dai dispositivi peer, dai sistemi host e dagli utenti finali.

Per rimanere reattivi, i dispositivi IoT devono fornire l'apparenza di una connettività continua, rimanendo attenti al traffico in entrata in modo da poter rispondere entro un periodo di tempo accettabile. Se gli sviluppatori cercano di soddisfare questo requisito fondamentale riattivando ripetutamente i loro dispositivi per ricevere il traffico in entrata, la batteria del dispositivo si esaurirà rapidamente. Infatti, i ricevitori radio nei dispositivi Wi-Fi alimentati a batteria consumano tipicamente più energia nel tempo rispetto ai trasmettitori radio, nonostante il maggiore consumo di energia associato a un'operazione di trasmissione individuale. Naturalmente, l'energia consumata dal processore host del dispositivo per il suo contributo in ogni operazione di ricezione aggiunge il proprio carico sostanziale al bilancio energetico. Fortunatamente, gli standard wireless definiscono protocolli che consentono agli sviluppatori di ridurre la potenza, pur mantenendo l'illusione di una connettività continua.

In che modo gli standard di connettività wireless aiutano i dispositivi a ridurre il consumo di energia

Nel funzionamento normale, le stazioni di ricezione (STA) Wi-Fi risparmiano energia spegnendo la maggior parte del loro sottosistema Wi-Fi. Poiché i punti di accesso (AP) bufferizzano i frame per le STA in sospensione, non va perso alcun messaggio. Nell'ambito delle loro normali operazioni di gestione della rete, gli AP trasmettono regolarmente segnali che contengono una bitmap, chiamata mappa di indicazione del traffico (TIM), che indica se l'AP ha traffico in attesa per ogni STA. Gli AP trasmettono inoltre periodicamente un segnale (beacon) che contiene una mappa di indicazione del traffico di consegna (DTIM), che indica la disponibilità di dati multicast o broadcast bufferizzati. Ci si aspetta che le STA si riattivino regolarmente entro il valore del periodo DTIM, che è un multiplo dell'intervallo normale del beacon. Una rete IoT configurata con un alto valore di periodo DTIM consentirebbe ai dispositivi nella sua rete di ridurre il consumo di energia perché potrebbero rimanere in sospensione più a lungo prima di riattivare il ricevitore per ricevere un beacon che indica che l'AP ha dei frame da inviargli. Questo è l'approccio fondamentale alla base del meccanismo di Power Save Polling dello standard 802.11 discusso di seguito.

Bluetooth Low Energy (BLE) consente ai dispositivi di ridurre il consumo di energia ottimizzando il carico utile e la frequenza di advertising del Bluetooth. Aumentando l'intervallo di advertising, i dispositivi IoT possono ritardare le operazioni del trasmettitore; diminuendo il carico utile, i dispositivi IoT possono ridurre la durata degli eventi del trasmettitore. Naturalmente, non tutte le applicazioni possono tollerare lunghi intervalli di advertising o carichi utili minimi. In un dispositivo di rilevamento in tempo reale o audio, ad esempio, lunghi intervalli di advertising significano connessioni ritardate che potrebbero influenzare negativamente il comportamento dell'applicazione nel suo complesso.

I dispositivi periferici possono utilizzare un'altra funzione BLE chiamata latenza slave che permette alla periferica di saltare gli eventi di connessione. Come nel caso del DTIM del Wi-Fi, la latenza slave del BLE consente ai dispositivi di rimanere in modalità a bassa potenza per un periodo di tempo più lungo. Invece di aumentare semplicemente l'intervallo di connessione, questa speciale modalità consente alla periferica di saltare gli eventi di connessione con un host, ma comunque di riattivare e inviare i dati secondo necessità senza incorrere in ulteriori latenze.

Supporto per la connettività dual-mode e per una durata estesa della batteria

Questi metodi aiutano a ridurre la durata e la frequenza del funzionamento a piena potenza nei dispositivi Wi-Fi e Bluetooth, ma gli sviluppatori possono fare molto di più per prolungare la durata della batteria utilizzando le capacità hardware e software dimostrate nel kit Wi-Fi BT Pioneer CY8CKIT-062S2-43012 di Cypress Semiconductor. Insieme ai fili per ponticelli e a un cavo USB, il kit di Cypress comprende la scheda PSoC 62S2 Wi-Fi BT Pioneer, che fornisce una piattaforma di sviluppo e un sistema hardware completi per l'implementazione di progetti IoT a bassa potenza. Utilizzato con il software di Cypress, il kit di Cypress consente agli sviluppatori di valutare immediatamente e di implementare rapidamente una serie di sofisticate capacità di gestione della potenza.

Insieme a pulsanti, LED e connettori di interfaccia multipli, la scheda del kit integra un dispositivo PSoC 5LP CY8C5868LTI-LP038 che fornisce la programmazione e il debug su scheda con KitProg3 di Cypress. Per l'archiviazione aggiuntiva su scheda, Cypress integra il suo dispositivo di memoria Flash NOR seriale da 512 Mbit S25FL512S e la sua memoria ad accesso casuale ferroelettrica (FeRAM) da 4 Mbit CY15B104 (Figura 1).

Figura 1: La scheda PSoC 62S2 Wi-Fi BT Pioneer di Cypress fornisce una serie completa di caratteristiche di sistema costruite attorno a un modulo portante che integra un microcontroller PSoC 6 e un modulo di connettività wireless Wi-Fi/Bluetooth. (Immagine per gentile concessione di Cypress Semiconductor)

Nel cuore della scheda, un modulo portante integra un microcontroller PSoC 6 di Cypress Semiconductor e un modulo di connettività wireless Type 1LV LBEE59B1LV di Murata Electronics con componenti passivi. Un interruttore a radiofrequenza (RF) e un'antenna in chip miniaturizzata da 2,45 GHz/5 GHz dual-band completano i dispositivi di supporto.

Progettato specificamente per eliminare il convenzionale compromesso tra prestazioni di elaborazione e consumo di energia, il PSoC 6 integra un Arm® Cortex®-M4 a 150 MHz, che funge da processore per applicazioni principale, e un Arm Cortex-M0+ a 100 MHz, che gestisce il funzionamento a bassa potenza. Insieme alla RAM statica (SRAM) e alla memoria Flash integrata, il PSoC6 include un motore di crittografia, periferiche analogiche e digitali programmabili, supporto per il rilevamento tattile CapSense e interfacce di sistema multiple (Figura 2).

Figura 2: Integrato nel modulo portante della scheda PSoC 62S2 Wi-Fi BT Pioneer di Cypress, un microcontroller PSoC 6 utilizza un'architettura multicore per soddisfare i requisiti sia per l'elaborazione delle applicazioni che per l'esecuzione in tempo reale a bassa potenza. (Immagine per gentile concessione di Cypress Semiconductor)

Il modulo LBEE59B1LV di Murata fornisce un sottosistema radio completo in un contenitore di 10,0 x 7,2 x 1,4 mm che contiene un dispositivo Wi-Fi + Bluetooth WICED (Wireless Internet Connectivity for Embedded Devices) CYW43012 di Cypress, clock di riferimento e filtri (Figura 3).

Figura 3: Il modulo di connettività wireless Type 1LV LBEE59B1LV di Murata fornisce un sottosistema radio Wi-Fi + Bluetooth completo e pre-certificato costruito intorno ad un dispositivo CYW43012 WICED. (Immagine per gentile concessione di Murata Electronics)

Il modulo supporta la connettività wireless a 2,4 GHz e 5 GHz con Bluetooth 5.0 e Wi-Fi 802.11a/b/g/n. Inoltre, fornisce una modalità compatibile con 802.11ac, che supporta la modulazione dell'ampiezza in quadratura (QAM) di 256 secondo 802.11ac per i canali a 20 MHz nella banda dei 5 GHz, offrendo uno throughput più elevato e una minore energia per bit rispetto ai prodotti solo 802.11n. Progettato per accelerare lo sviluppo, il modulo LBEE59B1LV di Murata è precertificato in più regioni, eliminando i lunghi ritardi associati ai test di conformità e alla certificazione.

All'interno del modulo, il dispositivo WICED di Cypress integra un processore Arm Cortex-M3 e un processore Arm Cortex-M4 nei sottosistemi Wi-Fi e Bluetooth, rispettivamente. Sebbene non sia disponibile per il codice del cliente, il processore Arm Cortex-M3 esegue il firmware di Cypress che supporta le operazioni Wi-Fi e le funzionalità aggiuntive, comprese le funzionalità di offload descritte di seguito. Il processore Arm Cortex-M4 nel sottosistema Bluetooth esegue il firmware del controller Bluetooth, lo stack Bluetooth e i profili. Inoltre, questo core può eseguire il codice del cliente programmato con il kit di sviluppo software (SDK) WICED di Cypress.

Utilizzo di metodi di risparmio energetico nei progetti di IoT wireless

Progettato per ridurre al minimo il consumo di energia, il PSoC 6 e il modulo di connettività wireless sono dotati di una serie completa di modalità di potenza e di capacità di riduzione della potenza. Cypress sostiene questa piattaforma hardware efficiente dal punto di vista energetico con un corposo complemento software progettato per semplificare l'uso di metodi di risparmio energetico nei progetti di IoT wireless. Per esempio, gli sviluppatori possono facilmente implementare il metodo di Power Save Polling menzionato in precedenza utilizzando la libreria embedded indipendente Wi-Fi Host Driver (WHD).

Gli sviluppatori semplicemente chiamano la funzione di interfaccia di programmazione di applicazioni (API) WHD whd_wifi_enable_powersave() per abilitare il Power Save Polling e whd_wifi_disable_powersave() per disabilitarlo in un secondo tempo nel dispositivo. Quando è abilitato, la STA informa l'AP che è andata in sospensione. Come accennato in precedenza, l'AP bufferizza i frame destinati alla STA in sospensione e configura il suo beacon periodico per indicare che sono disponibili dei frame. Quando la STA si attiva per controllare il beacon, inizia un processo standard per recuperare tali frame.

Sebbene il meccanismo di Power Save Polling sia destinato alle STA con cicli di lavoro leggeri, un metodo simile, chiamato Power Save without Poll (PS-non-Poll), supporta le STA con requisiti di throughput più elevato. Qui la STA trasmette un frame di dati a funzione nulla, che avvia il trasferimento del frame dall'AP.

Power Save Polling e Power Save without Poll (PS-non-Poll) consentono ai dispositivi di ridurre le operazioni del ricevitore, ma non aiutano ad eliminare le transazioni non necessarie correlate alle operazioni di rete. Ad esempio, qualsiasi rete, compresa una WLAN IoT, quando è connessa a una rete esterna, in particolare l'Internet pubblico, trasporta traffico di pacchetti indesiderati. La possibilità di lasciar fuori questi pacchetti filtrandoli all'interno del sottosistema di comunicazione senza coinvolgere il processore host del dispositivo IoT consentirebbe al processore host di rimanere in modalità di sospensione a basso consumo.

Oltre ai pacchetti indesiderati, anche il traffico di rete legittimo potrebbe riattivare inutilmente il processore host. Ad esempio, il protocollo di risoluzione degli indirizzi (ARP) standard Wi-Fi utilizza i pacchetti broadcast come parte della sua funzione per mappare un indirizzo IP associato ad un dispositivo con l'indirizzo MAC (Media Access Control) del dispositivo. Questa operazione è essenziale per la normale funzione WLAN, consentendo ai dispositivi di raggiungere gli altri nella loro rete, di rilevare indirizzi IP duplicati e di notificare ad altri dispositivi l'eventuale modifica di un indirizzo IP.

I pacchetti di richiesta e risposta ARP sono così fondamentali per le operazioni di rete che il processore host di un dispositivo IoT può diventare sovraccarico semplicemente elaborando le richieste e le risposte ARP. Se l'interfaccia WLAN del dispositivo passa semplicemente le richieste e le risposte tra l'host e la rete, ogni richiesta ARP riattiva l'host, a volte inutilmente.

Al contrario, il modulo di connettività wireless di Murata interviene in questo scambio, alleggerendo (offload) il microcontroller PSoC 6 della gestione delle richieste ARP. Quando il PSoC 6 è altrimenti impegnato nella sua funzionalità dell'applicazione IoT primaria, questa capacità preserva i cicli del processore per l'esecuzione dell'applicazione. Se il PSoC 6 è in modalità di sospensione, questa capacità aiuta a ridurre il consumo energetico complessivo del dispositivo IoT. Abilitando l'offload ARP con risposta automatica peer, il modulo di Murata riattiva il PSoC 6 solo se una richiesta ARP in entrata non può essere soddisfatta dalle voci memorizzate nel modulo di Murata (Figura 4, a sinistra).

Figure 4: Quando è abilitato, l'offload ARP intercetta le richieste ARP dalla rete (a sinistra) o dal processore host (a destra), rispondendo automaticamente quando la cache soddisfa la richiesta (in alto) e riattivando il processore solo sui fallimenti cache (in basso). (Immagine per gentile concessione di Cypress Semiconductor)

Questo stesso approccio può anche contribuire a ridurre il consumo di energia della WLAN. Nel funzionamento normale, il modulo di Murata è in grado di monitorare (snooping) il traffico di rete e conservare in cache le coppie IP:MAC di altre risposte ARP. Utilizzando la risposta automatica dell'host, il modulo di Murata può rispondere alle richieste ARP dal PSoC 6, invocando il suo sottosistema radio solo se la richiesta del PSoC 6 non può essere soddisfatta dalla cache ARP (Figura 4, a destra).

Semplice implementazione basata su menu delle funzioni di risparmio energetico

L'implementazione dell'offload ARP con il kit Pioneer è straordinariamente semplice. Incluso nell'ambiente di sviluppo integrato (IDE) ModusToolBox (MTB) di Cypress, il tool Device Configurator di Cypress permette agli sviluppatori di implementare questa funzionalità con poche selezioni di menu. Cypress fornisce file di configurazione pre-costruiti che permettono agli sviluppatori di selezionare rapidamente diverse configurazioni, compreso l'offload ARP.

L'uso dello strumento Device Configurator per definire esplicitamente le configurazioni è quasi altrettanto semplice. Gli sviluppatori utilizzano le opzioni di menu dello strumento per abilitare il pin di riattivazione dell'host, assegnare un nome al pin (CYBSP_WIFI_HOST_WAKE) e impostarne i parametri (Figura 5).

Figura 5: Lo strumento Device Configurator di Cypress permette agli sviluppatori di utilizzare i menu per impostare le opzioni di risparmio energetico disponibili con la scheda Pioneer. (Immagine per gentile concessione di Cypress Semiconductor)

Nella scheda Wi-Fi dello strumento, gli sviluppatori abilitano la riattivazione dell'host e impostano il pin di interrupt sul nome inserito in precedenza (CYBSP_WIFI_HOST_WAKE). Ulteriori opzioni di menu consentono di abilitare l'offload ARP, impostare la funzione di risposta automatica peer, abilitare lo snooping di rete e impostare il tempo di scadenza delle informazioni della cache (Figura 6).

Figura 6: Utilizzando le schede di menu aggiuntive nello strumento Device Configurator di Cypress, gli sviluppatori possono abilitare l'offload ARP e funzioni specifiche come la risposta automatica peer. (Immagine per gentile concessione di Cypress Semiconductor)

Dopo aver salvato la configurazione, gli sviluppatori semplicemente generano i file sorgente, costruiscono il progetto modificato e programmano la scheda Pioneer. Con una procedura simile, gli sviluppatori possono configurare il modulo di Murata per l'offload del filtraggio dei pacchetti Wi-Fi e gestire altri tipi comuni di operazioni di rete. Questo stesso approccio permette anche a un dispositivo IoT di eseguire il protocollo TCP Wi-Fi "keep alive" necessario per mantenere la connettività Wi-Fi, il tutto senza riattivare il processore host IoT.

Nelle normali operazioni WLAN, un dispositivo client e un server host mantengono le connessioni TCP scambiando pacchetti keep alive. Se una delle due parti di questo scambio non riceve una risposta dopo alcuni tentativi, termina la connessione. Anche nei dispositivi IoT con vincoli di potenza, il processore host deve continuamente riattivarsi per partecipare a questo scambio o usare ancora più energia per ristabilire continuamente le connessioni.

Come per l'offload ARP, gli sviluppatori possono usare lo strumento Device Configurator per abilitare l'offload keep alive TCP. Una volta abilitata questa funzione, il modulo di Murata esegue automaticamente il protocollo keep alive senza riattivare il PSoC 6 (Figura 7).

Figura 7: Quando l'offload keep alive TCP è abilitato, il modulo di connettività wireless (dispositivo WLAN) esegue automaticamente il protocollo keep alive, permettendo al processore host di rimanere in modalità di sospensione a basso consumo. (Immagine per gentile concessione di Cypress Semiconductor)

Sebbene Cypress raccomandi l'uso dello strumento Device Configurator come il percorso più semplice per l'implementazione, gli sviluppatori possono anche implementare manualmente le funzionalità di risparmio energetico della piattaforma di Cypress, tra cui l'offload ARP, il filtraggio dei pacchetti, l'offload keep alive TCP, e altre ancora.

Alla base di entrambi gli approcci c'è il middleware Low Power Assistant (LPA) di Cypress che supporta queste funzioni di risparmio energetico per Wi-Fi, Bluetooth e il microcontroller PSoC 6, insieme ad altre funzionalità oltre a quelle qui menzionate.

Dopo che lo sviluppatore ha definito le configurazioni usando i menu o aggiungendo manualmente il codice di configurazione, il firmware LPA opera in modo trasparente verso l'applicazione, orchestrando automaticamente l'uso di capacità software e caratteristiche hardware a bassa potenza.

Conclusione

La necessità di una connettività wireless continua e di una durata estesa della batteria nei dispositivi IoT presenta requisiti in conflitto per i progettisti che hanno la necessità di supportare sia il Wi-Fi che il Bluetooth. Come mostrato, combinando un sottosistema radio in grado di alleggerire (offload) le attività di elaborazione della rete con un microcontroller a bassa potenza, il kit Wi-Fi BT Pioneer CY8CKIT-062S2-43012 di Cypress Semiconductor permette ai progettisti di soddisfare i loro requisiti di connettività wireless IoT e di bassa potenza.