Ajouter une connectivité Wi-Fi continue sans compromettre la durée de vie des batteries

Offrant une large bande passante et une grande omniprésence, le Wi-Fi reste une exigence de connectivité essentielle pour de nombreux dispositifs Internet des objets (IoT). Cependant, pour les dispositifs corporels et d'autres dispositifs IoT alimentés par batteries, les besoins en énergie des solutions Wi-Fi classiques ont rendu la connectivité Wi-Fi continue peu pratique, obligeant généralement les développeurs à faire des compromis sur certains aspects des fonctionnalités, des performances ou de la durée de vie des batteries du dispositif.

Bien que la conception d'une solution Wi-Fi personnalisée pour optimiser la basse consommation puisse être une option pour certaines équipes, cela peut s'avérer une entreprise coûteuse et longue, surtout compte tenu du manque de concepteurs RF qualifiés. Il faut une solution plus complète qui rende également le Wi-Fi continu pratique pour les dispositifs IoT basse consommation.

Cet article montre comment les développeurs peuvent mettre en œuvre une connectivité Wi-Fi continue en utilisant les fonctions basse consommation intégrées dans un système sur puce (SoC) sans fil de Dialog Semiconductor.

Difficultés de la prise en charge de la connectivité Wi-Fi pour les dispositifs mobiles

Le Wi-Fi offre généralement la combinaison d'omniprésence et de caractéristiques de performances requise dans un large éventail d'applications IoT architecturées autour de produits mobiles personnels, de dispositifs de maison intelligente et de systèmes d'immotique, pour n'en citer que quelques-uns. Dans le passé, cependant, la consommation de courant relativement élevée des sous-systèmes Wi-Fi a obligé les développeurs à faire des compromis entre la durée de vie des batteries et la puissance du signal dans les dispositifs IoT alimentés par batteries.

Les exigences de puissance élevées des solutions Wi-Fi traditionnelles posent des défis supplémentaires aux développeurs IoT. Par exemple, les exigences en matière de connectivité Wi-Fi et de durée de vie étendue des batteries peuvent accroître la taille et la complexité de la conception pour permettre l'utilisation de batteries plus grandes. Pour les dispositifs corporels ou les nombreux dispositifs IoT pour lesquels des batteries plus grandes ne sont pas envisageables, il n'est pas toujours possible d'étendre la durée de vie des batteries en réduisant la force du signal Wi-Fi (et la consommation électrique associée).

Outre ces préoccupations, les développeurs IoT sont confrontés aux limites pratiques de l'environnement typique des signaux Wi-Fi, où la puissance du signal peut varier considérablement en raison des interférences à trajets multiples et d'autres caractéristiques de signaux radiofréquences (RF). Dans des applications telles que les ordinateurs portables, un consommateur peut simplement déplacer un ordinateur portable vers un autre endroit avec un meilleur signal Wi-Fi. En revanche, une serrure intelligente ou un appareil électroménager doit maintenir une connectivité fiable et des performances robustes, quel que soit l'endroit où il est installé.

Pour prendre en charge à la fois une durée de vie étendue des batteries et une haute puissance du signal Wi-Fi, les développeurs tirent généralement pleinement parti des modes de veille basse consommation disponibles dans la plupart des processeurs avancés, des radios et d'autres composants matériels complexes. En maximisant le temps que les dispositifs énergivores passent dans leurs modes basse consommation respectifs, les développeurs peuvent mettre en œuvre des conceptions qui étendent la durée de vie des batteries de leurs systèmes, généralement avec peu d'impact sur les fonctionnalités du système. Dans ces conceptions, un temporisateur basse consommation peut périodiquement activer brièvement le système pour lire les capteurs et transmettre sans fil les données des capteurs avant de repasser en mode veille.

Pour certaines applications IoT, cependant, le dispositif IoT doit maintenir une connexion continue au réseau Wi-Fi pour garantir une réponse rapide aux commandes de l'utilisateur, envoyées via des applications mobiles, des logiciels de bureau, ou même d'autres dispositifs. Par exemple, les serrures, les lampes et les interrupteurs intelligents que l'on trouve dans les maisons intelligentes doivent rester connectés pour fournir une réponse instantanée aux commandes de l'utilisateur. Attendre qu'un dispositif basé sur temporisateur s'active, détecte la commande et finalement déverrouille une porte ou allume une lumière serait tout simplement inacceptable pour les utilisateurs.

Le SoC DA16200 de Dialog Semiconductor et les modules associés fournissent une solution basse consommation efficace, capable de répondre à la fois aux exigences de connectivité Wi-Fi continue et de longue durée de vie des batteries.

Mise en œuvre de la connectivité Wi-Fi avec un SoC sans fil

Conçu spécifiquement pour les conceptions IoT alimentées par batteries, le SoC DA16200 combine un processeur Arm® Cortex®-M4F avec un sous-système radio Wi-Fi complet exécutant une pile réseau complète, éliminant ainsi le recours à un processeur réseau externe ou à un processeur hôte pour fournir la fonctionnalité de pile. Avec le sous-système radio, le dispositif intègre un ensemble complet de blocs fonctionnels et d'interfaces typiquement requis dans les conceptions IoT (Figure 1).

Figure 1 : Le SoC DA16200 de Dialog Semiconductor fournit une solution Wi-Fi complète capable de fournir une connectivité Wi-Fi continue tout en consommant un courant minimal. (Source de l'image : Dialog Semiconductor)

En plus de multiples interfaces standard, le dispositif inclut un convertisseur analogique-numérique (CAN) à registre d'approximations successives (SAR) 12 bits à 4 canaux pour prendre en charge l'acquisition de signaux analogiques.

Pour l'exécution de l'application, le DA16200 contient plusieurs mémoires internes, y compris :

• Mémoire en lecture seule pour un chargeur d'amorçage, le noyau système, la pile réseau et les pilotes.
• Mémoire vive statique (SRAM) pour les données de programme. Le code du programme est exécuté localement (Execute-in-Place (XIP)) sur la mémoire Flash série accessible via l'interface de mémoire Flash série externe du dispositif.
• Mémoire programmable une fois (OTP) utilisée pour stocker des informations sur le dispositif ainsi que des clés de cryptographie et un chargeur d'amorçage sécurisé. Les données OTP restent sécurisées car elles ne sont accessibles que via le contrôleur OTP et restent autrement invisibles pour l'accès normal aux données via le bus système.

Pour aider les développeurs à répondre à la demande croissante en matière de sécurité des dispositifs connectés, le SoC DA16200 intègre un large ensemble de mécanismes de sécurité, notamment un moteur de cryptographie pour AES (Advanced Encryption Standard), des algorithmes de hachage sécurisé (SHA) et d'autres types de chiffrages, ainsi que la prise en charge du protocole TLS (Transport Layer Security). Le dispositif inclut également la propriété intellectuelle (IP) de sécurité Arm TrustZone CryptoCell-312 (CC312). Conçu pour les dispositifs basse consommation, le CC312 prend en charge l'amorçage sécurisé et permet d'établir une racine de confiance pour les applications sécurisées.

Le dispositif simplifie la connectivité Wi-Fi grâce à un bloc RF complet. En plus des couches intégrées MAC 802.11 et PHY 802.11b/g/n, le sous-système radio inclut un émetteur-récepteur sur puce avec des amplificateurs de puissance (PA) et des amplificateurs à faible bruit (LNA) intégrés qui éliminent le recours à des composants actifs externes. En fonctionnement, le processeur Arm Cortex-M4F du DA16200 exécute une pile TCP/IP intégrée pour décharger les opérations de connectivité du processeur hôte d'un système.

Pour alimenter ses différents blocs, y compris le bloc RF, le SoC DA16200 intègre un convertisseur CC/CC, des régulateurs à faible chute de tension (LDO) et des commutateurs de puissance. Gérés par le bloc d'horloge temps réel (RTC) du dispositif, le convertisseur et les LDO génèrent tous les rails d'alimentation requis à partir d'une seule alimentation batterie VBAT. Tandis que le convertisseur CC/CC génère 1,4 volt (V) pour le bloc RF et le LDO numérique depuis VBAT, le LDO E/S génère les 1,8 V requis pour la mémoire Flash externe et l'E/S à usage général (GPIO) du dispositif (Figure 2).

Figure 2 : L'unité de gestion de l'alimentation du SoC DA16200 contrôle les composants d'alimentation intégrés du dispositif fournissant la tension à ses différents domaines d'alimentation. (Source de l'image : Dialog Semiconductor)

L'unité de gestion de l'alimentation du SoC DA16200 contrôle l'alimentation de ces domaines d'alimentation séparés dans le cadre de sa fonction de gestion des trois modes basse consommation (veille) du dispositif :

• Sleep 1 offre le fonctionnement à la plus basse consommation de 0,2 microampère (μA) : dans ce mode, le dispositif est largement désactivé mais se réactive en 150 millisecondes (ms) en réponse à un déclencheur externe délivré aux deux broches d'activation du SoC ou à l'une des nombreuses E/S numériques, ou lorsqu'un signal d'entrée analogique dépasse un seuil prédéfini.
• Sleep 2 ne consomme que 1,8 μA tout en maintenant la fonctionnalité RTC : dans ce mode, le SoC se réactive en moins de 100 ms en réponse à des événements d'activation externes ou à l'achèvement d'un temporisateur interne programmé.
• Sleep 3 fournit un mode Wi-Fi unique connecté en continu qui peut consommer un courant minimal et se réactiver en moins de 2 ms lors de la détection de paquets de données Wi-Fi entrants : comme décrit ci-dessous, l'utilisation de Sleep 3 avec la fonctionnalité TCP keepalive conventionnelle fournit la base pour mettre en œuvre une capacité de connectivité Wi-Fi continue consommant un courant moyen de moins de 50 μA.

La technologie de gestion de l'alimentation dynamique permet une connectivité Wi-Fi continue

Derrière ces modes de veille basse consommation se trouve la technologie de gestion de l'alimentation dynamique (Dynamic Power Management, DPM), propriété de Dialog Semiconductor, qui coupe les micro-éléments inutilisés de la puce, minimisant ainsi la consommation d'énergie lorsque le dispositif ne transmet ou ne reçoit pas de données. Pendant les opérations Wi-Fi, la technologie DPM minimise la consommation d'énergie durant l'émission et la réception radio en utilisant des algorithmes avancés pour activer les micro-éléments nécessaires juste au moment où ils sont requis.

Le kit de développement logiciel (SDK) DA16200 de Dialog Semiconductor synthétise les détails de la gestion de l'alimentation et du fonctionnement DPM avec son interface de programmation (API) DPM Manager. Pour le développement de logiciels personnalisés, le SDK donne accès à la pile logicielle DA16200 de services d'applications et de systèmes (Figure 3).

Figure 3 : L'architecture logicielle du SoC DA16200 fournit un ensemble complet de services de systèmes et d'applications requis pour prendre en charge la connectivité Wi-Fi standard dans les dispositifs IoT. (Source de l'image : Dialog Semiconductor)

La mise en œuvre d'une connectivité Wi-Fi continue combine l'utilisation du DPM Manager et de la bibliothèque TCP/IP NetX Duo. La bibliothèque NetX Duo offre une fonction TCP keepalive qui envoie un paquet TCP sans données à un routeur Wi-Fi, garantissant que le routeur maintient la connexion Wi-Fi active. Les développeurs invoquent cette fonctionnalité simplement en définissant l'option de socket TCP actuelle, keepalive_enabled, sur true, et fournissent le nombre de secondes, keepalive_timeout, entre les paquets keepalive. NetX Duo transmet automatiquement les trames keepalive selon les besoins.

Alors que les paquets keepalive maintiennent la connexion réseau avec un routeur ou un autre hôte, la capacité du DA16200 à s'activer en mode Sleep 3 repose sur la détection des éléments d'information TIM (Traffic Indication Map) standard ou DTIM (Delivery Traffic Indication Map) embarqués dans des trames de gestion 802.11, et est utilisée pour notifier aux stations réseau, comme un système basé sur le DA16200, que du trafic réseau est disponible pour lui. Lorsque le DA16200 est placé en mode Sleep 3, la technologie DPM du DA16200 garantit que le sous-système radio utilise une puissance minimale pour rechercher les éléments TIM/DTIM. Lorsque le sous-système radio DA16200 détecte des éléments TIM/DTIM, il active le SoC pour qu'il commence à traiter le trafic Wi-Fi normal, comme toute station réseau.

Grâce à l'API DA16200 DPM Manager, les développeurs n'ont qu'à programmer quelques appels intuitifs pour implémenter cette fonctionnalité. Après avoir défini la configuration DPM requise, y compris les paramètres et les rappels, les développeurs utilisent les appels de fonction API DPM Manager pour invoquer et interagir avec le DPM Manager. L'entrée et la sortie du mode Sleep 3 sont gérées de manière transparente par la technologie DPM DA16200.

Les exemples d'applications inclus dans le SDK illustrent les modèles de conception de base requis pour implémenter cette séquence d'opérations (Liste 1).

Copier
#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 : En utilisant le SoC DA16200, les développeurs peuvent implémenter une connectivité Wi-Fi continue en utilisant des configurations et quelques appels de fonction API DPM. (Source du code : Dialog Semiconductor)

Comme le montre la Liste 1, les développeurs implémentent cette capacité en utilisant principalement une fonction d'initialisation (tcp_client_ka_dpm_sample_init_user_config()) qui définit divers paramètres de configuration, y compris l'intervalle keepalive (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT), et fournit divers rappels, y compris pour l'activation DPM (tcp_client_ka_dpm_sample_wakeup_callback()) et pour le traitement des paquets de données entrants (tcp_client_ka_dpm_sample_recv_callback()). Pour lancer la séquence TCP keepalive et d'activation DPM, une fonction distincte (tcp_client_ka_dpm_sample()) invoque simplement une routine de configuration (dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config)) et le DPM Manager (dpm_mng_start()).

Comme mentionné précédemment, cette séquence complète, y compris les paquets TCP keepalive standard et la surveillance Wi-Fi activée par le DA16200 DPM, résulte en une capacité de connectivité Wi-Fi continue qui consomme généralement un courant moyen inférieur à 50 μA.

Ce même modèle de conception peut être utilisé pour sortir le SoC de ses modes de veille afin de gérer d'autres opérations. Une application d'exemple montre l'utilisation de l'horloge RTC du DA16200 pour activer le SoC et traiter des données (Liste 2).

Copier
#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 : Les développeurs peuvent implémenter une fonctionnalité basée sur un temporisateur basse consommation avec le DA16200 en utilisant quelques appels de fonction API DPM pour garantir une consommation d'énergie minimale pendant les périodes de veille du DA16200. (Source du code : Dialog Semiconductor)

Comme indiqué dans la Liste 2, le développeur appelle une fonction API DPM Manager (dpm_timer_create()) pour créer un temporisateur (SAMPLE_RTC_TIMER) et une autre fonction API DPM Manager (dpm_app_sleep_ready_set()) pour indiquer que le système est prêt à repasser en veille. Le moteur DPM détermine alors à quelle vitesse le système peut repasser en mode veille basse consommation en fonction de l'activité en cours. Par la suite, lorsque le temporisateur expire, le système exécute la fonction de rappel du développeur, rtc_timer_dpm_periodic_cb(), qui effectue les opérations requises — dans ce cas, la simple impression d'une notification à la console. Lorsque l'opération est terminée, la même fonction de rappel exécute la fonction dpm_app_sleep_ready_set() pour notifier le moteur DPM que le système est prêt à repasser en veille. Comme auparavant, le moteur DPM effectue la transition vers le mode veille lorsque cela est approprié.

Les modules drop-in simplifient la conception Wi-Fi

Tandis que le SDK DA16200 simplifie la conception logicielle, la fonctionnalité intégrée étendue du dispositif se traduit par une conception d'interface matérielle relativement simple. En utilisant le SoC DA16200 avec un dispositif Flash externe, tel que le circuit intégré de mémoire NOR 16 mégabits (Mb) W25Q16JVSNIQ de Winbond Electronics et seulement quelques composants supplémentaires, les développeurs peuvent implémenter une conception IoT sécurisée compatible Wi-Fi (Figure 4).

Figure 4 : Grâce à ses nombreuses fonctionnalités intégrées, le SoC DA16200 de Dialog Semiconductor ne nécessite qu'une mémoire Flash série externe et un nombre minimum de composants supplémentaires pour implémenter un système Wi-Fi complet. (Source de l'image : Dialog Semiconductor)

Les développeurs qui cherchent à accélérer le développement de leurs propres conceptions basées sur le SoC DA16200 peuvent se tourner vers les modules de Dialog Semiconductor qui leur permettent d'éliminer l'implémentation de l'interface matérielle du SoC. Avec le SoC DA16200, les modules incluent 4 méga-octets (Mo) de Flash, des composants RF et le choix entre une antenne monopuce intégrée (DA16200MOD-AAC4WA32) ou un connecteur u.FL pour une antenne externe (DA16200MOD-AAE4WA32). Entièrement certifiés FCC, IC, CE et par d'autres organismes de réglementation, les modules de 13,8 millimètres (mm) x 22,1 mm x 3,3 mm offrent une solution matérielle immédiate pour la mise en œuvre d'une connectivité Wi-Fi continue basse consommation.

Les développeurs qui souhaitent explorer la connectivité Wi-Fi continue et prototyper rapidement des conceptions IoT basées sur le SoC DA16200 peuvent tirer immédiatement parti du kit de développement DA16200MOD-DEVKT de Dialog Semiconductor. Ce kit combine un module DA16200MOD avec une interface USB, des clés et des connexions pour aider à accélérer le développement et le débogage des conceptions basées sur le DA16200.

Conclusion

La capacité à maintenir une connectivité Wi-Fi continue est une caractéristique de routine des ordinateurs portables et d'autres produits connectés. Cependant, pour les dispositifs corporels et les dispositifs IoT alimentés par batteries, les besoins en énergie des solutions Wi-Fi classiques ont rendu la connectivité Wi-Fi continue peu pratique, de sorte que les concepteurs doivent généralement faire des compromis sur certains aspects des fonctionnalités, des performances ou de la durée de vie des batteries.

Un SoC de Dialog Semiconductor offre une solution Wi-Fi complète capable de fournir une connectivité Wi-Fi continue tout en consommant un courant minimal. Comme illustré, avec le SoC ou ses modules associés, les développeurs peuvent rapidement mettre en œuvre des dispositifs alimentés par batteries sécurisés, capables de fournir aux utilisateurs les avantages d'une connectivité Wi-Fi continue tout en répondant à leurs attentes en matière de durée de vie étendue des batteries.