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

Por Stephen Evanczuk

Colaboración de Editores de Digi-Key de América del Norte

La demanda de productos conectados inteligentes ofrece amplias oportunidades a los desarrolladores que son capaces de convertir rápidamente los conceptos en aplicaciones de la Internet de las cosas (IoT) que funcionan. La disponibilidad de procesadores de bajo consumo, opciones de conectividad inalámbrica y una amplia gama de periféricos de hardware ofrece una base sólida para implementar diseños adecuados de bajo consumo y listos para la producción.

Sin embargo, en la fase inicial de definición del producto, los desarrolladores necesitan una plataforma de desarrollo flexible para construir prototipos rápidos basados en la misma clase de procesadores, subsistemas de conectividad y periféricos. La capacidad de construir rápidamente prototipos que funcionen y de añadir fácilmente funcionalidades es esencial para proporcionar pruebas tempranas de concepto y para apoyar el desarrollo de software a medida.

Este artículo muestra cómo los desarrolladores pueden utilizar el hardware y el software de Silicon Labs para construir rápidamente prototipos de dispositivos IoT conectados especializados y eficientes desde el punto de vista energético, utilizando una amplia selección de placas complementarias disponibles en el mercado.

Permitir la creación rápida de prototipos

A la hora de explorar nuevas posibilidades para los dispositivos inalámbricos del IoT alimentados por batería, los desarrolladores pueden verse atascados por los numerosos detalles que conlleva la creación de una plataforma de desarrollo que funcione. Con sus subsistemas integrados, los dispositivos avanzados de sistema en chip (SoC) pueden proporcionar el núcleo de una plataforma de este tipo, pero los desarrolladores siguen necesitando construir un sistema completo a su alrededor.

Para crear una plataforma de desarrollo adecuada para estos dispositivos, los desarrolladores no solo tienen que cumplir los requisitos fundamentales de un rendimiento sólido y una mayor duración de la batería, sino que también tienen que incorporar la flexibilidad necesaria para satisfacer los requisitos específicos de cada aplicación. El kit explorador BGM220-EK4314A de Silicon Labs satisface esta combinación de necesidades, permitiendo a los desarrolladores centrarse en la rápida creación de prototipos de nuevos conceptos de diseño en lugar de ocuparse de los detalles que conlleva la construcción de su propia plataforma de desarrollo.

Plataforma flexible de desarrollo rápido

Ofreciendo una plataforma de bajo costo para el 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-Link integrado, un pulsador, un diodo emisor de luz (LED) y múltiples opciones de expansión (Figura 1).

Imagen del kit BGM220-EK4314A Explorer de SiLabsFigura 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 localización inferior a un metro, todo ello necesario en una creciente gama de aplicaciones Bluetooth populares, como etiquetas de seguimiento de activos, cerraduras de puertas inteligentes, fitness, etc.

El módulo BGM220P, capaz de funcionar como sistema autónomo, combina el SoC EFR32BG22 con 512 Kbytes de memoria flash, 32 Kbytes de memoria de acceso aleatorio (RAM), cristales de alta frecuencia (HF) y baja frecuencia (LF) (XTAL), y una red de adaptación de 2.4 gigahercios (GHz) y una antena cerámica para la conectividad inalámbrica (Figura 2).

Diagrama del módulo BGM220P de SiLabsFigura 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)

Además de su capacidad de servir como host independiente para diseños IoT de tamaño reducido, el módulo también puede servir como coprocesador de red (NCP) para un procesador host conectado a través de 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 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 32 bits, una radio de 2.4 GHz, seguridad, subsistemas de gestión de la energía y múltiples temporizadores y opciones de interfaz. El SoC EFR32BG22, diseñado específicamente para diseños de consumo ultrabajo y alimentados por batería, utiliza múltiples funciones de gestión de la energía que pueden permitir el funcionamiento de la batería de botón hasta diez años.

Al funcionar con una única fuente de tensión externa, el SoC utiliza su unidad interna de gestión de la energía para generar tensiones de alimentación internas. Durante el funcionamiento, la unidad de gestión de la energía controla las transiciones entre los cinco modos de energía (EM) del SoC. Cada modo reduce aún más el consumo de energía al mantener progresivamente menos bloques funcionales activos a medida que el SoC pasa del modo activo (EM0) al modo de reposo (EM1), al modo de reposo profundo (EM2), al modo de parada (EM3) o al modo de apagado (EM4) (Figura 3).

Diagrama del SoC EFR32BG22 de Silicon Labs (haga clic para ampliar)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 76.8 MHz y 3 voltios, utilizando su convertidor CC/CC interno, el SoC consume 27 microamperios por megahercio (μA/MHz). EM0 es el modo de funcionamiento normal y es el único en el que el núcleo del procesador Cortex M33 y todos los bloques periféricos están disponibles.

Todos los periféricos están disponibles en modo de reposo (EM1), y son menos los que permanecen activos cuando el sistema entra en modos de consumo aún 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:

  • 17 μA/MHz en modo de espera (EM1)
  • Modo de inactividad profunda de 1.40 μA (EM2) con retención de RAM de 32 Kbytes y reloj en tiempo real (RTC) que funciona desde LFXO
  • Modo de parada de 1.05 μA (EM3) con retención de RAM de 8 Kbytes y RTC funcionando desde el oscilador de resistencia-condensador (RC) de 1 kilohercio (kHz) integrado en el SoC
  • 0.17 μA en modo de apagado (EM4)

Algunos dispositivos alimentados por pilas necesitan algo más que la capacidad de hacer funcionar el procesador en modos de funcionamiento de bajo consumo. Muchas aplicaciones compatibles con Bluetooth suelen presentar periodos prolongados de poca o ninguna actividad, pero requieren una capacidad de respuesta de baja latencia cuando se reanuda la actividad. De hecho, incluso si una aplicación tiene requisitos de latencia más indulgentes, un tiempo de activación lento desperdicia energía porque el procesador no realiza ningún trabajo útil mientras completa el proceso de activación y entra en el modo activo (o completa el proceso de entrar en un modo de menor energía desde un modo de mayor energía).

A medida que el tiempo entre periodos activos se reduce, el uso de un modo de reposo de bajo consumo puede incluso llegar a ser contraproducente cuando un tiempo lento de despertar o de entrada en el modo de alimentación utiliza más energía de la que se consumiría si el procesador permaneciera en un modo de mayor consumo durante el periodo inactivo. Como resultado, los desarrolladores que trabajan para optimizar la duración de la batería a veces mantienen un procesador en un modo de mayor potencia que el requerido por las necesidades de procesamiento de la aplicación.

Al utilizar un procesador con tiempos de activación y entrada más rápidos, los desarrolladores pueden aprovechar mejor los modos de menor consumo del procesador. En el EM1, el EFG32BG22 se activa en tres relojes/1.24 microsegundos (µs) y tiene un tiempo de entrada de 1.29 µs, que se eleva a 8.81 milisegundos (ms) y 9.96 µ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 alimentación del SoC EFG32BG22. (Fuente de la tabla: Silicon Labs)

El método utilizado para despertar al procesador cuando se reanuda la actividad también puede afectar significativamente a la duración de la batería. Aunque algunas aplicaciones -como las industriales- requieren que los sistemas utilicen el procesamiento por sondeo para garantizar una sincronización periódica estricta, muchas aplicaciones en áreas de consumo utilizan el procesamiento basado en eventos para responder a una actividad específica. El uso de métodos de sondeo para aplicaciones basadas en eventos, por ejemplo, puede erosionar significativamente la vida de la batería cuando el procesador se despierta repetidamente sin necesidad.

Del mismo modo que muchos diseños basados en sensores utilizan la función activación-interrupción para evitar despertar repetidamente al procesador solo para comprobar la actividad, una función activación-RF integrada en el subsistema de radio del SoC EFG32BG22 permite un enfoque similar basado en interrupciones. Esto permite a los desarrolladores mantener el procesador en un modo de energía de baja potencia hasta que se produzca la actividad de radiofrecuencia (RF).

En la práctica, los desarrolladores colocan el SoC inalámbrico EFG32BG22 en un modo EM2, EM3 o EM4 de muy bajo consumo y confían en la capacidad activación-RF para activar el SoC cuando se detecta energía de RF. Cuando simplemente se detecta energía por encima del umbral, la capacidad de RFSENSE consume 131 nanoamperios (nA). Un modo RFSENSE más selectivo consume un poco más de corriente, con 138 nA, pero en este modo, RFSENSE filtra las señales de RF entrantes para evitar que se despierte el ruido de RF en lugar de una señal de RF válida.

En algunos casos, el SoC EFG32BG22 puede no necesitar despertar el núcleo del procesador para responder a eventos externos: El sistema de reflejo de periféricos (PRS) de SiLabs permite que los periféricos respondan a eventos y funcionen sin despertar el núcleo del procesador. Los periféricos pueden comunicarse directamente entre sí y sus funciones pueden combinarse para ofrecer una funcionalidad compleja. Al utilizar las capacidades de PRS con modos de energía más bajos, los desarrolladores pueden reducir sustancialmente el consumo de energía sin comprometer la funcionalidad crítica, como la adquisición de datos de los sensores.

Depuración incorporada y fácil ampliación

Integrado en la placa BGM220 Explorer Kit, el módulo BGM220P aporta el conjunto completo de capacidades de gestión y procesamiento de energía del SoC EFR32BG22 a los diseños Bluetooth alimentados por batería. Cuando es necesario construir rápidamente prototipos para explorar nuevos conceptos de diseño, otras características de la placa ayudan a acelerar el desarrollo.

A través del conector USB Micro-B de la placa, un depurador SEGGER J-Link integrado permite la descarga y depuración de código, así como un puerto COM virtual para el acceso a la consola del host. El depurador también es compatible con la interfaz de rastreo de paquetes (PTI) de SiLabs para analizar los paquetes transmitidos o recibidos a través de una red inalámbrica.

Para la creación rápida de prototipos, la compatibilidad de la placa con múltiples opciones de expansión ofrece la flexibilidad necesaria para explorar nuevas ideas de diseño que necesiten diferentes combinaciones de sensores, actuadores, opciones de conectividad y otros periféricos. Aprovechando la amplia variedad de placas complementarias mikroBUS disponibles y el hardware Qwiic Connect System de múltiples proveedores, los desarrolladores pueden configurar rápidamente 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 a través de las interfaces I2C, SPI o UART. El conector Qwiic proporciona la interfaz I2C del sistema Qwiic para conectar una o más tarjetas Qwiic a distancias de hasta un metro y medio. Para las conexiones a mayores distancias, los desarrolladores pueden utilizar la tarjeta SparkFun QwiicBus EndPoint(COM-16988), que utiliza la señalización diferencial para mantener la integridad de la señal I2C a distancias de hasta unos 100 pies.

Desarrollo rápido de aplicaciones

SiLabs aplica el concepto de expansión rápida al desarrollo de software de aplicación. Junto con los paquetes de soporte de la placa, los controladores, las bibliotecas y las cabeceras para el desarrollo personalizado, la empresa ofrece varias aplicaciones de muestra incluidas en su entorno de desarrollo Simplicity Studio, así como proyectos adicionales disponibles en los repositorios GitHub de SiLabs. De hecho, los desarrolladores pueden empezar a explorar el desarrollo de aplicaciones de sensores con una aplicación de temperatura de muestra incluida que utiliza 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 a través de 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. Después de completar la inicialización, la aplicación se instala en un bucle sin fin para esperar eventos (Listado 1).

Copiar
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, cuando un temporizador fijado durante la inicialización cuenta hacia abajo, una rutina de devolución de llamada asociada realiza una medición de la temperatura. Después de que los desarrolladores creen la aplicación y flasheen la placa, pueden utilizar la aplicación EFR Connect de SiLabs, una aplicación móvil Bluetooth genérica que funciona con todos los kits y dispositivos Bluetooth de Silicon Labs. Además de proporcionar el marco de trabajo para las aplicaciones personalizadas, la aplicación ayuda al desarrollo proporcionando una vista de las características soportadas asociadas a un servicio Bluetooth, como el servicio de termómetro de salud Bluetooth utilizado en esta aplicación de ejemplo (Figura 4).

Imagen de la aplicación EFR Connect de SiLabsFigura 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 demuestran varios escenarios de uso, incluyendo diseños construidos con placas Qwiic o mikroBUS, por separado o en combinación. Por ejemplo, una aplicación de muestra que demuestra el uso de los servicios estándar de frecuencia cardíaca (HR) y oxímetro de pulso (SpO2) por Bluetooth en combinación con la placa MIKROE-4037 Heart Rate 2 Click mikroBUS de MikroElektronika, que contiene el biosensor MAX86161 de Maxim Integrated. El MAX86161 proporciona un subsistema completo de bajo consumo capaz de proporcionar mediciones precisas de FC y SpO2 a un procesador anfitrión conectado a través de su interfaz I2C. (Para más información sobre el uso del MAX86161, consulte Construir un verdadero audífono inalámbrico para fitness-Parte 1: Medición de la frecuencia cardíaca y la SpO2).

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

Diagrama de la aplicación HR/SpO2Figura 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)

Al igual que la aplicación de temperatura mencionada anteriormente, esta aplicación se basa 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 añade una llamada a una rutina, hrm_loop, en app_process_action. Esto resulta en una llamada a hrm_loop en cada pasada por el bucle sin fin de nivel superior mostrado anteriormente en el Listado 1. Además, se utiliza un temporizador de software para actualizar periódicamente los datos de FC y SpO2.

La rutina hrm_loop llama a su vez 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, a su vez, llama a un par de rutinas, maxm86161_hrm_frame_process y maxm86161_hrm_spo2_frame_process, que ejecutan algoritmos para validar y generar resultados de FC y SpO2, respectivamente. Los desarrolladores pueden ver los resultados junto con otras características del servicio utilizando la aplicación EFR Connect mencionada anteriormente.

Otro ejemplo de aplicación de software muestra cómo los desarrolladores pueden construir sobre una aplicación compleja como esta aplicación HR/SpO2 cuando amplían su plataforma de hardware. Utilizando la placa BGM220-EK4314A Explorer Kit y el ecosistema de software de SiLabs, construir sobre el hardware y el software existentes es relativamente sencillo. SiLabs demuestra este enfoque con una aplicación de ejemplo que añade una pantalla OLED a la plataforma de hardware/software utilizada para la aplicación HR/SpO2 anterior. En este ejemplo, una placa complementaria Qwiic con pantalla OLED de SparkFun(LCD-14532) se conecta al conector Qwiic de la placa, mientras que la placa complementaria MikroElektronika Heart Rate 2 Click permanece en su lugar desde la aplicación de ejemplo anterior HR/SpO2 (Figura 6).

Imagen de la placa BGM220-EK4314A Kit Explorador de Silicon Labs con pantalla OLEDFigura 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)

Aparte de la adición de un controlador y servicios de apoyo para la placa OLED, la aplicación de software sigue siendo en gran medida la misma para esta versión ampliada de la aplicación HR/SpO2. El temporizador de software mencionado anteriormente para la aplicación HR/SpO2 añade una llamada a la función hrm_update_display, que muestra los datos de HR y SpO2 (Listado 2).

Copiar
    /* 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;
Listado 2: Utilizando el kit y el ecosistema de software, los desarrolladores pueden añadir funcionalidad de visualización a una aplicación HR/SpO2 existente conectando una placa de visualización y realizando cambios mínimos en el software más allá de añadir 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 permite a los desarrolladores crear rápidamente aplicaciones de IoT que funcionan. Dado que tanto el hardware como el software pueden añadirse o eliminarse fácilmente, los desarrolladores pueden explorar más fácilmente nuevas soluciones de diseño y evaluar configuraciones alternativas.

Conclusión:

Los dispositivos IoT con batería y compatible con Bluetooth son el núcleo de las aplicaciones más populares y constituyen el elemento clave para satisfacer la continua demanda de mayor funcionalidad y vida útil. Para los desarrolladores, satisfacer estas demandas conflictivas de manera efectiva requiere la capacidad de explorar rápidamente nuevos diseños y evaluar conceptos de diseño alternativos. Utilizando un kit de desarrollo y el software asociado de Silicon Labs, los desarrolladores pueden construir rápidamente prototipos, añadiendo y eliminando hardware según sea necesario para satisfacer los requisitos específicos de la aplicación.

Descargo de responsabilidad: Las opiniones, creencias y puntos de vista expresados por los autores o participantes del foro de este sitio web no reflejan necesariamente las opiniones, las creencias y los puntos de vista de Digi-Key Electronics o de las políticas oficiales de Digi-Key Electronics.

Información sobre el autor

Stephen Evanczuk

Stephen Evanczuk tiene más de 20 años de experiencia escribiendo para y sobre la industria de electrónica en un amplio rango de temas, entre ellos hardware, software, sistemas y aplicaciones, que incluyen IoT. Se doctoróen neurociencias (redes neuronales) y trabajó en la industria aeroespacial en sistemas seguros con distribución masiva y métodos de aceleración de algoritmos. Actualmente, cuando no escribe artículos sobre tecnología e ingeniería, trabaja en aplicaciones de aprendizaje profundo sobre sistemas de reconocimiento y recomendaciones.

Información sobre la editorial

Editores de Digi-Key de América del Norte