Inicio Artículos Prototipos rápidos de aplicaciones IoT por Bluetooth con un kit de desarrollo...

Prototipos rápidos de aplicaciones IoT por Bluetooth con un kit de desarrollo y placas complementarias estándar

digikey
digikey

La demanda de productos conectados inteligentes ofrece extensas ocasiones a los desarrolladores que son capaces de transformar de manera rápida los conceptos en aplicaciones de la Internet de las cosas (IoT) que marchan. La disponibilidad de procesadores de bajo consumo, opciones de conectividad inalámbrica y una extensa gama de periféricos de hardware ofrece una base sólida para incorporar diseños convenientes de bajo consumo y listos para la producción.

No obstante, en la primera fase de definición del producto, los desarrolladores precisan una plataforma de desarrollo flexible para edificar prototipos veloces basados en exactamente la misma clase de procesadores, subsistemas de conectividad y periféricos. La capacidad de edificar de forma rápida prototipos que funcionen y de incorporar sencillamente funcionalidades es esencial para otorgar pruebas tempranas de término y para respaldar el desarrollo de software a la medida.

Este artículo muestra de qué forma los desarrolladores pueden emplear el hardware y el software de Silicon Labs para edificar de forma rápida prototipos de dispositivos IoT conectados especializados y eficaces desde el punto de vista energético, usando una extensa selección de placas complementarias libres en el mercado.

Permitir la creación veloz de prototipos

En el momento de explorar nuevas posibilidades para los dispositivos inalámbricos del IoT alimentados por batería, los desarrolladores pueden verse bloqueados por los abundantes detalles que acarrea la creación de una plataforma de desarrollo que funcione. Con sus subsistemas integrados, los dispositivos avanzados de sistema en chip (SoC) pueden administrar el núcleo de una plataforma de esta clase, mas los desarrolladores prosiguen necesitando edificar un sistema completo a su alrededor.

Para crear una plataforma de desarrollo conveniente para estos dispositivos, los desarrolladores no solo deben cumplir los requisitos esenciales de un desempeño sólido y una mayor duración de la batería, sino asimismo deben añadir la flexibilidad precisa para satisfacer los requisitos concretos de cada aplicación. El kit explorador BGM220-EK4314A de Silicon Labs satisface esta combinación de necesidades, dejando a los desarrolladores centrarse en la veloz creación de prototipos de nuevos conceptos de diseño en vez de encargarse de los detalles que acarrea la construcción de su plataforma de desarrollo.

Plataforma flexible de desarrollo veloz

Ofertando una plataforma de bajo costo de cara al desarrollo de aplicaciones basadas en Bluetooth, el Kit BGM220-EK4314A Explorer combina el módulo BGM220P Wireless Gecko de SiLabs(BGM220PC22HNA), un depurador SEGGER J-Enlace integrado, un pulsador, un diodo transmisor de luz (led) y múltiples opciones de expansión (Figura 1).

aplicaciones iot
Figura 1: El kit BGM220-EK4314A Explorer de SiLabs ofrece la combinación de rendimiento de procesamiento, gestión de la energía y flexibilidad de configuración necesaria para construir rápidamente prototipos y evaluar diferentes configuraciones de hardware periférico. (Fuente de la imagen: Silicon Labs)

El módulo BGM220P es una solución completa para pequeños dispositivos IoT alimentados por batería. Su SoC integrado EFR32BG22 Blue Gecko presenta un consumo de energía ultrabajo, capacidades de ángulo de llegada (AoA) y ángulo de salida (AoD) de Bluetooth, y una precisión de ubicación inferior a un metro, todo ello preciso en una creciente gama de aplicaciones Bluetooth populares, como etiquetas de seguimiento de activos, cerraduras de puertas inteligentes, fitness, etcétera

El módulo BGM220P, capaz de marchar como sistema autónomo, combina el SoC EFR32BG22 con quinientos doce Kbytes de memoria flash, treinta y dos Kbytes de memoria de acceso azaroso (RAM), cristales de alta frecuencia (HF) y baja frecuencia (LF) (XTAL), y una red de adaptación de dos.4 gigahercios (GHz) y una antena porcelana para la conectividad inalámbrica (Figura dos).

dispositivo con bluetooth
Figura 2: Capaz de servir como sistema independiente, el módulo BGM220P de SiLabs combina el SoC EFR32BG22 Blue Gecko con los componentes adicionales necesarios para implementar un dispositivo con Bluetooth. (Fuente de la imagen: Silicon Labs)

Aparte de su capacidad de servir como host independiente para diseños IoT de tamaño reducido, el módulo asimismo puede servir como coprocesador de red (NCP) para un procesador host conectado mediante la interfaz UART del módulo. Su pila Bluetooth integrada ejecuta servicios inalámbricos para las aplicaciones que se ejecutan en el módulo en diseños independientes, o bien procesa los comandos recibidos desde el host cuando se ejecuta en diseños NCP.

SoC inalámbrico de bajo consumo

El SoC inalámbrico Bluetooth EFR32BG22 del módulo BGM220P integra un núcleo Arm Cortex-M33 de treinta y dos bits, una radio de veinticuatro GHz, seguridad, subsistemas de administración de la energía y múltiples temporizadores y opciones de interfaz. El SoC EFR32BG22, desarrollado particularmente para diseños de consumo ultrabajo y alimentados por batería, usa múltiples funciones de administración de la energía que pueden permitir el funcionamiento de la batería de botón hasta diez años.

Al marchar con una sola fuente de tensión externa, el SoC usa su unidad interna de administración de la energía para producir tensiones de nutrición internas. A lo largo del funcionamiento, la unidad de administración de la energía controla las transiciones entre los 5 modos de energía (EM) del SoC. Cada modo reduce todavía más el consumo de energía al sostener progresivamente menos bloques funcionales activos conforme el SoC pasa del modo activo (EM0) al modo de reposo (EM1), al modo de reposo profundo (EM2), al modo de parada (EM3) o bien al modo de apagado (EM4) (Figura tres).

gestion de energia
Figura 3: La unidad de gestión de energía del SoC EFR32BG22 controla las transiciones entre los modos de energía EM0, EM1, EM2, EM3 y EM4 (código de colores en la parte inferior de la imagen). (Fuente de la imagen: Silicon Labs)

En modo activo (EM0) a setecientos sesenta y ocho MHz y tres voltios, usando su convertidor CC/CC interno, el SoC consume veintisiete micro amperios por megahercio (μA/MHz). EM0 es el modo perfecto de funcionamiento normal y es el único en el que el núcleo del procesador Cortex M33 y todos y cada uno de los bloques periféricos están libres.

Todos y cada uno de los periféricos están libres en modo de reposo (EM1), y son menos los que continúan activos cuando el sistema entra en modos de consumo todavía más bajos. En sus modos de bajo consumo, la reducción de los relojes activos y de los bloques funcionales se traduce en niveles de consumo significativamente menores:

  • diecisiete μA/MHz en modo de espera (EM1)
  • Modo de inactividad profunda de ciento cuarenta μA (EM2) con retención de RAM de treinta y dos Kbytes y reloj en tiempo real (RTC) que marcha desde LFXO
  • Modo de parada de ciento cinco μA (EM3) con retención de RAM de ocho Kbytes y RTC marchando desde el oscilador de resistencia-condensador (RC) de 1 kilohercio (kHz) integrado en el SoC
  • 0.17 μA en modo de apagado (EM4)
    Ciertos dispositivos alimentados por pilas precisan algo más que la capacidad de hacer marchar el procesador en modos de funcionamiento de bajo consumo. Muchas aplicaciones compatibles con Bluetooth acostumbran a presentar periodos prolongados de poca o bien ninguna actividad, mas requieren una capacidad de contestación de baja latencia cuando se reinicia la actividad. En verdad, aun si una aplicación tiene requisitos de latencia más clementes, un tiempo de activación lento desaprovecha energía por el hecho de que el procesador no efectúa ningún trabajo útil mientras que completa el proceso de activación y entra en el modo perfecto activo (o bien completa el proceso de entrar en un modo de menor energía desde un modo de mayor energía).

Conforme el tiempo entre periodos activos se reduce, el empleo de una manera de reposo de bajo consumo puede aun llegar a ser contraproducente en el momento en que un tiempo lento de despertar o bien de entrada en el modo perfecto de nutrición usa más energía de la que se consumiría si el procesador continuara en un modo de mayor consumo a lo largo del periodo inactivo. Como resultado, los desarrolladores que trabajan para optimar la duración de la batería en ocasiones sostienen un procesador en un modo de mayor potencia que el requerido por las necesidades de procesamiento de la aplicación.

Al emplear un procesador con tiempos de activación y entrada más veloces, los desarrolladores pueden aprovechar mejor los modos de menor consumo del procesador. En el EM1, el EFG32BG22 se activa en 3 relojes/1.24 microsegundos (µs) y tiene un tiempo de entrada de ciento veintinueve µs, que se eleva a ocho.81 milisegundos (ms) y novecientos noventa y seis µs, respectivamente, en el EM4 (Tabla 1).

Modo de energía Activación (ejecutar desde la RAM/Flash) Entrada (ejecutando desde Flash)
EM1 3 relojes/1.24 μs 1.29 μs
EM2 5.15/13.22 μs 5.23 μs
EM3 5.15/13.21 μs 5.23 μs
EM4 8.81 ms (solo Flash) 9.96 μs

Tabla 1: Tiempos de activación y entrada en modo de nutrición del SoC EFG32BG22. (Fuente de la tabla: Silicon Labs)

El procedimiento empleado para despertar al procesador cuando se reinicia la actividad asimismo puede afectar significativamente a la duración de la batería. Si bien ciertas aplicaciones -como las industriales- requieren que los sistemas usen el procesamiento por sondeo para asegurar una sincronización periódica rigurosa, muchas aplicaciones en áreas de consumo usan el procesamiento basado en acontecimientos para contestar a una actividad concreta. El empleo de métodos de sondeo para aplicaciones basadas en acontecimientos, por servirnos de un ejemplo, puede desgastar significativamente la vida de la batería cuando el procesador se lúcida reiteradamente sin necesidad.

De la misma forma que muchos diseños basados en sensores emplean la función activación-interrupción para eludir despertar reiteradamente al procesador solo para revisar la actividad, una función activación-RF integrada en el subsistema de radio del SoC EFG32BG22 deja un enfoque afín basado en interrupciones. Esto deja a los desarrolladores sostener el procesador en un modo de energía de baja potencia hasta el momento en que se genere la actividad de radiofrecuencia (RF).

En la práctica, los desarrolladores ponen el SoC inalámbrico EFG32BG22 en un modo EM2, EM3 o bien EM4 de bajísimo consumo y confían en la capacidad activación-RF para activar el SoC cuando se advierte energía de RF. Cuando sencillamente se advierte energía sobre el umbral, la capacidad de RFSENSE consume ciento treinta y uno nanoamperios (nA). Un modo RFSENSE más selectivo consume un tanto más de corriente, con ciento treinta y ocho nA, mas en este modo, RFSENSE filtra las señales de RF entrantes para eludir que se despierte el estruendos de RF en vez de una señal de RF válida.

En ciertos casos, el SoC EFG32BG22 puede no precisar despertar el núcleo del procesador para contestar a acontecimientos externos: El sistema de reflejo de periféricos (PRS) de SiLabs deja que los periféricos respondan a acontecimientos y funcionen sin despertar el núcleo del procesador. Los periféricos pueden comunicarse de manera directa entre sí y sus funciones pueden conjuntarse para ofrecer una funcionalidad compleja. Al usar las capacidades de PRS con modos de energía más bajos, los desarrolladores pueden reducir substancialmente el consumo de energía sin comprometer la funcionalidad crítica, como la adquisición de datos de los sensores.

Depuración incorporada y simple ampliación

Integrado en la placa BGM220 Explorer Kit, el módulo BGM220P aporta el conjunto completo de capacidades de administración y procesamiento de energía del SoC EFR32BG22 a los diseños Bluetooth alimentados por batería. Cuando es preciso edificar de forma rápida prototipos para explorar nuevos conceptos de diseño, otras peculiaridades de la placa asisten a apresurar el desarrollo.

A través del conector USB Micro-B de la placa, un depurador SEGGER J-Enlace integrado deja la descarga y depuración de código, como un puerto COM virtual para el acceso a la consola del host. El depurador asimismo es compatible con la interfaz de rastreo de bultos (PTI) de SiLabs para examinar los bultos trasmitidos o bien recibidos por medio de una red inalámbrica.

Para la creación veloz de prototipos, la compatibilidad de la placa con múltiples opciones de expansión ofrece la flexibilidad precisa para explorar nuevas ideas de diseño que precisen diferentes combinaciones de sensores, actuadores, opciones de conectividad y otros periféricos. Aprovechando la extensa pluralidad de placas complementarias mikroBUS libres y el hardware Qwiic Connect System de múltiples distribuidores, los desarrolladores pueden configurar de forma rápida una plataforma de desarrollo para cada aplicación.

Conectada al zócalo mikroBUS de la placa, una placa mikroBUS se conecta al módulo BGM220P mediante las interfaces I2C, SPI o bien UART. El conector Qwiic da la interfaz I2C del sistema Qwiic para conectar una o bien más tarjetas Qwiic a distancias de hasta un metro y medio. Para las conexiones a mayores distancias, los desarrolladores pueden emplear la tarjeta SparkFun QwiicBus EndPoint(COM-dieciseis mil novecientos ochenta y ocho), que emplea la señalización diferencial para sostener la integridad de la señal I2C a distancias de hasta unos cien pies.

Desarrollo veloz de aplicaciones

SiLabs aplica el término de expansión veloz al desarrollo de software de aplicación. Así como los bultos de soporte de la placa, los controladores, las bibliotecas y las cabeceras para el desarrollo adaptado, la compañía ofrece múltiples aplicaciones de muestra incluidas en su ambiente de desarrollo Simplicity Studio, como proyectos auxiliares libres en los repositorios GitHub de SiLabs. En verdad, los desarrolladores pueden comenzar a explorar el desarrollo de aplicaciones de sensores con una aplicación de temperatura de muestra incluida que emplea el sensor de temperatura interno del SoC EFR32BG22 como fuente de datos.

Construida en torno al servicio estándar Bluetooth Health Temperature, la aplicación de temperatura ofrece una demostración inmediata del flujo de procesamiento mediante una aplicación IoT genérica por Bluetooth construida sobre la arquitectura de software de SiLabs. La aplicación llama a una serie de rutinas de inicialización para los servicios del sistema y los servicios de la aplicación que configuran los manejadores de interrupción y las devoluciones de llamada. Tras llenar la inicialización, la aplicación se instala en un bucle sin fin para aguardar acontecimientos (Listado 1).

int main(void) {   // Initialize Silicon Labs device, system, service(s) and protocol stack(s).   // Note that if the kernel is present, processing task(s) will be created by   // this call.   sl_system_init();   // Initialize the application. For example, create periodic timer(s) or   // task(s) if the kernel is present.   app_init(); #if defined(SL_CATALOG_KERNEL_PRESENT)   // Start the kernel. Task(s) created in app_init() will start running.   sl_system_kernel_start(); #else // SL_CATALOG_KERNEL_PRESENT   while (1) {     // Do not remove this call: Silicon Labs components process action routine     // must be called from the super loop.     sl_system_process_action();     // Application process.     app_process_action(); #if defined(SL_CATALOG_POWER_MANAGER_PRESENT)     // Let the CPU go to sleep if the system allows it.     sl_power_manager_sleep(); #endif   } #endif // SL_CATALOG_KERNEL_PRESENT }

Listado 1: Las aplicaciones de ejemplo de Bluetooth de SiLabs utilizan un marco de ejecución genérico en el que un bucle sin fin permite que los callbacks y los manejadores de eventos procesen las acciones del sistema y de la aplicación tras la inicialización. (Fuente del código: Silicon Labs)

En esta aplicación, en el momento en que un temporizador fijado a lo largo de la inicialización cuenta cara abajo, una rutina de devolución de llamada asociada efectúa una medición de la temperatura. Una vez que los desarrolladores creen la aplicación y flasheen la placa, pueden usar la aplicación EFR Connect de SiLabs, una aplicación móvil Bluetooth genérica que marcha con todos y cada uno de los kits y dispositivos Bluetooth de Silicon Labs. Aparte de administrar el marco de trabajo para las aplicaciones adaptadas, la aplicación ayuda al desarrollo dando una vista de las peculiaridades soportadas asociadas a un servicio Bluetooth, como el servicio de termómetro de salud Bluetooth usado en esta aplicación de ejemplo (Figura cuatro).

servicios bluetooth
Figura 4: La aplicación EFR Connect de SiLabs muestra las características de los servicios Bluetooth utilizados en una aplicación, lo que no sólo acelera el desarrollo de prototipos, sino que también proporciona un marco para el desarrollo de aplicaciones personalizadas. (Fuente de la imagen: Silicon Labs)

En Simplicity Studio, los desarrolladores pueden importar una serie de ejemplos de aplicaciones Bluetooth diferentes que prueban múltiples escenarios de empleo, incluyendo diseños construidos con placas Qwiic o bien mikroBUS, separadamente o bien en combinación. Por servirnos de un ejemplo, una aplicación de muestra que prueba el empleo de los servicios estándar de frecuencia cardiaca (HR) y oxímetro de pulso (SpO2) por Bluetooth en combinación con la placa MIKROE-cuatro mil treinta y siete Heart Rate dos Clic mikroBUS de MikroElektronika, que contiene el biosensor MAX86161 de Maxim Integrated. El MAX86161 da un subsistema completo de bajo consumo capaz de suministrar mediciones precisas de FC y SpO2 a un procesador anfitrión conectado mediante su interfaz I2C. (Para más información sobre el empleo del MAX86161, consulte Edificar un auténtico audífono inalámbrico para fitness-Parte 1: Medición de la frecuencia cardiaca y la SpO2).

Con su necesidad de un supervisor auxiliar y un algoritmo de procesamiento más exigente que en la aplicación de temperatura, esta aplicación da una demostración más compleja de la arquitectura de una aplicación de software para dispositivos IoT (Figura cinco).

desarrollo de prototipos
Figura 5: Los proyectos de ejemplo, como la aplicación HR/SpO2, ayudan a acelerar el desarrollo de prototipos, al tiempo que demuestran un flujo de proceso típico para aplicaciones de sensores Bluetooth de bajo consumo. (Fuente de la imagen: Silicon Labs)

De exactamente la misma forma que la aplicación de temperatura mentada previamente, esta aplicación se fundamenta en una serie de rutinas de inicialización para configurar el sistema y los servicios de la aplicación. Cuando la rutina app_process_action está vacía en la aplicación de temperatura, esta aplicación agrega una llamada a una rutina, hrm_loop, en app_process_action. Esto resulta en una llamada a hrm_loop en todos y cada pasada por el bucle sin fin de nivel superior mostrado previamente en el Listado 1. Además de esto, se usa un temporizador de software para actualizar periódicamente los datos de FC y SpO2.

La rutina hrm_loop llama por su parte a maxm86161_hrm_process, que extrae muestras de una cola mantenida por funciones de ayuda y las entrega a una rutina de proceso de muestras. Esto, por su parte, llama a dos rutinas, maxm86161_hrm_frame_process y maxm86161_hrm_spo2_frame_process, que ejecutan algoritmos para validar y producir resultados de FC y SpO2, respectivamente. Los desarrolladores pueden ver los resultados así como otras peculiaridades del servicio usando la aplicación EFR Connect citada previamente.

Otro ejemplo de aplicación de software muestra de qué manera los desarrolladores pueden edificar sobre una aplicación compleja como esta aplicación HR/SpO2 cuando amplían su plataforma de hardware. Usando la placa BGM220-EK4314A Explorer Kit y el ecosistema de software de SiLabs, edificar sobre el hardware y el software existentes es parcialmente fácil. SiLabs prueba este enfoque con una aplicación de ejemplo que agrega una pantalla OLED a la plataforma de hardware/software empleada para la aplicación HR/SpO2 precedente. En este caso de ejemplo, una placa complementaria Qwiic con pantalla OLED de SparkFun(LCD-catorce mil quinientos treinta y dos) se conecta al conector Qwiic de la placa, al paso que la placa complementaria MikroElektronika Heart Rate dos Clic continúa en su sitio desde la aplicación de ejemplo precedente HR/SpO2 (Figura seis).

desarrolladores
Figura 6: Los desarrolladores pueden añadir rápidamente funcionalidad a un diseño existente construido en la placa BGM220-EK4314A Explorer Kit – aquí añadiendo una pantalla OLED a un prototipo HR/SpO2 existente. (Fuente de la imagen: Silicon Labs)

Además de la adición de un supervisor y servicios de apoyo para la placa OLED, la aplicación de software prosigue siendo en buena medida exactamente la misma para esta versión ampliada de la aplicación HR/SpO2. El temporizador de software citado previamente para la aplicación HR/SpO2 agrega una llamada a la función hrm_update_display, que muestra los datos de HR y SpO2 (Listado dos).

Listado 2: Usando el kit y el ecosistema de software, los desarrolladores pueden agregar funcionalidad de visualización a una aplicación HR/SpO2 existente conectando una placa de visualización y efectuando cambios mínimos en el software alén de incorporar una llamada a la función, hrm_update_display, al manejador del temporizador del software de la aplicación existente. (Fuente del código: Silicon Labs)
Este enfoque extensible de hardware y software deja a los desarrolladores crear de forma rápida aplicaciones de IoT que marchan. Puesto que tanto el hardware como el software pueden añadirse o bien eliminarse de manera fácil, los desarrolladores pueden explorar más de manera fácil nuevas soluciones de diseño y valorar configuraciones opciones alternativas.

/* Software Timer event */     case sl_bt_evt_system_soft_timer_id:       /* Check which software timer handle is in question */       if (evt->data.evt_system_soft_timer.handle == HEART_RATE_TIMER) {         heart_rate_send_new_data(connection_handle);         break;       }         if (evt->data.evt_system_soft_timer.handle == PULSE_OXIMETER_TIMER) {         pulse_oximeter_send_new_data(connection_handle);         break;       }         if (evt->data.evt_system_soft_timer.handle == DISPLAY_TIMER) {         hrm_update_display();         break;       }       break;

Conclusión

Los dispositivos IoT con batería y compatible con Bluetooth son el núcleo de las aplicaciones más populares y forman el factor clave para satisfacer la continua demanda de mayor funcionalidad y vida útil. Para los desarrolladores, satisfacer estas demandas problemáticas de forma eficaz requiere la capacidad de explorar velozmente nuevos diseños y valorar conceptos de diseño alternativos. Usando un kit de desarrollo y el software asociado de Silicon Labs, los desarrolladores pueden edificar de forma rápida prototipos, agregando y suprimiendo hardware conforme sea preciso para satisfacer los requisitos concretos de la aplicación.