Tome la vía rápida hacia las redes de malla Bluetooth 5

Con la disponibilidad de la capacidad de redes de malla para Bluetooth 5, los desarrolladores pueden mejorar el alcance y la disponibilidad de red de los sistemas conectados de forma inalámbrica, como los dispositivos de IoT. Sin embargo, las redes de malla tienen niveles de complejidad entre el diseño de hardware inalámbrico de baja potencia y el desarrollo de software de redes de malla que pueden enredar rápidamente a los desarrolladores y poner en peligro la programación del proyecto.

A medida que surgen los teléfonos inteligentes habilitados con Bluetooth 5 y otras plataformas móviles, el tiempo se convierte en un factor crítico ya que los desarrolladores necesitarán responder rápidamente a una explosión esperada de demanda de capacidad de redes de malla Bluetooth en casi todos los segmentos y aplicaciones de la industria. En respuesta, los proveedores de software y silicio están introduciendo soluciones para simplificar y acelerar el proceso de desarrollo.

Este artículo describirá los fundamentos de las redes de malla Bluetooth y luego realizará un proceso de desarrollo mediante un dispositivo específico de la línea de módulo Bluetooth 5 compatible con malla de Silicon Labs. Con una solución Bluetooth 5 integrada, los desarrolladores pueden implementar rápidamente dispositivos conectados y aplicaciones capaces de aprovechar al máximo las redes de malla Bluetooth.

El artículo concluye con una descripción del paquete de desarrollo de software de malla Bluetooth de Silicon Labs, que incluye una vista detallada del modelo impulsado por eventos que se demuestra mediante el código de aplicación de malla de muestra.

La necesidad de una malla Bluetooth

La malla Bluetooth va más allá de la capacidad de conexión punto a punto de la tecnología Bluetooth tradicional. Al transmitir mensajes a través de dispositivos conectados vecinos, la malla Bluetooth amplía el alcance efectivo de los dispositivos de baja potencia más allá del alcance real proporcionado por la salida de potencia del transmisor y la sensibilidad del receptor. Lo que es más importante, la malla Bluetooth aprovecha la amplia familiaridad con las aplicaciones habilitadas con Bluetooth en teléfonos inteligentes y otros dispositivos móviles. Esto proporciona una progresión natural para aplicaciones conectadas de malla más sofisticadas.

Con soporte de malla, los desarrolladores que usan Bluetooth ahora tienen una poderosa habilidad para conectar fácilmente una gran cantidad de dispositivos para automatización doméstica, administración de edificios y una cantidad de aplicaciones de IoT.

Cómo funciona la malla Bluetooth

La malla Bluetooth usa un modelo de interacción conceptualmente simple entre nodos en una red (Figura 1). Los tipos de nodos especializados proporcionan capacidades adicionales necesarias para transmitir mensajes entre nodos, y extiende el alcance efectivo de una red que interactúa a través de un nodo proxy con un dispositivo móvil con Bluetooth.

Figura 1: Junto con los nodos periféricos básicos, una red de malla Bluetooth puede usar tipos de nodos especiales para pasar mensajes a otros nodos (transmisión), servir como caché (friend) para nodos de baja potencia o conectar la red (proxy) a un dispositivo móvil habilitado con Bluetooth. (Fuente de la imagen: Silicon Labs)

Otros tipos de nodos especializados abordan los requisitos de potencia reducida, mediante nodos friend para almacenar en caché los mensajes que los nodos de baja potencia sondean periódicamente entre los estados de reposo extendido. Incluso con esta funcionalidad adicional, los dispositivos de malla Bluetooth pueden, no obstante, usar servicios de perfil de atributo genérico (GATT) para conectarse con dispositivos heredados que utilizan versiones anteriores de Bluetooth. Por lo tanto, los dispositivos de malla pueden aprovechar al máximo las capacidades existentes de Bluetooth de baja energía (BLE), como las señales para generar mensajes específicos de área para teléfonos inteligentes, o para identificar las aplicaciones de administración de activos.

La malla Bluetooth también aborda las crecientes preocupaciones por la seguridad en las redes protegidas necesarias en la automatización de edificios u otras aplicaciones de IoT. A diferencia de BLE, donde la seguridad es opcional para proteger un solo dispositivo, la malla Bluetooth impone seguridad en un intento de proteger la red de malla como un todo.

El enfoque de Bluetooth para la seguridad de malla es particularmente interesante. Su esquema de seguridad introduce el concepto de separación de preocupaciones a redes de malla, con medidas de seguridad separadas para cada dispositivo, la red y la aplicación general. Una clave de dispositivo privado (DevKey) asociada a cada dispositivo proporciona seguridad para operaciones tales como la configuración y el aprovisionamiento que involucran a ese nodo solo. Cada dispositivo necesita una clave de red (NetKey) para comunicarse con otros nodos en una red o subred. Finalmente, las interacciones a nivel de aplicación, como enviar un mensaje para encender una luz, requieren una clave de aplicación (AppKey). Otras medidas de seguridad protegen contra amenazas comunes como ataques de intermediarios o de repetición. En combinación, los mecanismos de seguridad en la malla Bluetooth proporcionan una base fundamental de confianza necesaria para aplicaciones de IoT más sofisticadas.

Sin embargo, la implementación de una aplicación conectada a la malla Bluetooth presenta importantes dificultades para los desarrolladores. La mayoría de las aplicaciones que usan redes de malla se basan en dispositivos de potencia limitada, al contar con la red de malla para extender el alcance efectivo de los subsistemas de radio de baja potencia. Los desafíos involucrados en la creación de dispositivos de hardware de baja potencia para malla adecuados pueden detener incluso al desarrollador de hardware más experimentado. Incluso después de completar sus diseños personalizados de Bluetooth, los desarrolladores pueden enfrentar costos significativos y retrasos prolongados en el cumplimiento de los requisitos de certificación nacional. Los desarrolladores de software se enfrentan a sus propios retrasos para encontrar pilas de malla Bluetooth compatibles y usarlas para crear niveles de software capaces de soportar sus propias aplicaciones. Sin embargo, con el hardware y software de Bluetooth de Silicon Laboratories, los desarrolladores pueden implementar rápidamente la funcionalidad de malla Bluetooth en dispositivos de baja potencia para sus propias aplicaciones.

Módulo Bluetooth

La solución de malla Bluetooth de Silicon Labs se basa en su módulo de hardware de Bluetooth BGM13P de baja potencia, que combina un procesador inalámbrico y una pila Bluetooth completa para proporcionar un sistema Bluetooth completo y certificado en un paquete de 12.9 × 15.0 × 2.2 mm. En el corazón del módulo, un sistema en chip (SoC) inalámbrico EFR32BG13 de Blue Gecko proporciona la funcionalidad central. El SoC EFR32BG13 combina un núcleo Arm® Cortex®-M4 de 32 bits, un subsistema de radio de 2.4 GHz, 512 Kbytes de flash, 64 Kbytes de RAM y un amplio complemento de periféricos analógicos y digitales. Junto con un acelerador de cifrado de hardware en chip, el SoC soporta la creciente demanda de una seguridad más estricta con una unidad de administración de seguridad que proporciona el mismo tipo de control de acceso granular a los periféricos que la unidad de protección de memoria proporciona a la memoria.

El SoC EFR32BG13 puede servir como base para diseños de hardware de Bluetooth personalizados. Al usar el SoC, los desarrolladores asumen la responsabilidad no solo de los requisitos de diseño, como los circuitos de soporte del SoC, sino también de la certificación requerida en el diseño completo. El módulo ofrece un diseño completamente certificado que incluye el EFR32BG13 con los circuitos de soporte requeridos que incluyen varias fuentes de oscilador, dos cristales y controladores de puerto. Al mismo tiempo, el módulo proporciona una gama de características de ahorro de energía que permiten a los desarrolladores responder a la demanda continua de dispositivos de menor potencia.

El módulo consume solo 87 microamperios (μA)/MHz en modo activo y 1.4 μA en modo de reposo profundo con una completa retención de RAM. Para ayudar a maximizar el tiempo que se pasa en ese modo de reposo profundo de baja potencia, los ingenieros pueden aprovechar las características que incluyen una interfaz de sensor de baja energía y un temporizador de baja energía, entre otros. Mediante la interfaz de sensor de baja energía, los ingenieros pueden programar que la máquina de estado finito integrada del módulo y los periféricos analógicos adquieran y procesen las señales del sensor mientras el procesador permanece en modo de reposo profundo. De manera similar, el temporizador de baja energía permite a los ingenieros generar ondas simples y supervisar el reloj/contador en tiempo real para realizar acciones en períodos designados sin la participación del procesador.

Por supuesto, el consumo de energía en dispositivos inalámbricos generalmente depende de la eficiencia del subsistema de radio. En este caso, el subsistema de radio de 2.4 GHz del módulo consume solo 9.9 miliamperios (mA) en modo de recepción y 8.5 mA en modo de transmisión a una potencia de salida de 0 dBm. Aun así, el módulo proporciona una característica adicional para el ahorro de energía a través del control de RF. Los desarrolladores pueden programar una característica de detección de RF en el módulo para reactivar el procesador cuando se detecta energía de RF de banda ancha. Al usar este enfoque, los desarrolladores pueden mantener el módulo en modo de reposo profundo durante períodos de inactividad sin pérdida de comunicaciones. Sin embargo, como se señaló anteriormente, los desarrolladores también pueden configurar un dispositivo para actuar como un nodo de baja potencia de Bluetooth 5 que simplemente se activa periódicamente del reposo profundo para sondear un nodo friend en busca de mensajes en caché.

Desarrollo del sistema

Con todas sus características, el módulo presenta poca dificultad en la implementación. Los desarrolladores pueden simplemente colocar el módulo en un diseño con un procesador existente para usarlo como un coprocesador de red Bluetooth (Figura 2A). Alternativamente, los desarrolladores pueden usar el módulo como una solución de sistema completa (Figura 2B). En este modo independiente, los desarrolladores pueden ejecutar el código de aplicación en el procesador EFR32BG13 del módulo y utilizar los periféricos analógicos y digitales integrados del EFR32BG13 para la adquisición de señal en un diseño de IoT simple.

Figura 2: Los diseñadores pueden usar el módulo BGM13P como un coprocesador Bluetooth para una CPU host (A) o usarlo de manera independiente (B), al aprovechar el SoC EFR32BG13 integrado del módulo para la ejecución del programa de aplicación e incluso para la adquisición de datos del sensor. (Fuente de la imagen: Silicon Labs)

Los desarrolladores pueden simplificar aún más el diseño de Bluetooth con el BGM13P22F512GA-V2, una versión del módulo que incluye una antena integrada. Para los diseños dirigidos a un entorno de RF más desafiante, los desarrolladores pueden recurrir al BGM13P22F512GE-V2, una versión con un conector U.FL para conectar una antena de parche plana compatible con Bluetooth, como la FXP74.07.0100A de Taoglas.

Silicon Labs elimina incluso ese nivel de implementación de hardware con su kit de desarrollo SLWSTK6101C. Diseñado para funcionar con placas de conexión para sus diferentes dispositivos Bluetooth, el SLWSTK6101C proporciona un diseño representativo de IoT que incluye el flash de 8 Mbit MX25R8035F de Macronix, la pantalla LCD 128 x 128 LS013B7DH03 de Sharp Microelectronics y el sensor de temperatura y humedad Si7021 de Silicon Labs. En este caso, los desarrolladores conectan la placa de radio inalámbrica SLWRB4306A, que incluye el módulo BGM13P, a la placa SLWSTK6101C.

Además de ser un diseño listo para producción, el conjunto de placas completo proporciona un diseño de referencia probado que los ingenieros pueden usar a fin de examinar diferentes enfoques para dispositivos de interfaz como el flash, la pantalla LCD y el sensor.

Por ejemplo, mientras el flash de 8 Mbit y la pantalla LCD se conectan al módulo a través de su bus SPI, la interfaz I²C del sensor Si7021 comparte el bus con un cabezal externo en la placa de desarrollo. Silicon Labs demuestra un método para diseñar una interfaz simple que mantiene el sensor normalmente desactivado y aislado eléctricamente de ese bus compartido. Cuando la entrada PD15 del módulo se eleva, la salida SENSOR_ENABLE se eleva, esto conecta el sensor al riel de alimentación VMCU de 3.3 V y el bus I²C (Figura 3).

Figura 3: Además de proporcionar una plataforma de evaluación de hardware, el kit de desarrollo SLWSTK6101C de Silicon Labs sirve como un diseño de referencia, que ilustra los métodos para interactuar con un dispositivo externo como el sensor Si7021 de Silicon Labs que se muestra aquí. (Fuente de la imagen: Silicon Labs)

La cabecera de bus compartido I²C es solo una de varias características diseñadas para soportar el desarrollo con esta plataforma (Figura 4). Junto con un depurador de J-Link incorporado, la placa proporciona una interfaz de seguimiento de paquete (PTI) que permite a los ingenieros analizar paquetes en detalle. La PTI se basa en un paquete y una unidad de seguimiento de estado incorporada en el SoC EFR32BG13 para proporcionar una captura no invasiva de todos los paquetes enviados y recibidos por el sistema. Para analizar protocolos complejos como la malla Bluetooth, esta capacidad de seguimiento de paquete proporciona una herramienta que puede ser fundamental para la optimización y el ajuste de las comunicaciones de red de bajo nivel.

Figura 4: El kit SLWSTK6101C de Silicon Labs presenta múltiples interfaces para seguimiento de paquete, supervisión de energía y seguimiento de bajo nivel de macrocélulas de seguimiento integrado (ETM) de Arm. Esto brinda a los ingenieros un amplio conjunto de herramientas para el análisis profundo de la operación y el rendimiento del diseño. (Fuente de la imagen: Silicon Labs)

Si bien los expertos en redes necesitan capacidades como la PTI para la optimización de la red, los desarrolladores de sistemas necesitan herramientas que los ayuden a identificar las ineficiencias de las aplicaciones que pueden conducir a un consumo excesivo de potencia. Para este tipo de optimización de potencia a nivel de aplicación, el perfilador de energía Simplicity Studio de Silicon Labs proporciona análisis a nivel de código del consumo de potencia.

Al igual que con la herramienta de seguimiento de paquete, el perfilador de energía aprovecha el hardware subyacente. En este caso, la placa incluye un circuito medidor de energía dedicado que comprende una resistencia de sensor de corriente, un amplificador de detección de corriente y etapas de ganancia que proporcionan su salida al controlador de la placa para acceder a un sistema host de desarrollo (Figura 5). Las etapas de ganancia paralela permiten que el monitor de energía mida la corriente entre 0.1 μA a 95 mA en dos niveles de resolución diferentes: 0.1 mA de resolución por encima de 250 μA; y 1 μA de resolución por debajo del umbral de 250 μA.

Figura 5: Integrados en el módulo Bluetooth BGM13P, un circuito medidor de energía dedicado y un controlador de procesamiento pueden proporcionar una medición de corriente no invasiva de 0.1 μA a 95 mA. (Fuente de la imagen: Silicon Labs)

Mientras que el circuito medidor de energía genera mediciones de corriente, los mecanismos de seguimiento de bajo nivel integrados en el EFR32BG13 pueden muestrear periódicamente el contador de programa del procesador y emitir los resultados en la clavija de salida de cable serial del dispositivo. Al combinar los resultados del medidor de energía y la salida de seguimiento de este programa, el perfilador de energía puede proporcionar una visualización en tiempo real del consumo de energía vinculado al código que se ejecuta en el dispositivo (Figura 6).

Figura 6: El perfilador de energía Simplicity Studio combina la salida del medidor de energía con los datos de seguimiento del programa para proporcionar una visualización en tiempo real del consumo de corriente vinculado al código real. (Fuente de la imagen: Silicon Labs)

Desarrollo de aplicaciones de malla

Si bien los ingenieros de hardware pueden usar el kit de desarrollo para optimizar sus diseños de hardware, los desarrolladores de software pueden aprovechar el amplio entorno de desarrollo de software de Silicon Labs para crear rápidamente aplicaciones de redes de malla. Provista con Simplicity Studio, la pila de malla Bluetooth 5 de Silicon Labs amplía la pila Bluetooth básica con recursos de malla específicos. Como resultado, los desarrolladores pueden trasladarse fácilmente de protocolos de Bluetooth más convencionales, como comunicaciones de señales o de punto a punto, a topologías de malla completa (Figura 7).

Figura 7: La pila de malla Bluetooth de Silicon Labs amplía la funcionalidad anterior de Bluetooth (azul) con capas de malla (verde), lo que permite a los desarrolladores aprovechar toda la gama de características de Bluetooth, desde las configuraciones de señalización a malla completa. (Fuente de la imagen: Silicon Labs)

Utilizado con las placas de desarrollo SLWRB4306A y SLWSTK6101C basadas en BGM13P de Silicon Labs, Simplicity Studio permite a los desarrolladores configurar su entorno con los kits de desarrollo de software (SDK) apropiados. Para el desarrollo de Bluetooth, Studio proporciona el SDK de malla Bluetooth de Silicon Labs junto con el código fuente y binario de demostración prediseñados. Dentro de este entorno, los desarrolladores pueden trabajar con un código de muestra que implemente una aplicación completa de malla Bluetooth.

Diseñados para demostrar operaciones en una red de malla Bluetooth, las aplicaciones de muestra trabajan con la placa de desarrollo y una aplicación móvil para guiar al desarrollador a través de operaciones de malla típicas, que incluyen el aprovisionamiento, la configuración y el uso relacionado con la aplicación. Para implementar la aplicación de muestra, los ingenieros ejecutan Simplicity Studio contra un conjunto de placas de desarrollo configuradas por separado para funcionar como una luz o un interruptor en una aplicación de iluminación conectada. Al trabajar con el código de muestra y el hardware, los ingenieros pueden obtener una mejor comprensión de cada fase operativa de una aplicación de malla típica que comienza con el encendido del dispositivo.

Con la arquitectura de software de Silicon Labs, las operaciones de Bluetooth proceden como una serie de eventos, con ID de eventos predefinidos que indican la naturaleza del evento. En el paquete de software de muestra, la rutina principal(), que se ejecuta al encender o reiniciar, simplemente invoca una serie de rutinas de inicio antes de ingresar a su bucle principal, que consiste en solo dos líneas de código en este caso (Listado 1).

Copy int main() { #ifdef FEATURE_SPI_FLASH /* Coloque el flash SPI en modo Deep Power Down para aquellas placas de radio donde esté disponible */ MX25_init(); MX25_DP(); /* Debemos desactivar la comunicación SPI */ USART_Reset(USART1); #endif /* FEATURE_SPI_FLASH */ enter_DefaultMode_from_RESET(); #if (EMBER_AF_BOARD_TYPE == BRD4304A) LNA_init(); #endif gecko_init(&config); #ifdef FEATURE_PTI_SUPPORT APP_ConfigEnablePti(); #endif // FEATURE_PTI_SUPPORT RETARGET_SerialInit(); /* inicie LED y botones. Nota: algunas placas de radio comparten el mismo GPIO para botones y LED.
   * El inicio se realiza en este orden de modo que la configuración predeterminada será botón para aquellas * placas de radio con pins compartidos. led_init() se denomina luego según sea necesario (re)iniciar los LED * */ led_init(); button_init(); LCD_init(); while (1) { struct gecko_cmd_packet *evt = gecko_wait_event(); handle_gecko_event(BGLIB_MSG_ID(evt->header), evt); } } 

Listado 1: Simplicity Studio proporciona un entorno de desarrollo completo que incluye código de muestra, como esta rutina principal de iluminación de malla, que demuestra el inicio y el bucle para el manejo de eventos. (Fuente código: Silicon Labs)

En la primera línea del bucle principal, la función gecko_wait_event() realiza el bloqueo mientras se espera que los eventos aparezcan en una cola de eventos poblada por niveles inferiores. Aunque los desarrolladores a menudo evitan las funciones de bloqueo, este enfoque es particularmente efectivo en este caso porque la pila Bluetooth administra automáticamente los estados de reposo de baja potencia en este modo bloqueado. Para requisitos de aplicación específicos que no pueden tolerar esperas de bloqueo, el SDK también proporciona una función de no bloqueo que regresa el próximo evento o NULA si la cola está vacía. Sin embargo, con esta función, los desarrolladores tienen que ocuparse de la administración del reposo de baja potencia por sí mismos.

En la segunda línea del bucle principal, la función del manipulador handle_gecko_event() procesa el último evento (evt) en función del ID del evento (Listado 2). Cuando un dispositivo se enciende, la pila emite un evento de arranque del sistema (gecko_evt_system_boot_id). A su vez, el manipulador de eventos ingresa una serie de funciones de inicio, incluida gecko_cmd_mesh_node_init(), que inicia la pila de malla Bluetooth. Luego, el manipulador ingresa otras funciones para proporcionar la funcionalidad asociada con ese tipo de evento representado por su ID de evento asociado.

Copy /** * Manipulación de eventos de pila. Tanto los eventos de Bluetooth de LE como malla Bluetooth se manipulan aquí.
 */ static void handle_gecko_event(uint32_t evt_id, struct gecko_cmd_packet *evt) { struct gecko_bgapi_mesh_node_cmd_packet *node_evt; struct gecko_bgapi_mesh_generic_server_cmd_packet *server_evt; struct gecko_msg_mesh_node_provisioning_failed_evt_t *prov_fail_evt; if (NULL == evt) { return; } switch (evt_id) { case gecko_evt_system_boot_id: // verificar estado del botón en el encendido. Si PB0 or PB1 se mantiene apretado entonces, haga el reinicio de fábrica if (GPIO_PinInGet(BSP_GPIO_PB0_PORT, BSP_GPIO_PB0_PIN) == 0 || GPIO_PinInGet(BSP_GPIO_PB1_PORT, BSP_GPIO_PB1_PIN) == 0) { initiate_factory_reset(); } else { struct gecko_msg_system_get_bt_address_rsp_t *pAddr = gecko_cmd_system_get_bt_address(); set_device_name(&pAddr->address); // Inicie la pila de malla en el modo de funcionamiento del nodo, espere a que inicie el evento gecko_cmd_mesh_node_init(); // reinicie los LED (necesarios para esas placas de radio que comparten GPIO para botón/LED) led_init(); } break; .
      .
      .
    case gecko_evt_mesh_node_initialized_id: printf(node initialized\r\n); struct gecko_msg_mesh_node_initialized_evt_t *pData = (struct gecko_msg_mesh_node_initialized_evt_t *)&(evt->data); if (pData->provisioned) { .
      .
      .
      } else { printf(node is unprovisioned\r\n); LCD_write(unprovisioned, LCD_ROW_STATUS); printf(starting unprovisioned beaconing...\r\n); gecko_cmd_mesh_node_start_unprov_beaconing(0x3); // habilite el portador de aprovisionamiento de ADV y GATT } break; case gecko_evt_mesh_node_provisioning_started_id: printf(Started provisioning\r\n); LCD_write(provisioning..., LCD_ROW_STATUS); // inicie el temporizador para LED parpadeantes para indicar qué nodo se está aprovisionando gecko_cmd_hardware_set_soft_timer(32768 / 4, TIMER_ID_PROVISIONING, 0); break; case gecko_evt_mesh_node_provisioned_id: _my_index = 0; // índice de elemento primario con hardcode a cero en este ejemplo lightbulb_state_init(); printf(node provisioned, got index=%x\r\n, _my_index); // detenga LED parpadeante cuando se complete el aprovisionamiento gecko_cmd_hardware_set_soft_timer(0, TIMER_ID_PROVISIONING, 0); LED_set_state(LED_STATE_OFF); LCD_write(provisioned, LCD_ROW_STATUS); break; case gecko_evt_mesh_node_provisioning_failed_id: prov_fail_evt = (struct gecko_msg_mesh_node_provisioning_failed_evt_t *)&(evt->data); printf(provisioning failed, code %x\r\n, prov_fail_evt->result); LCD_write(prov failed, LCD_ROW_STATUS); /* comience un temporizador único que desencadenará un reinicio suave después de un pequeño retraso */ gecko_cmd_hardware_set_soft_timer(2 * 32768, TIMER_ID_RESTART, 1); break; .
      .
      .
  } } 

Listado 2: Los desarrolladores pueden examinar el código de muestra de malla de Silicon Labs para ver patrones de diseño clave, como el procesamiento de eventos de aprovisionamiento, que se muestra en este fragmento de la rutina del manipulador de eventos handle_gecko_event() ingresado en la rutina principal de luz de malla (ver Listado 1). (Fuente código: Silicon Labs)

Una de las series clave de eventos en una red de malla Bluetooth se relaciona con el proceso de aprovisionamiento. Después de que un dispositivo se encienda y complete su secuencia de inicio, pasa al modo de señalización y se anuncia en la red para el aprovisionamiento. Mientras el aprovisionamiento continúa hasta su finalización (o falla), el código de muestra utiliza la pantalla LCD y los LED del kit de desarrollo para indicar el estado. Al examinar el bloque de códigos del manipulador de eventos para cada estado de aprovisionamiento, los desarrolladores pueden obtener una comprensión rápida de esta secuencia y las opciones de aprovisionamiento.

De forma similar, los ingenieros de software pueden usar el código de muestra del manipulador como guía para crear su funcionalidad a nivel de aplicación. Por ejemplo, un concepto clave en las redes de malla Bluetooth es el uso de un modelo de publicación y suscripción para asociar nodos que comparten alguna relación funcional (Figura 8).

Figura 8: Los desarrolladores de aplicaciones usan el modelo de publicación y suscripción de Bluetooth para combinar dispositivos en grupos funcionales, como un grupo de luces controladas por uno o más interruptores. (Fuente de la imagen: Silicon Labs)

Con este enfoque, se podrían suscribir varias bombillas inteligentes a un editor de interruptores. Cuando el usuario final activa el interruptor, este publicará el evento de ENCENDIDO/APAGADO. Ese evento se conectaría en cascada a través de la red de malla a las bombillas inteligentes suscritas, y sus manipuladores de eventos tomarían la acción adecuada. El código de muestra de Silicon Labs demuestra este proceso: primero con una solicitud de encendido/apagado publicada en el interruptor conectado de malla (Listado 3) y luego con una respuesta correspondiente en la luz conectada (Listado 4).

Copy /** * Esta función publica una solicitud de encendido/apagado para cambiar el estado de las luces en el grupo.
 * La variable global switch_pos mantiene el último estado de luz deseado, los valores posibles son * switch_pos = 1 -> PB1 se presionó, enciende las luces * switch_pos = 0 -> PB0 se presionó, apaga las luces * * Esta aplicación envía múltiples solicitudes para cada botón para mejorar la fiabilidad.
 * La retransmisión de parámetros indica si se trata de la primera solicitud o una retransmisión.
 * El ID de transferencia no aumenta en caso de una retransmisión.
 */ void send_onoff_request(int retrans) { uint16 resp; uint16 delay; struct mesh_generic_request req; req.kind = mesh_generic_request_on_off; req.on_off = switch_pos ? MESH_GENERIC_ON_OFF_STATE_ON : MESH_GENERIC_ON_OFF_STATE_OFF; // incremente ID de transferencia para cada solicitud, a menos que sea una retransmisión if (retrans == 0) { trid++; } /* se calcula el retraso de la solicitud de modo que la última solicitud tenga cero retraso y cada * solicitud previa tenga un retraso que se incremente en pasos de 50 ms. Por ejemplo, al usar tres * solicitudes de encendido/apagado por botón, los retrasos se establecen como 100, 50, 0 ms */ delay = (request_count - 1) * 50; resp = gecko_cmd_mesh_generic_client_publish( MESH_GENERIC_ON_OFF_CLIENT_MODEL_ID, _my_index, trid, 0, // transition delay, 0, // flags mesh_generic_request_on_off, // type 1, // param len &req.on_off /// parameters data )->result; if (resp) { printf(gecko_cmd_mesh_generic_client_publish failed,code %x\r\n, resp); } else { printf(request sent, trid = %u, delay = %d\r\n, trid, delay); } } 

Listado 3: Este fragmento de la aplicación de muestra del interruptor de malla de Silicon Labs ilustra el uso del proceso de publicación de Bluetooth 5 (gecko_cmd_mesh_generic_client_publish) para solicitar un cambio de estado (encendido o apagado) en una luz suscrita a este flujo de eventos. (Fuente código: Silicon Labs)

Copy static void onoff_request(uint16_t model_id, uint16_t element_index, uint16_t client_addr, uint16_t server_addr, uint16_t appkey_index, const struct mesh_generic_request *request, uint32_t transition_ms, uint16_t delay_ms, uint8_t request_flags) { printf(ON/OFF request: requested state=<%s>, transition=%u, delay=%u\r\n, request->on_off ? ON : OFF, transition_ms, delay_ms); if (lightbulb_state.onoff_current == request->on_off) { printf(Request for current state received; no op\n); } else { printf(Turning lightbulb <%s>\r\n, request->on_off ? ON : OFF); if (transition_ms == 0 && delay_ms == 0) { // Immediate change lightbulb_state.onoff_current = request->on_off; lightbulb_state.onoff_target = request->on_off; if (lightbulb_state.onoff_current == MESH_GENERIC_ON_OFF_STATE_OFF) { LED_set_state(LED_STATE_OFF); } else { LED_set_state(LED_STATE_ON); } } else { // Current state remains as is for now lightbulb_state.onoff_target = request->on_off; LED_set_state(LED_STATE_TRANS); // set LEDs to transition mode gecko_cmd_hardware_set_soft_timer(TIMER_MS_2_TIMERTICK(delay_ms + transition_ms), TIMER_ID_TRANSITION, 1); } lightbulb_state_store(); } if (request_flags & MESH_REQUEST_FLAG_RESPONSE_REQUIRED) { onoff_response(element_index, client_addr, appkey_index); } else { onoff_update(element_index); } } 

Listado 4: La muestra de luz de malla de Silicon Labs incluye rutinas para eventos específicos a nivel de aplicación, como esta función para encender o apagar un LED en respuesta a una solicitud publicada desde el interruptor (consulte el Listado 3). (Fuente código: Silicon Labs)

Junto con la pila Bluetooth y el SDK para el desarrollo de nodos, Silicon Labs también proporciona la pieza final del rompecabezas de malla Bluetooth: la conexión a dispositivos móviles. La mayoría de los dispositivos móviles son compatibles con Bluetooth 4 y, aunque sus radios pueden soportar requisitos de Bluetooth 5, no brindan soporte de pila para los niveles de malla Bluetooth 5. Silicon Labs soluciona esta limitación al proporcionar a los desarrolladores de aplicaciones móviles una pila de software adicional que proporciona funcionalidad de malla (Figura 9).

Figura 9: Los desarrolladores pueden agregar la pila de malla de Silicon Labs para dispositivos móviles a sus aplicaciones móviles, lo que permite el uso de dispositivos móviles con Bluetooth 4 en redes de malla Bluetooth 5. (Fuente de la imagen: Silicon Labs)

Conclusión

Las redes de malla Bluetooth 5 proporcionan una transición natural para una amplia gama de aplicaciones que ya aprovechan los teléfonos inteligentes y otros dispositivos móviles para las comunicaciones de punto a punto. Sin embargo, la implementación de redes de malla Bluetooth 5 presenta desafíos significativos en el diseño de hardware y software, particularmente en aplicaciones de potencia limitada como IoT. Además, los ingenieros de hardware deben cumplir con los requisitos de espacio mínimo y baja potencia; los ingenieros de software necesitan diseñar un software que use recursos mínimos para ejecutar protocolos de comunicación complejos. Con la combinación del módulo BGM13P, la placa de desarrollo SLWSTK6101C y las pilas Bluetooth para nodos y dispositivos móviles, los ingenieros tienen una plataforma completa para el desarrollo rápido de aplicaciones que utilizan redes de malla Bluetooth.