Añade una conectividad Wi-Fi continua sin comprometer la vida de la batería

Ofreciendo un gran ancho de banda y ubicuidad, el Wi-Fi sigue siendo un requerimiento primario de conectividad para muchos dispositivos de Internet de las Cosas (IoT). Sin embargo, en el caso de los dispositivos vestibles y otros dispositivos de IoT alimentados por baterías, los requisitos de energía de las soluciones Wi-Fi convencionales han hecho que la conectividad Wi-Fi continua sea poco práctica, lo que normalmente requiere que los desarrolladores comprometan algún aspecto de la funcionalidad, el rendimiento o la duración de la batería del dispositivo.

Si bien el diseño de una solución Wi-Fi personalizada para optimizar la baja potencia puede ser una opción para algunos equipos, puede ser una tarea costosa y que requiere mucho tiempo, especialmente dada la escasez de diseñadores de RF calificados. Se requiere una solución más completa que también haga práctico el Wi-Fi continuo para los dispositivos de IoT de baja potencia.

Este artículo muestra cómo los desarrolladores pueden implementar una conectividad Wi-Fi continua utilizando las funciones de bajo consumo incorporadas en un dispositivo de sistema inalámbrico en el chip (SoC) de Dialog Semiconductor.

Los desafíos de apoyar la conectividad Wi-Fi para los dispositivos móviles

El Wi-Fi suele proporcionar la combinación de la presencia ubicua y las características de rendimiento que se requieren en una amplia gama de aplicaciones de IoT construidas en torno a productos móviles personales, dispositivos domésticos inteligentes y sistemas de automatización de edificios, por mencionar sólo algunos. Sin embargo, en el pasado, el consumo actual relativamente alto de los subsistemas Wi-Fi obligó a los desarrolladores a comprometer la vida útil de las baterías o la intensidad de la señal en los dispositivos de IoT alimentados por baterías.

Los altos requerimientos de energía de las soluciones tradicionales de Wi-Fi traen desafíos adicionales a los desarrolladores de IoT. Por ejemplo, los requisitos tanto para la conectividad Wi-Fi como para la prolongación de la vida útil de las baterías pueden aumentar el tamaño y la complejidad del diseño para acomodar baterías más grandes. En el caso de los dispositivos portátiles o de muchos dispositivos de IoT en los que las baterías de mayor tamaño no son una opción, los intentos de prolongar la vida de las baterías reduciendo la intensidad de la señal de Wi-Fi (y el consumo de energía asociado) podrían no ser factibles.

Junto con estas preocupaciones, los desarrolladores de IoT se enfrentan a las limitaciones prácticas del entorno típico de la señal Wi-Fi, en el que la intensidad de la señal puede variar significativamente debido a la interferencia de multitrayecto y otras características de la señal de radiofrecuencia (RF). En aplicaciones como los ordenadores portátiles, un consumidor puede simplemente mover un ordenador portátil a un lugar diferente con una mejor señal de Wi-Fi. Por el contrario, una cerradura inteligente o un electrodoméstico necesita mantener una conectividad fiable y un rendimiento resistente, independientemente de dónde se instale.

Para soportar tanto una mayor duración de la batería como una robusta potencia de la señal Wi-Fi, los desarrolladores suelen aprovechar al máximo los modos de suspensión de bajo consumo disponibles en la mayoría de los procesadores avanzados, radios y otros componentes de hardware complejos. Al maximizar la cantidad de tiempo que los dispositivos que consumen energía pasan en sus respectivos modos de bajo consumo, los desarrolladores pueden implementar diseños que prolonguen la vida de la batería de sus diseños de sistemas, normalmente con poco impacto en la funcionalidad del sistema. En estos diseños, un temporizador de baja potencia podría despertar periódicamente al sistema brevemente para leer los sensores y transmitir inalámbricamente los datos de los sensores antes de volver al modo de reposo.

Sin embargo, para algunas aplicaciones de IoT, el dispositivo de IoT necesita mantener una conexión continua con la red Wi-Fi para asegurar una respuesta rápida a los comandos del usuario emitidos a través de aplicaciones móviles, software de escritorio o incluso otros dispositivos. Por ejemplo, las cerraduras, luces e interruptores inteligentes que se encuentran en las casas inteligentes necesitan permanecer conectados para proporcionar una respuesta instantánea a los comandos del usuario. Esperar a que un dispositivo basado en un temporizador se despierte, detecte el comando y finalmente abra una puerta o encienda una luz sería simplemente inaceptable para los usuarios.

Los SoC DA16200 de Dialog Semiconductor y los módulos asociados proporcionan una solución eficaz de bajo consumo capaz de soportar los requisitos tanto de conectividad Wi-Fi continua como de una mayor duración de la batería.

Implementar la conectividad Wi-Fi con un SoC inalámbrico

Diseñado específicamente para diseños de IoT alimentados por pilas, el DA16200 SoC combina un Arm® Cortex®-M4F con un completo subsistema de radio Wi-Fi que funciona con una pila de red completa, eliminando la necesidad de un procesador de red externo o un procesador anfitrión para proporcionar la funcionalidad de la pila. Junto con el subsistema de radio, el dispositivo integra un conjunto completo de bloques funcionales e interfaces típicamente requeridos en los diseños de IoT (Figura 1).

Figura 1: El SoC DA16200 de Dialog Semiconductor proporciona una completa solución Wi-Fi capaz de ofrecer una conectividad Wi-Fi continua con un consumo mínimo de corriente. (Fuente de la imagen: Dialog Semiconductor)

Junto con múltiples interfaces estándar, el dispositivo incluye un convertidor analógico-digital (ADC) de registro de aproximación sucesiva (SAR) de 4 canales y 12 bits para apoyar la adquisición de señales analógicas.

Para la ejecución de la aplicación, el DA16200 contiene múltiples memorias internas, incluyendo:

• Memoria de sólo lectura para un cargador de arranque, el núcleo del sistema, la pila de red y los controladores.
• Memoria estática de acceso aleatorio (SRAM) para datos de programas. El código de programa se ejecuta en el lugar (XIP) en la memoria flash serial a la que se accede a través de la interfaz de la memoria flash serial externa del dispositivo.
• Memoria programable una sola vez (OTP) utilizada para almacenar información del dispositivo así como claves de criptografía y un cargador de arranque seguro. Los datos de la OTP permanecen seguros porque solo se puede acceder a ellos a través del controlador de la OTP y, por lo demás, permanecen invisibles para el acceso normal a los datos a través del bus del sistema.

Para ayudar a los desarrolladores a satisfacer la creciente demanda de seguridad de los dispositivos conectados, el SoC DA16200 integra un amplio conjunto de mecanismos de seguridad que incluyen un motor de criptografía para el Estándar de Cifrado Avanzado (AES), los Algoritmos Secure Hash (SHA) y otros cifrados, así como soporte para el protocolo de Seguridad de la Capa de Transporte (TLS). El dispositivo también incluye el Arm TrustZone CryptoCell-312 (CC312) de seguridad de la propiedad intelectual (IP). Diseñado para dispositivos de bajo consumo, el CC312 soporta un arranque seguro y permite una raíz de confianza para aplicaciones seguras.

El dispositivo simplifica la conectividad Wi-Fi gracias a un completo bloque de RF. Junto con las capas físicas 802.11 de control de acceso a los medios (MAC) y 802.11b/g/n incorporadas, el subsistema de radio incluye un transceptor en chip con amplificadores de potencia integrados (PAs) y amplificadores de bajo ruido (LNA) que eliminan la necesidad de componentes activos externos. En funcionamiento, el procesador Arm Cortex-M4F DA16200 ejecuta una pila de protocolo de control de transmisión/protocolo de Internet (TCP/IP) incorporado para descargar las operaciones de conectividad del procesador host de un sistema.

Para alimentar sus diversos bloques, incluido el de RF, el DA16200 SoC integra un convertidor CC-CC, reguladores de baja caída (LDO) e interruptores de potencia. Gestionado por el bloque de reloj en tiempo real del dispositivo (RTC), el convertidor y los LDO generan todos los rieles de suministro necesarios a partir de una sola batería VBAT. Mientras que el convertidor CC-CC genera 1.4 voltios para el bloque de RF y el LDO digital de VBAT, el LDO de E/S genera los 1.8 voltios necesarios para el flash externo y la E/S de propósito general del dispositivo (GPIO) (Figura 2).

Figura 2: La unidad de gestión de la energía de SoC DA16200 controla los componentes de energía integrados del dispositivo que suministran voltaje a sus dominios de energía separados. (Fuente de la imagen: Dialog Semiconductor)

La unidad de administración de energía del SoC DA16200 controla el suministro de estos dominios de energía separados como parte de su función en la administración de los tres modos de bajo consumo (sleep) del dispositivo:

• Sleep 1 ofrece el funcionamiento de menor potencia con 0,2 microamperios (μA): En este modo, el dispositivo se apaga en gran medida pero se despierta en menos de 150 milisegundos (ms) en respuesta a un disparador externo entregado a los dos pines de activación del SoC o a una de varias E/S digitales, o cuando una señal de entrada analógica supera un umbral predefinido.
• Sleep 2 consume solo 1.8 μA mientras mantiene la funcionalidad RTC: En este modo, el SoC se despierta en menos de 100 ms en respuesta a eventos externos de despertar o al completar un temporizador interno programado.
• Sleep 3 proporciona un modo único de conexión continua de Wi-Fi que puede consumir una corriente mínima y se activa en menos de 2 ms al detectar paquetes de datos Wi-Fi entrantes: Como se describe a continuación, el uso de Sleep 3 con la función convencional de mantenimiento de la vida del TCP proporciona la base para implementar una capacidad de conectividad Wi-Fi continua que consume menos de 50 μA de corriente promedio.

La tecnología de gestión dinámica de la energía permite una conectividad Wi-Fi continua.

Subyacente a estos modos de suspensión de baja potencia está la tecnología de Gestión dinámica de potencia (DPM), propiedad de Dialog Semiconductor, que apaga los microelementos no utilizados en el chip, lo que resulta en un consumo mínimo de energía cuando el dispositivo no está transmitiendo o recibiendo datos. Durante las operaciones de Wi-Fi, el DPM minimiza el consumo de energía durante las operaciones de transmisión y recepción de radio usando algoritmos avanzados para despertar los microelementos necesarios justo cuando se necesitan.

El kit de desarrollo de software DA16200 de Dialog Semiconductor (SDK) resume los detalles de la gestión de la energía y el funcionamiento del DPM con su interfaz de programación de aplicaciones (API) DPM Manager. Para el desarrollo de software personalizado, el SDK proporciona acceso a la pila de software DA16200 de servicios de aplicaciones y sistemas (Figura 3).

Figura 3: La arquitectura de software del SoC DA16200 proporciona un conjunto completo de servicios de sistemas y aplicaciones necesarios para soportar la conectividad Wi-Fi estándar en los dispositivos de IoT. (Fuente de la imagen: Dialog Semiconductor)

La implementación de la conectividad Wi-Fi continua combina el uso del DPM Manager y la biblioteca NetX Duo TCP/IP. La biblioteca de NetX Duo ofrece una función de "TCP keepalive" que envía un paquete TCP sin datos a un enrutador Wi-Fi, asegurando que el enrutador mantenga la conexión Wi-Fi activa. Los desarrolladores invocan esta característica simplemente estableciendo la opción de socket TCP actual, keepalive_enabled, a true, y proporcionan el número de segundos, keepalive_timeout, entre los paquetes de keepalive. El NetX Duo transmite automáticamente los marcos de "Keepalive" según sea necesario.

Mientras que los paquetes keepalive mantienen la conexión de red con un enrutador u otro host, la capacidad del DA16200 de activarse del modo Sleep 3 depende de la detección de los elementos de información estándar del Mapa de Indicación de Tráfico (TIM) o del Mapa de Indicación de Tráfico de Entrega (DTIM) incorporados en los marcos de gestión 802.11, y se utiliza para notificar a las estaciones de red, como un sistema basado en el DA16200, que el tráfico de red está disponible para él. Cuando el DA16200 se pone en modo Sleep 3, la tecnología DPM del DA16200 asegura que el subsistema de radio use la mínima energía buscando elementos TIM/DTIM. Cuando el subsistema de radio DA16200 detecta elementos TIM/DTIM, despierta al SoC para que empiece a procesar el tráfico Wi-Fi normal, como cualquier estación de la red.

Al usar la API del DPM Manager DA16200, los desarrolladores solo tienen que hacer unas pocas llamadas intuitivas para implementar esta funcionalidad. Después de definir la configuración de DPM requerida, incluyendo los parámetros y las llamadas, los desarrolladores utilizan las llamadas a la función de la API del DPM Manager para invocar e interactuar con el DPM Manager. La entrada y salida de Sleep 3 se maneja de forma transparente con la tecnología del DA16200 DPM.

Las aplicaciones de muestra incluidas en el SDK ilustran los patrones básicos de diseño necesarios para implementar esta secuencia de operaciones (Lista 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 ;
}

Listado 1: Con el Soc DA16200, los desarrolladores pueden implementar una conectividad Wi-Fi continua usando configuraciones y unas pocas llamadas a la función DPM API. (Fuente del código: Dialog Semiconductor)

Como se muestra en el Listado 1, los desarrolladores implementan esta capacidad en gran medida utilizando solo una función de inicialización (tcp_client_ka_dpm_sample_init_user_config()) que establece varios parámetros de configuración, incluido el intervalo de conservación (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT), y proporciona varias llamadas de retorno, incluyendo las de DMP wakeup (tcp_client_ka_dpm_sample_wakeup_callback()) y para el procesamiento de los paquetes de datos entrantes (tcp_client_ka_dpm_sample_recv_callback()). Para iniciar la secuencia de activación de TCP keepalive y DPM, una función separada (tcp_client_ka_dpm_sample()) simplemente invoca una rutina de configuración (dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config)) y el DMP Manager (dpm_mng_start()).

Como ya se ha mencionado, toda esta secuencia, incluidos los paquetes estándar de TCP keepalive y la supervisión Wi-Fi habilitada por DA16200 DPM, da como resultado una capacidad de conectividad Wi-Fi continua que normalmente consume menos de 50 μA de corriente media.

Este mismo patrón de diseño puede ser usado para activar al SoC de sus modos de sueño para manejar otras operaciones. Por ejemplo, una aplicación de muestra indica el uso del RTC del DA16200 para activar al SoC para procesar datos (Lista 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);
    }
}

Listado 2: Los desarrolladores pueden implementar la funcionalidad basada en el temporizador de bajo consumo con el DA16200 utilizando unas pocas llamadas a la función API de DPM para asegurar un consumo mínimo de energía durante los períodos de suspensión del DA16200. (Fuente del código: Dialog Semiconductor)

Como se muestra en el Listado 2, el desarrollador llama a una función de la API del DPM Manager (dpm_timer_create()) para crear un temporizador (SAMPLE_RTC_TIMER) y otra función de la API del DPM Manager (dpm_app_sleep_ready_set()) para indicar que el sistema está listo para volver a dormir. El motor DPM determinará entonces la rapidez con la que el sistema puede volver al modo de reposo de baja potencia en función de la actividad actual. Más tarde, cuando el temporizador se agota, el sistema ejecuta la función de devolución de llamada del desarrollador, rtc_timer_dpm_periodic_cb(), que realiza las operaciones necesarias, en este caso, simplemente imprimiendo una notificación a la consola. Cuando la operación se ha completado, la misma función de devolución de llamada realiza el dpm_app_sleep_ready_set() para notificar al motor DPM que el sistema está listo para volver a dormir. Como antes, el motor DPM completa la transición al modo de suspensión cuando es apropiado.

Los módulos desplegables simplifican el diseño del Wi-Fi

Mientras que el SDK DA16200 simplifica el diseño del software, la amplia funcionalidad del dispositivo en el chip se traduce en un diseño de interfaz de hardware relativamente simple. Al usar el SoC DA16200 junto con un dispositivo flash externo, como el CI de la memoria NORW25Q16JVSNIQ de Winbond Electronics de 16 megabit (Mbit) y solo unos pocos componentes adicionales, los desarrolladores pueden implementar un diseño de IoT seguro habilitado para Wi-Fi- (Figura 4).

Figura 4: Con su amplia funcionalidad integrada, el SoC DA16200 de Dialog Semiconductor solo requiere un flash externo de serie y un mínimo de componentes adicionales para implementar un sistema Wi-Fi completo. (Fuente de la imagen: Dialog Semiconductor)

Los desarrolladores que buscan acelerar el desarrollo de sus propios diseños basados en el SoC DA16200 pueden recurrir a los módulos Dialog Semiconductor que eliminan la necesidad de implementar la interfaz de hardware del SoC. Junto con el SoC DA16200, los módulos incluyen 4 megabytes (Mbytes) de flash, componentes de RF y la elección de una antena chip incorporada (DA16200MOD-AAE4WA32) o un conector u.FL para una antena externa (DA16200MOD-AAE4WA32). Completamente certificados por la FCC, IC, CE y otros organismos reguladores, los módulos de 13.8 x 22.1 x 3.3 milímetros (mm) proporcionan una solución de hardware directa para implementar una conectividad Wi-Fi continua de baja potencia.

Los desarrolladores que buscan explorar la conectividad Wi-Fi continua y rápidamente prototipar diseños de IoT basados en el SoC DA16200 pueden aprovechar inmediatamente el kit de desarrollo DA16200MOD-DEVKT de Dialog Semiconductor. Este kit combina un módulo DA16200MOD con una interfaz USB, llaves y conexiones para ayudar a acelerar el desarrollo y la depuración de los diseños basados en DA16200.

Conclusión:

La capacidad de mantener una conectividad Wi-Fi continua es una característica rutinaria de las computadoras portátiles y otros productos conectados. Sin embargo, en el caso de los dispositivos portátiles y otros dispositivos de IoT alimentados por batería, los requisitos de energía de las soluciones Wi-Fi convencionales han hecho que la conectividad Wi-Fi continua sea poco práctica, lo que normalmente requiere que los desarrolladores comprometan algún aspecto de la funcionalidad, el rendimiento o la duración de la batería del dispositivo.

Un SoC de Dialog Semiconductor proporciona una completa solución Wi-Fi capaz de ofrecer una conectividad Wi-Fi continua mientras se consume una corriente mínima. Como se muestra, utilizando el SoC o sus módulos asociados, los desarrolladores pueden implementar rápidamente dispositivos seguros alimentados por batería capaces de proporcionar a los usuarios las ventajas de la conectividad Wi-Fi continua y, al mismo tiempo, satisfacer sus expectativas de una mayor duración de la batería.