Construya un concentrador de Bluetooth de baja energía y una red de sensores

Por Stephen Evanczuk

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

Con su amplia disponibilidad en dispositivos móviles, Bluetooth es muy adecuado para proporcionar a los consumidores acceso inalámbrico simple a productos inteligentes. Sin embargo, para los desarrolladores de IoT, la construcción de redes de sensores conectadas por Bluetooth presenta desafíos, tales como maximizar la duración de la batería, optimizar los protocolos de Bluetooth y garantizar la conectividad segura entre los dispositivos.

Como se mostrará en este artículo, utilizando un dispositivo Bluetooth avanzado y un entorno de desarrollo asociado de Cypress Semiconductor, los desarrolladores pueden sortear estos problemas e implementar rápidamente redes de sensores de concentradores Bluetooth seguros.

¿Por qué Bluetooth?

El amplio soporte de Bluetooth en teléfonos inteligentes y otros dispositivos móviles lo ha convertido en la tecnología inalámbrica preferida para conectar a los consumidores con sus dispositivos electrónicos personales, como dispositivos portátiles y dispositivos de uso médico, entre otros. Con la aparición de Bluetooth 5, los desarrolladores de IoT pueden aprovechar esas mismas ventajas a la vez que satisfacen los crecientes requisitos de mayor alcance y velocidades de datos más altas asociadas con redes de sensores y otras aplicaciones de IoT.

Para crear diseños para esas aplicaciones, los desarrolladores pueden recurrir a una creciente variedad de dispositivos con capacidad Bluetooth 5. Al combinar un subsistema de RF completo y un núcleo de procesador, estos dispositivos son capaces de realizar transacciones de bajo nivel asociadas con las comunicaciones de Bluetooth. Sin embargo, la necesidad de mantener un bajo consumo de energía y garantizar una conectividad segura en redes IoT puede presentar una complicación adicional al implementar Bluetooth en estas aplicaciones.

Solución integrada

Cypress Semiconductor CYW20719 está diseñado específicamente para satisfacer los crecientes requisitos de los diseños de Bluetooth con alimentación por batería para IoT, dispositivos portátiles, dispositivos electrónicos personales y otras aplicaciones de baja potencia. Junto con sus capacidades de bajo consumo, su compatibilidad con funciones avanzadas de Bluetooth 5, incluido el salto de frecuencia adaptativo, proporciona una ventaja importante en los entornos de radio ocupados asociados con esas aplicaciones.

El dispositivo integra un subsistema de radio Bluetooth de baja potencia, un núcleo Arm® Cortex®-M4 con unidad de punto flotante (FPU) y múltiples bloques periféricos (Figura 1). Además, un motor de seguridad en chip acelera la criptografía de clave pública y proporciona la funcionalidad criptográfica crítica necesaria para ayudar a garantizar la seguridad de las operaciones de Bluetooth. Finalmente, una unidad de gestión de energía en el chip (PMU) proporciona a los desarrolladores un mecanismo flexible para cumplir con los requisitos de la operación de potencia ultra baja, que cada vez es más necesaria para los dispositivos habilitados para Bluetooth.

Diagrama de Cypress Semiconductor CYW20719

Figura 1: Cypress Semiconductor CYW20719 combina un Arm® Cortex®-M4, un subsistema completo de Bluetooth y servicios de software integrados para proporcionar un MCU inalámbrico con Bluetooth 5 completa para diseños de baja potencia. (Fuente de la imagen: Cypress Semiconductor)

El subsistema de radio CYW20719 incluye rutas de señal de RF completas de 2.5 GHz para la operación de transmisión (Tx) y recepción (Rx). Para la ruta de la señal Rx, el dispositivo atenúa las señales fuera de banda y, así, logra una sensibilidad de Rx de -95.5 dBm, mientras que permite a los desarrolladores utilizar el dispositivo sin filtros adicionales fuera de chip, si fuese necesario. Su ruta de señal de Tx incluye un amplificador de potencia integrado (PA) diseñado para soportar niveles de potencia de transmisión configurables que van desde -24 dBm hasta un máximo de +4 dBm. Junto con las capacidades de la capa física integrada (PHY), el dispositivo incluye una capa completa de control de acceso medio (MAC) de Bluetooth 5 en el chip. Con sus rutas de señal de Rx y Tx optimizadas, el dispositivo usa solo 5.9 mA de corriente de Rx o 5.6 mA (a 0 dBm) de corriente de Tx.

Para minimizar aún más el consumo de energía, el dispositivo proporciona múltiples modos de energía administrados por la unidad de administración de energía integrada (PMU). Diseñada para suministrar dominios de potencia digital y de RF separados, la PMU combina un regulador buck integrado, un regulador de caída baja (LDO) para circuitos digitales y un LDO separado para circuitos de RF (Figura 2). Además, la PMU incluye un LDO de bypass separado (BYPLDO) que automáticamente evita el regulador buck para suministrar los LDO digitales y de RF si el suministro de fuente de VBAT cae por debajo de 2.1 voltios.

Diagrama de PMU Cypress CYW20719

Figura 2: La PMU CYW20719 de Cypress gestiona dominios de potencia separados que se pueden desactivar de forma selectiva en diferentes modos de baja potencia para reducir el consumo de corriente en diseños de baja potencia. (Fuente de la imagen: Cypress Semiconductor)

En funcionamiento, la PMU ajusta los dominios de potencia de acuerdo con el modo de potencia seleccionado, lo que incluye el modo completamente activo, el modo inactivo y tres modos de suspensión diferentes. En el modo de suspensión de más baja potencia (SDS), la PMU apaga todos los bloques de dispositivo, excepto la potencia de E/S, el reloj en tiempo real (RTC) y un oscilador dedicado de baja potencia (LPO) utilizado como fuente de reloj para algunos bloques y tiempo de activación.

Incluso utilizando esos recursos mínimos, el CYW20719 en modo SDS puede mantener una conexión con otro dispositivo Bluetooth previamente emparejado, y consumir, así, menos de 70 microamperios (μA) en el proceso. Sin embargo, en este modo, el dispositivo no retiene la memoria y requiere un arranque en caliente para restablecer el estado antes de proceder con operaciones más complejas. Los otros dos modos de suspensión, la suspensión de pérdida de potencia (PDS) y el estado de suspensión, mantienen niveles crecientes de actividad del dispositivo, incluida la retención de memoria con aumentos graduales proporcionales en el consumo de energía. Aun así, los desarrolladores que trabajan con presupuestos de potencia muy limitados pueden aprovechar el modo PDS como publicidad de Bluetooth de baja potencia (alrededor de 125 μA) y conexiones activas (alrededor de 170 μA). Al administrar los modos de alimentación del dispositivo, los desarrolladores pueden lograr fácilmente un funcionamiento a muy baja potencia sin comprometer la funcionalidad.

Integración de sistema

Incluso con sus modos de funcionamiento flexibles y su amplia funcionalidad, el CYW20719 requiere pocos componentes adicionales para completar la integración de hardware en el diseño de un sistema. Debido a que integra componentes críticos en el chip, los desarrolladores solo necesitan agregar unas pocas resistencias, capacitores de acoplamiento, un inductor de 2.2 μH, como el Murata LQH2MCN2R2M52L, y perlas de ferrita como el Murata BLM15AG601SN1D (Figura 3). Aun así, es aconsejable colocar un filtro de banda pasante entre el CYW20719 y los componentes de adaptación de antena para reducir los armónicos.

Diagrama del Cypress CYW20719 (haga clic para agrandar)

Figura 3: Debido a que Cypress CYW20719 integra todas las funciones críticas, los desarrolladores pueden completar la integración de hardware con solo unos pocos componentes adicionales, incluido un filtro de banda pasante recomendado para reducir los armónicos. (Fuente de la figura: Cypress Semiconductor)

El dispositivo también ayuda a simplificar la integración del software con su amplia memoria en el chip, que incluye 1 Mbyte flash, 512 Kbytes de RAM y 2 Mbytes de ROM. Mientras que el flash y la RAM proporcionan a los desarrolladores áreas de memoria para sus aplicaciones, la ROM en el chip está reservada para el firmware del dispositivo y los perfiles de Bluetooth. Para admitir parches de firmware cuando sea necesario, el dispositivo proporciona la RAM de parche, una región de RAM conectada a través de la lógica de control de parche (consulte la Figura 1 anterior). Finalmente, el dispositivo proporciona un área de memoria siempre activa (AON), la cual permite que el dispositivo almacene datos incluso en modos de baja potencia como SDS que, de lo contrario, desactivarían la memoria volátil.

Aunque la RAM y la memoria flash proporcionadas en el chip pueden parecer limitadas en comparación con otros dispositivos de última generación, la amplia compatibilidad de software incorporada en la ROM garantiza una gran cantidad de memoria para las aplicaciones típicas. Cypress configura la ROM en el chip con una completa pila de software que se extiende desde la capa de abstracción de hardware (HAL) más baja hasta la interfaz de programación de aplicaciones (API) para el entorno WICED (conectividad inalámbrica a Internet para dispositivos integrados) (Figura 4).

Imagen de los 2 Mbytes de firmware ROM de Cypress​CYW20719

Figura 4: Los 2 Mbytes de firmware ROM del Cypress CYW20719 proporciona una pila de software completa que incluye un sistema operativo en tiempo real, lo que reduce la complejidad y el espacio del código de la aplicación del desarrollador. (Fuente de la imagen: Cypress Semiconductor)

Basándose en la HAL, el firmware ROM ejecuta un sistema operativo incorporado en tiempo real y maneja todas las interacciones con el hardware CYW20719. Al mismo tiempo, el firmware ROM incluye un complemento completo de capas de servicio Bluetooth, incluidas las que soportan el Perfil de atributos genérico Bluetooth (GATT) y el perfil de acceso genérico (GAP).

Para aplicaciones típicas, el código de desarrollador se ejecuta desde la RAM, utilizando las API de WICED para acceder a RTOS, periféricos y otras características del dispositivo. Aunque los requisitos de RAM pueden variar significativamente, la mayoría del código de la aplicación para el CYW20719 generalmente deja suficiente RAM libre para los datos o la memoria de trabajo. Por ejemplo, la aplicación hello_sensor descrita más adelante deja aproximadamente 240 Kbytes de RAM libre.

Sin embargo, para aplicaciones con bases de códigos especialmente grandes, los desarrolladores pueden aprovechar la capacidad del CYW20719 para trabajar con el código de la aplicación diseñado para ejecutarse en el sitio (XIP) desde el flash en el chip. Aquí, el entorno WICED carga el código designado por el desarrollador y las secciones de datos de solo lectura en el flash en el chip y coloca las secciones restantes en la RAM. Este enfoque, por supuesto, reduce el espacio de RAM para una aplicación, pero puede afectar el rendimiento. En consecuencia, los desarrolladores deben tener cuidado al designar las secciones de código XIP y asegurarse de que las funciones de tiempo crítico se colocan en la memoria RAM.

Desarrollo de aplicaciones

Aunque el CYW20719 simplifica la integración del diseño, los desarrolladores que buscan enfocarse en aplicaciones seguras de Bluetooth de baja potencia aún pueden enfrentar demoras significativas para completar el diseño de hardware y el desarrollo de aplicaciones. Diseñado para demostrar aplicaciones basadas en CYW20719, el kit de evaluación Cypress CYW920719Q40EVB-01 funciona con el entorno de software Cypress WICED para proporcionar un diseño de referencia y una plataforma de desarrollo integral para crear aplicaciones de IoT compatibles con Bluetooth 5.0.

El kit de evaluación está construido alrededor de un módulo portador que incluye el CYW20719 en el diseño de la figura 3, con la adición de un detector de voltaje Torex Semiconductor XC6119N conectado al pin RST_N del CYW20719 para realizar un reinicio. El módulo portador está soldado a la placa base del kit, que incluye un sensor de movimiento de 9 ejes STMicroelectronics LSM9DS1TR, un termistor NTC Murata serie NCU, los puertos CYW20719 GPIO, una conexión de depuración, cabeceras compatibles con Arduino para la expansión e interruptores y LED como interfaz de usuario simple (Figura 5).

Diagrama del kit de evaluación Cypress CYW920719Q40EVB-01

Figura 5: El kit de evaluación Cypress CYW920719Q40EVB-01 combina un CYW20719 en un módulo portador con múltiples componentes de placa base capaces de soportar una aplicación típica de IoT. (Fuente de la imagen: Cypress Semiconductor)

El software de muestra de Cypress utiliza el CYW20719 y otros componentes como parte de una amplia demostración de conectividad Bluetooth segura en una red representativa de IoT que comprende múltiples dispositivos de sensores y un concentrador central (Figura 6). Con esta aplicación de muestra, los desarrolladores pueden explorar diferentes niveles de seguridad para el emparejamiento entre un dispositivo sensor y el concentrador, y evaluar el impacto de estos diferentes niveles de seguridad en el intercambio de datos.

Diagrama de los kits CYW920719Q40EVB-01 y el entorno de desarrollo Cypress WICED

Figura 6: Diseñado para funcionar con múltiples kits CYW920719Q40EVB-01 y el entorno de desarrollo Cypress WICED, una aplicación de muestra Cypress exhibe conectividad Bluetooth segura en una aplicación IoT representativa. (Fuente de la imagen: Cypress Semiconductor)

Para el hardware de la aplicación, los desarrolladores utilizan un kit separado CYW920719Q40EVB-01 configurado como concentrador seguro y kits adicionales configurados como sensores individuales en la red. Una PC conectada a través de una conexión en serie a cada kit proporciona una consola para establecer parámetros, visualizar datos, imprimir mensajes de depuración e interactuar de otra manera con la aplicación de muestra.

Aunque no está incluido en esta aplicación de muestra, el único elemento restante en una aplicación típica como esta sería una conexión a un dispositivo móvil para funciones de supervisión y control de aplicaciones. Aquí, la PC conectada en serie cumple la misma función.

Cypress incluye el software para esta aplicación de muestra en su paquete de idiomas C BLE Secure Hub CYW20917 para su entorno de desarrollo WICED. En este caso, el paquete incluye dos proyectos para las dos funciones separadas en la aplicación de muestra. Diseñado para ejecutarse en el kit designado como concentrador seguro, un proyecto (secure_hub) permite que el concentrador admita múltiples roles de protocolo Bluetooth. En particular, el software del concentrador está diseñado para permitir el emparejamiento en niveles de seguridad separados con diferentes kits que se ejecutan como secundarios.

Los kits configurados como secundarios ejecutan el proyecto del sensor (hello_sensor) diseñado para ilustrar la recopilación de datos y la comunicación en el nivel de seguridad establecido durante el emparejamiento. Cada proyecto incluye varios módulos de encabezado y código necesarios para respaldar cada rol funcional. Entre estos archivos, cada uno de los proyectos secure_hub y hello_sensor incluye un encabezado de perfil genérico de atributos (GATT) (gatt_db.h) y un código (gatt_db.c).

En el protocolo Bluetooth, una tabla de búsqueda llamada base de datos (DB) GATT define la naturaleza y las capacidades de una conexión Bluetooth a través de un conjunto de servicios definidos que comprenden un conjunto de características soportadas. Por ejemplo, la especificación Bluetooth incluye servicios GATT predefinidos que van desde capacidades de utilidad, como notificación de alerta e información del dispositivo, hasta capacidades específicas de la aplicación como la presión arterial y los servicios de oxímetro de pulso. Al tener una función más fundamental que los servicios GATT, el perfil de acceso genérico (GAP) de Bluetooth para un dispositivo define cómo se anuncia a sí mismo para ser descubierto por la red y cómo establece las conexiones una vez descubierto.

El encabezado gatt_db.h y el código gatt_db.c en el proyecto secure_hub y el proyecto hello_sensor definen los servicios GAP y GATT para el concentrador seguro y los kits configurados del sensor, respectivamente. Para esta aplicación de demostración, cada proyecto define un servicio GATT personalizado según su función. Por ejemplo, el encabezado del proyecto hello_sensor incluye un tipo de enum C que define los manipuladores obligatorios del servicio GATT y GAP, así como una definición GATT personalizada para un servicio de sensor (Listado 1a). A su vez, el archivo gatt_db.c de ese proyecto usa esas definiciones para construir la base de datos GATT requerida en el protocolo Bluetooth (Listado 1b).

Copiar 

typedef enum

{

HANDLE_HSENS_GATT_SERVICE = 0x1, // service handle

 

HANDLE_HSENS_GAP_SERVICE = 0x14, // service handle

HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME, // characteristic handl

HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME_VAL, // char value handle

 

HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE, // characteristic handl

HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE_VAL,// char value handle

 

 

HANDLE_HSENS_SERVICE = 0x28,

HANDLE_HSENS_SERVICE_CHAR_UART, // characteristic handl

HANDLE_HSENS_SERVICE_CHAR_UART_VAL, // char value handle

HANDLE_HSENS_SERVICE_CHAR_CFG_DESC, // charconfig desc handl

 

HANDLE_HSENS_SERVICE_CHAR_BLINK, // characteristic handl

HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL, // char value handle

 

HANDLE_HSENS_SERVICE_CHAR_TEMP, // characteristic handl

HANDLE_HSENS_SERVICE_CHAR_TEMP_VAL, // char value handle

HANDLE_HSENS_SERVICE_CHAR_TEMP_CFG_DESC, // charconfig desc handl

(A)

Copiar 

 

/* Permisos para características personalizadas */

#define LED_BLINK_CHAR_PERMISSION    LEGATTDB_PERM_WRITE_REQ | LEGATTDB_PERM_AUTH_WRITABLE | LEGATTDB_PERM_READABLE

#define TEMP_CHAR_PERMISSION         LEGATTDB_PERM_READABLE

#define UART_CHAR_PERMISSION         LEGATTDB_PERM_READABLE

 

uint8_t paired_security_level;

 

static void                     temp_notificaition_timeout( uint32_t count );

 

 

const uint8_t hello_sensor_gatt_database[]=

{

// Declarar el servicio obligatorio del GATT

PRIMARY_SERVICE_UUID16( HANDLE_HSENS_GATT_SERVICE, UUID_SERVICE_GATT ),

 

// Declarar el servicio obligatorio GAP. El nombre del dispositivo y la apariencia son obligatorios

// características del servicio GAP

PRIMARY_SERVICE_UUID16( HANDLE_HSENS_GAP_SERVICE, UUID_SERVICE_GAP ),

 

// Declarar característica de servicio GAP obligatoria: Nombre del desarrollador

CHARACTERISTIC_UUID16( HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME, HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME_VAL,

UUID_CHARACTERISTIC_DEVICE_NAME, LEGATTDB_CHAR_PROP_READ, LEGATTDB_PERM_READABLE ),

 

// Declarar característica de servicio GAP obligatoria: Apariencia

CHARACTERISTIC_UUID16( HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE, HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE_VAL,

UUID_CHARACTERISTIC_APPEARANCE, LEGATTDB_CHAR_PROP_READ, LEGATTDB_PERM_READABLE ),

 

// Declarar el servicio Hello propietario con UUID de 128 bytes

PRIMARY_SERVICE_UUID128( HANDLE_HSENS_SERVICE, UUID_HELLO_SERVICE ),

// Declarar la característica utilizada para notificar o indicar el cambio

CHARACTERISTIC_UUID128( HANDLE_HSENS_SERVICE_CHAR_UART, HANDLE_HSENS_SERVICE_CHAR_UART_VAL,

UUID_HELLO_CHARACTERISTIC_NOTIFY, LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE, UART_CHAR_PERMISSION ),

 

 

// Declarar descriptor de configuración de característica del cliente

// El valor del descriptor puede ser modificado por el cliente

// El valor modificado se conservará durante la conexión y a través de la conexión

// para dispositivos enlazados. Establecer valor en 1 dice a esta aplicación que envíe notificaciones

// cuando el valor de la característica cambia. El valor 2 es para permitir indicaciones.

CHAR_DESCRIPTOR_UUID16_WRITABLE( HANDLE_HSENS_SERVICE_CHAR_CFG_DESC, UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ ),

// Declarar la configuración Hello característica

// La configuración consta de 1 byte que indica cuántas veces

// parpadea el LED cuando el usuario presiona el botón.

CHARACTERISTIC_UUID128_WRITABLE( HANDLE_HSENS_SERVICE_CHAR_BLINK, HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL,

UUID_HELLO_CHARACTERISTIC_LED_BLINK,

LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE,

LED_BLINK_CHAR_PERMISSION ),

 

CHARACTERISTIC_UUID128( HANDLE_HSENS_SERVICE_CHAR_TEMP, HANDLE_HSENS_SERVICE_CHAR_TEMP_VAL,

UUID_HELLO_CHARACTERISTIC_TEMP, LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE, TEMP_CHAR_PERMISSION ),

 

 

// Declarar descriptor de configuración de característica del cliente

// El valor del descriptor puede ser modificado por el cliente

// El valor modificado se conservará durante la conexión y a través de la conexión

// para dispositivos enlazados. Establecer valor en 1 dice a esta aplicación que envíe notificaciones

// cuando el valor de la característica cambia. El valor 2 es para permitir indicaciones.

CHAR_DESCRIPTOR_UUID16_WRITABLE( HANDLE_HSENS_SERVICE_CHAR_TEMP_CFG_DESC, UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ ),

(B)

Listado 1: Incluido en el proyecto hello_sensor de la aplicación Cypress BLE Secure Hub, un archivo de cabecera define un tipo de enumeración para diferentes características (A) que el módulo de código correspondiente utiliza para construir la base de datos GATT requerida para las operaciones de Bluetooth. (Fuente de código: Cypress Semiconductor)

Incluido en estas definiciones, el servicio del sensor GATT también define si sus características de servicio subyacentes pueden leer, escribir, notificar o indicar (usando la consola conectada). Por ejemplo, la característica de parpadeo del LED (HANDLE_HSENS_SERVICE_CHAR_BLINK declarada en el Listado 1a y aplicada en el Listado 1b) incluye máscaras de bits (LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE en el Listado 1b) que indican que la característica es legible y escribible.

El archivo gatt_db.c del proyecto hello_sensor, sin embargo, combina esas definiciones con código que implementa acceso seguro a esa característica. Es decir, la capacidad de hacer parpadear el LED la cantidad de veces que se indica mediante un carácter escrito por el desarrollador en la consola. Para los fines de esta aplicación de muestra, el acceso a esta capacidad requiere que la conexión a ese kit de sensores se haya realizado con el emparejamiento “hombre en el medio” (MITM) de Bluetooth con una clave de paso proporcionada por el usuario utilizando la consola durante el emparejamiento.

En general, cuando se realiza una solicitud para invocar alguna funcionalidad, un manipulador correspondiente realiza las tareas específicas de la aplicación, teniendo en cuenta tanto las características definidas como los requisitos de acceso seguro. Para el ejemplo de parpadeo del LED, cuando se realiza una solicitud para realizar la función de parpadeo del LED, el código real para garantizar el permiso y autorizar el acceso es bastante simple.

Para cambiar el valor de la característica de parpadeo del LED (HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL), el código usa una declaración condicional que confirma tanto el permiso de escritura como la autorización de acceso (Listado 2). Para el permiso de escritura, el condicional compara el permiso solicitado (LEGATTDB_PERM_AUTH_WRITABLE) con la configuración de permiso de parpadeo del dispositivo LED real, LED_BLINK_CHAR_PERMISSION (definido en la parte superior del Listado 1b). Para la autorización, el condicional comprueba que el nivel de seguridad emparejado actual (paired_security_level) se haya creado con el emparejamiento de MITM (BTM_SEC_LINK_PAIRED_WITH_MITM) (Listado 2).

Copiar 

/*

* Solicitud de escritura de proceso o comando de escritura desde un dispositivo similar

*/

wiced_bt_gatt_status_t hello_sensor_gatts_req_write_handler( uint16_t conn_id, wiced_bt_gatt_write_t * p_data )

{

wiced_bt_gatt_status_t result    = WICED_BT_GATT_SUCCESS;

uint8_t                *p_attr   = p_data->p_val;

 

uint8_t sec_flag, key_size;

WICED_BT_TRACE("write_handler: conn_id:%d hdl:0x%x prep:%d offset:%d len:%d\r\n ", conn_id, p_data->handle, p_data->is_prep, p_data->offset, p_data->val_len );

 

switch ( p_data->handle )

{

 

.

.

.

 

case HANDLE_HSENS_SERVICE_CHAR_TEMP_CFG_DESC:

if ( p_data->val_len != 2 )

{

return WICED_BT_GATT_INVALID_ATTR_LEN;

}

WICED_BT_TRACE( "Temp Notif Enabled\r\n");

 

hello_sensor_hostinfo.temp_characteristic_client_configuration = p_attr[0] | ( p_attr[1] << 8 );

break;

 

case HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL:

 

if ( p_data->val_len != 1 )

{

return WICED_BT_GATT_INVALID_ATTR_LEN;

}

 

 

if ((!(paired_security_level & BTM_SEC_LINK_PAIRED_WITH_MITM))&& (LED_BLINK_CHAR_PERMISSION & LEGATTDB_PERM_AUTH_WRITABLE))

{

WICED_BT_TRACE("Write Failed: Insufficient Authentication\r\n");

return WICED_BT_GATT_INSUF_AUTHENTICATION;

}

 

hello_sensor_hostinfo.number_of_blinks = p_attr[0];

if ( hello_sensor_hostinfo.number_of_blinks != 0 )

{

WICED_BT_TRACE( "hello_sensor_write_handler:num blinks: %d\r\n", hello_sensor_hostinfo.number_of_blinks );

wiced_bt_app_hal_led_blink(250, 250, hello_sensor_hostinfo.number_of_blinks );

}

break;

 

default:

result = WICED_BT_GATT_INVALID_HANDLE;

break;

}

 

return result;

}

Listado 2: En este fragmento de la aplicación Cypress BLE Secure Hub, la solicitud para realizar la característica de parpadeo de LED primero debe pasar una marca (resaltada) para obtener permiso y autorización de seguridad. (Fuente de código: Cypress Semiconductor)

Usando definiciones de la base de datos GATT y el código de apoyo apropiado para el proyecto de sensor y el proyecto del concentrador, esta aplicación de muestra proporciona a los desarrolladores los patrones de diseño básicos asociados con tres niveles de seguridad diferentes, incluso cualquier nivel de emparejamiento, el emparejamiento de MITM aquí descrito y el emparejamiento de Bluetooth LE Secure. El último método de emparejamiento ofrece la mayor seguridad, utilizando un método de autenticación basado en el intercambio de claves Elifftic Curve Diffie-Hellman (ECDH). Debido a que el motor de seguridad integrado del CYW20719 incluye un acelerador ECDH, los desarrolladores pueden implementar este enfoque sin comprometer el rendimiento.

Conclusión

La disponibilidad de MCU inalámbricas integradas habilitadas para Bluetooth ha ayudado a los desarrolladores a acelerar la integración de estos dispositivos en sus diseños. Sin embargo, para implementar redes seguras de Bluetooth, los desarrolladores se enfrentan a múltiples desafíos al crear servicios compatibles con Bluetooth y escribir aplicaciones capaces de usar esos dispositivos de forma segura.

Basados en Cypress CYW20719 Bluetooth MCU, el kit de evaluación Bluetooth del kit Cypress Semiconductor CYW920719Q40EVB-01 y el entorno de desarrollo WICED proporcionan una plataforma completa para construir estas aplicaciones. Usando los kits y el entorno WICED junto con el paquete Cypress BLE Secure Hub, los desarrolladores pueden evaluar rápidamente las aplicaciones seguras de Bluetooth y ampliarlas rápidamente a aplicaciones personalizadas que aprovechen la velocidad y el alcance mejorados de Bluetooth 5.

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