1. Introducción
Nest es una implementación de código abierto del protocolo de red Thread® que lanzó OpenThread. Nest lanzó OpenThread para que la tecnología que se usa en sus productos esté ampliamente disponible para que los desarrolladores aceleren el desarrollo de productos para el hogar conectado.
La especificación de Thread define un protocolo de comunicación de dispositivo a dispositivo inalámbrico, seguro y de bajo consumo basado en IPv6 para aplicaciones domésticas. OpenThread implementa todas las capas de red de Thread, incluidas IPv6, 6LoWPAN, IEEE 802.15.4 con seguridad MAC, establecimiento de vínculos de malla y enrutamiento de malla.
En este codelab, usarás las APIs de OpenThread para iniciar una red Thread, supervisar los cambios en los roles de los dispositivos y reaccionar ante ellos, y enviar mensajes UDP. Además, vincularás estas acciones a botones y luces LED en hardware real.
Qué aprenderás
- Cómo programar los botones y las luces LED en las placas de desarrollo nórdicas nRF52840
- Cómo usar las APIs comunes de OpenThread y la clase
otInstance
- Cómo supervisar los cambios de estado de OpenThread y reaccionar ante ellos
- Cómo enviar mensajes UDP a todos los dispositivos de una red Thread
- Cómo modificar archivos makefile
Requisitos
Hardware:
- 3 placas de desarrollo Nordic Semiconductor nRF52840
- 3 cables USB a micro USB para conectar las placas
- Una máquina Linux con al menos 3 puertos USB
Software:
- Cadena de herramientas GNU
- Herramientas de línea de comandos nRF5x nórdicas
- Software de Segger J-Link
- OpenThread
- Git
A menos que se indique lo contrario, el contenido de este codelab está registrado bajo la Licencia Creative Commons Atribución 3.0 y las muestras de códigos están registradas bajo la Licencia Apache 2.0.
2. Cómo comenzar
Completa el codelab de hardware
Antes de comenzar este codelab, debes completar el codelab Build a Thread Network with nRF52840 Boards and OpenThread, que hace lo siguiente:
- Detalla todo el software que necesitas para la compilación y la escritura en la memoria flash
- Te enseña a compilar OpenThread y a escribirlo en la memoria flash de las placas Nordic nRF52840.
- Demuestra los conceptos básicos de una red Thread
En este codelab, no se requiere ninguna configuración del entorno para compilar OpenThread y escribir en la memoria flash de las placas, sino solo instrucciones básicas para escribir en la memoria flash de las placas. Se da por sentado que ya completaste el codelab Cómo compilar una red de subprocesos.
Máquina Linux
Este codelab se diseñó para usar una máquina Linux basada en i386 o x86 para escribir en la memoria flash todas las placas de desarrollo Thread. Todos los pasos se probaron en Ubuntu 14.04.5 LTS (Trusty Tahr).
Placas Nordic Semiconductor nRF52840
En este codelab, se usan tres placas de PDK nRF52840.
Instale el software
Para compilar e instalar OpenThread, debes instalar SEGGER J-Link, las herramientas de línea de comandos nRF5x, la cadena de herramientas ARM GNU y varios paquetes de Linux. Si completaste el codelab Cómo compilar una red de Thread según sea necesario, ya tendrás todo lo que necesitas instalado. De lo contrario, completa ese codelab antes de continuar para asegurarte de que puedes compilar e instalar OpenThread en las placas de desarrollo nRF52840.
3. Clona el repositorio
OpenThread incluye un código de aplicación de ejemplo que puedes usar como punto de partida para este codelab.
Clona el repositorio de ejemplos de OpenThread Nordic nRF528xx y compila OpenThread:
$ git clone --recursive https://github.com/openthread/ot-nrf528xx $ cd ot-nrf528xx $ ./script/bootstrap
4. Conceptos básicos de la API de OpenThread
Las APIs públicas de OpenThread se encuentran en ./openthread/include/openthread
, en el repositorio de OpenThread. Estas API proporcionan acceso a una variedad de características y funcionalidades de OpenThread a nivel de Thread y de plataforma para usarlas en tus aplicaciones:
- Información y control de la instancia de OpenThread
- Servicios de aplicaciones como IPv6, UDP y CoAP
- Administración de credenciales de red, junto con funciones de comisionado y combinador
- Administración del router de borde
- Funciones mejoradas como Supervisión infantil y Detección de Jams
La información de referencia sobre todas las APIs de OpenThread está disponible en openthread.io/reference.
Usa una API
Para usar una API, incluye su archivo de encabezado en uno de los archivos de tu aplicación. Luego, llama a la función deseada.
Por ejemplo, la app de ejemplo de la CLI incluida con OpenThread usa los siguientes encabezados de API:
./openthread/examples/apps/cli/main.c
#include <openthread/config.h> #include <openthread/cli.h> #include <openthread/diag.h> #include <openthread/tasklet.h> #include <openthread/platform/logging.h>
La instancia de OpenThread
La estructura de otInstance
es algo que usarás con frecuencia cuando trabajes con las APIs de OpenThread. Una vez inicializada, esta estructura representa una instancia estática de la biblioteca de OpenThread y permite al usuario realizar llamadas a la API de OpenThread.
Por ejemplo, la instancia de OpenThread se inicializa en la función main()
de la app de ejemplo de la CLI:
./openthread/examples/apps/cli/main.c
int main(int argc, char *argv[]) { otInstance *instance ... #if OPENTHREAD_ENABLE_MULTIPLE_INSTANCES // Call to query the buffer size (void)otInstanceInit(NULL, &otInstanceBufferLength); // Call to allocate the buffer otInstanceBuffer = (uint8_t *)malloc(otInstanceBufferLength); assert(otInstanceBuffer); // Initialize OpenThread with the buffer instance = otInstanceInit(otInstanceBuffer, &otInstanceBufferLength); #else instance = otInstanceInitSingle(); #endif ... return 0; }
Funciones específicas de la plataforma
Si quieres agregar funciones específicas de la plataforma a una de las aplicaciones de ejemplo incluidas con OpenThread, primero decláralas en el encabezado ./openthread/examples/platforms/openthread-system.h
con el espacio de nombres otSys
para todas las funciones. Luego, impleméntalas en un archivo de origen específico de la plataforma. De esta manera, puedes usar los mismos encabezados de función para otras plataformas de ejemplo.
Por ejemplo, las funciones GPIO que usaremos para conectar a los botones y los LED nRF52840 deben declararse en openthread-system.h
.
Abre el archivo ./openthread/examples/platforms/openthread-system.h
en tu editor de texto preferido.
./openthread/examples/platforms/openthread-system.h
ACCIÓN: Agrega declaraciones de funciones GPIO específicas de la plataforma.
Agrega estas declaraciones de función después de #include
para el encabezado openthread/instance.h
:
/** * Init LED module. * */ void otSysLedInit(void); void otSysLedSet(uint8_t aLed, bool aOn); void otSysLedToggle(uint8_t aLed); /** * A callback will be called when GPIO interrupts occur. * */ typedef void (*otSysButtonCallback)(otInstance *aInstance); void otSysButtonInit(otSysButtonCallback aCallback); void otSysButtonProcess(otInstance *aInstance);
Los implementaremos en el siguiente paso.
Ten en cuenta que la declaración de la función otSysButtonProcess
usa un otInstance
. De esa manera, la aplicación puede acceder a la información sobre la instancia de OpenThread cuando se presiona un botón, si es necesario. Todo depende de las necesidades de tu aplicación. Si no la necesitas en la implementación de la función, puedes usar la macro OT_UNUSED_VARIABLE
de la API de OpenThread para suprimir los errores de compilación alrededor de variables sin usar para algunas cadenas de herramientas. Veremos ejemplos de esto más adelante.
5. Implementa la abstracción de la plataforma GPIO
En el paso anterior, repasamos las declaraciones de funciones específicas de la plataforma en ./openthread/examples/platforms/openthread-system.h
que se pueden usar para GPIO. Para acceder a los botones y las luces LED de las placas de desarrollo nRF52840, debes implementar esas funciones para la plataforma nRF52840. En este código, agregarás funciones que hacen lo siguiente:
- Inicializa los pines y modos de GPIO
- Cómo controlar el voltaje en un pin
- Habilita las interrupciones de GPIO y registra una devolución de llamada
En el directorio ./src/src
, crea un archivo nuevo llamado gpio.c
. En este archivo nuevo, agrega el siguiente contenido.
./src/src/gpio.c (archivo nuevo)
ACCIÓN: Agregar define.
Estas definiciones sirven como abstracciones entre los valores específicos de nRF52840 y las variables usadas en el nivel de la aplicación de OpenThread.
/** * @file * This file implements the system abstraction for GPIO and GPIOTE. * */ #define BUTTON_GPIO_PORT 0x50000300UL #define BUTTON_PIN 11 // button #1 #define GPIO_LOGIC_HI 0 #define GPIO_LOGIC_LOW 1 #define LED_GPIO_PORT 0x50000300UL #define LED_1_PIN 13 // turn on to indicate leader role #define LED_2_PIN 14 // turn on to indicate router role #define LED_3_PIN 15 // turn on to indicate child role #define LED_4_PIN 16 // turn on to indicate UDP receive
Para obtener más información sobre los botones y los LED de nRF52840, consulta el Centro de información de Semiconductors nórdicos.
ACCIÓN: Agregar encabezados incl.
A continuación, agrega las inclusiones de encabezado que necesitarás para la funcionalidad GPIO.
/* Header for the functions defined here */ #include "openthread-system.h" #include <string.h> /* Header to access an OpenThread instance */ #include <openthread/instance.h> /* Headers for lower-level nRF52840 functions */ #include "platform-nrf5.h" #include "hal/nrf_gpio.h" #include "hal/nrf_gpiote.h" #include "nrfx/drivers/include/nrfx_gpiote.h"
ACCIÓN: Agrega funciones de devolución de llamada y de interrupción para el Botón 1.
Agrega este código a continuación. La función in_pin1_handler
es la devolución de llamada que se registra cuando se inicializa la funcionalidad de presionar el botón (más adelante en este archivo).
Observa cómo esta devolución de llamada usa la macro OT_UNUSED_VARIABLE
, ya que las variables que se pasan a in_pin1_handler
no se usan realmente en la función.
/* Declaring callback function for button 1. */ static otSysButtonCallback sButtonHandler; static bool sButtonPressed; /** * @brief Function to receive interrupt and call back function * set by the application for button 1. * */ static void in_pin1_handler(uint32_t pin, nrf_gpiote_polarity_t action) { OT_UNUSED_VARIABLE(pin); OT_UNUSED_VARIABLE(action); sButtonPressed = true; }
ACCIÓN: Agrega una función para configurar las luces LED.
Agrega este código para configurar el modo y el estado de todos los LED durante la inicialización.
/** * @brief Function for configuring: PIN_IN pin for input, PIN_OUT pin for output, * and configures GPIOTE to give an interrupt on pin change. */ void otSysLedInit(void) { /* Configure GPIO mode: output */ nrf_gpio_cfg_output(LED_1_PIN); nrf_gpio_cfg_output(LED_2_PIN); nrf_gpio_cfg_output(LED_3_PIN); nrf_gpio_cfg_output(LED_4_PIN); /* Clear all output first */ nrf_gpio_pin_write(LED_1_PIN, GPIO_LOGIC_LOW); nrf_gpio_pin_write(LED_2_PIN, GPIO_LOGIC_LOW); nrf_gpio_pin_write(LED_3_PIN, GPIO_LOGIC_LOW); nrf_gpio_pin_write(LED_4_PIN, GPIO_LOGIC_LOW); /* Initialize gpiote for button(s) input. Button event handlers are set in the application (main.c) */ ret_code_t err_code; err_code = nrfx_gpiote_init(); APP_ERROR_CHECK(err_code); }
ACCIÓN: Agrega una función para establecer el modo de una luz LED.
Esta función se usará cuando cambie el rol del dispositivo.
/** * @brief Function to set the mode of an LED. */ void otSysLedSet(uint8_t aLed, bool aOn) { switch (aLed) { case 1: nrf_gpio_pin_write(LED_1_PIN, (aOn == GPIO_LOGIC_HI)); break; case 2: nrf_gpio_pin_write(LED_2_PIN, (aOn == GPIO_LOGIC_HI)); break; case 3: nrf_gpio_pin_write(LED_3_PIN, (aOn == GPIO_LOGIC_HI)); break; case 4: nrf_gpio_pin_write(LED_4_PIN, (aOn == GPIO_LOGIC_HI)); break; } }
ACCIÓN: Agrega una función para activar o desactivar el modo de una luz LED.
Esta función se utilizará para activar o desactivar el LED4 cuando el dispositivo reciba un mensaje UDP multidifusión.
/** * @brief Function to toggle the mode of an LED. */ void otSysLedToggle(uint8_t aLed) { switch (aLed) { case 1: nrf_gpio_pin_toggle(LED_1_PIN); break; case 2: nrf_gpio_pin_toggle(LED_2_PIN); break; case 3: nrf_gpio_pin_toggle(LED_3_PIN); break; case 4: nrf_gpio_pin_toggle(LED_4_PIN); break; } }
ACCIÓN: Agrega funciones para inicializar y procesar las presiones de botones.
La primera función inicializa el tablero cuando se presiona un botón y la segunda envía el mensaje UDP multidifusión cuando se presiona el Botón 1.
/** * @brief Function to initialize the button. */ void otSysButtonInit(otSysButtonCallback aCallback) { nrfx_gpiote_in_config_t in_config = NRFX_GPIOTE_CONFIG_IN_SENSE_LOTOHI(true); in_config.pull = NRF_GPIO_PIN_PULLUP; ret_code_t err_code; err_code = nrfx_gpiote_in_init(BUTTON_PIN, &in_config, in_pin1_handler); APP_ERROR_CHECK(err_code); sButtonHandler = aCallback; sButtonPressed = false; nrfx_gpiote_in_event_enable(BUTTON_PIN, true); } void otSysButtonProcess(otInstance *aInstance) { if (sButtonPressed) { sButtonPressed = false; sButtonHandler(aInstance); } }
ACCIÓN: Guarda y cierra el archivo gpio.c
.
6. API: Reacciona a los cambios de rol del dispositivo
En nuestra aplicación, queremos que se enciendan diferentes LED según el rol del dispositivo. Hagamos un seguimiento de los siguientes roles: líder, router, dispositivo final. Podemos asignarlos a LED de la siguiente manera:
- LED1 = líder
- LED2 = Router
- LED3 = Dispositivo final
Para habilitar esta funcionalidad, la aplicación debe saber cuándo cambió la función del dispositivo y cómo encender el LED correcto en respuesta. Para la primera parte, usaremos la instancia de OpenThread y la abstracción de la plataforma GPIO para la segunda.
Abre el archivo ./openthread/examples/apps/cli/main.c
en tu editor de texto preferido.
./openthread/examples/apps/cli/main.c
ACCIÓN: Agregar encabezados incl.
En la sección de inclusiones del archivo main.c
, agrega los archivos de encabezado de la API que necesitarás para la función de cambio de rol.
#include <openthread/instance.h> #include <openthread/thread.h> #include <openthread/thread_ftd.h>
ACCIÓN: Agrega la declaración de función de controlador para el cambio de estado de la instancia de OpenThread.
Agrega esta declaración a main.c
, después de que el encabezado incluya las sentencias #if
y antes de ella. Esta función se definirá después de la aplicación principal.
void handleNetifStateChanged(uint32_t aFlags, void *aContext);
ACCIÓN: Agrega un registro de devolución de llamada para la función del controlador de cambio de estado.
En main.c
, agrega esta función a la función main()
después de la llamada otAppCliInit
. Este registro de devolución de llamada le indica a OpenThread que llame a la función handleNetifStateChange
cada vez que cambie el estado de la instancia de OpenThread.
/* Register Thread state change handler */ otSetStateChangedCallback(instance, handleNetifStateChanged, instance);
ACCIÓN: Agrega la implementación del cambio de estado.
En main.c
, después de la función main()
, implementa la función handleNetifStateChanged
. Esta función verifica la marca OT_CHANGED_THREAD_ROLE
de la instancia de OpenThread y, si cambió, enciende o apaga las luces LED según sea necesario.
void handleNetifStateChanged(uint32_t aFlags, void *aContext) { if ((aFlags & OT_CHANGED_THREAD_ROLE) != 0) { otDeviceRole changedRole = otThreadGetDeviceRole(aContext); switch (changedRole) { case OT_DEVICE_ROLE_LEADER: otSysLedSet(1, true); otSysLedSet(2, false); otSysLedSet(3, false); break; case OT_DEVICE_ROLE_ROUTER: otSysLedSet(1, false); otSysLedSet(2, true); otSysLedSet(3, false); break; case OT_DEVICE_ROLE_CHILD: otSysLedSet(1, false); otSysLedSet(2, false); otSysLedSet(3, true); break; case OT_DEVICE_ROLE_DETACHED: case OT_DEVICE_ROLE_DISABLED: /* Clear LED4 if Thread is not enabled. */ otSysLedSet(4, false); break; } } }
7. API: Usa la multidifusión para encender una luz LED
En nuestra aplicación, también queremos enviar mensajes UDP a todos los demás dispositivos de la red cuando se presiona Button1 en una placa. Para confirmar la recepción del mensaje, se activará el LED4 en las otras placas como respuesta.
Para habilitar esta funcionalidad, la aplicación debe hacer lo siguiente:
- Inicializa una conexión UDP cuando se inicia
- Poder enviar un mensaje UDP a la dirección de multidifusión local de la malla
- Maneja mensajes UDP entrantes
- Activar o desactivar LED4 en respuesta a mensajes UDP entrantes
Abre el archivo ./openthread/examples/apps/cli/main.c
en tu editor de texto preferido.
./openthread/examples/apps/cli/main.c
ACCIÓN: Agregar encabezados incl.
En la sección de inclusiones, en la parte superior del archivo main.c
, agrega los archivos de encabezado de la API que necesitarás para la función UDP multicast.
#include <string.h> #include <openthread/message.h> #include <openthread/udp.h> #include "utils/code_utils.h"
El encabezado code_utils.h
se usa para las macros otEXPECT
y otEXPECT_ACTION
que validan las condiciones de tiempo de ejecución y manejan errores de forma correcta.
ACCIÓN: Agrega definiciones y constantes:
En el archivo main.c
, después de la sección inclusiones y antes de cualquier sentencia #if
, agrega constantes específicas de UDP y define lo siguiente:
#define UDP_PORT 1212 static const char UDP_DEST_ADDR[] = "ff03::1"; static const char UDP_PAYLOAD[] = "Hello OpenThread World!";
ff03::1
es la dirección de multidifusión local de malla. Los mensajes que se envíen a esta dirección se enviarán a todos los dispositivos de subproceso completo de la red. Consulta Multicast en openthread.io para obtener más información sobre la compatibilidad con multicast en OpenThread.
ACCIÓN: Agrega declaraciones de funciones.
En el archivo main.c
, después de la definición de otTaskletsSignalPending
y antes de la función main()
, agrega funciones específicas de UDP, así como una variable estática para representar un socket UDP:
static void initUdp(otInstance *aInstance); static void sendUdp(otInstance *aInstance); static void handleButtonInterrupt(otInstance *aInstance); void handleUdpReceive(void *aContext, otMessage *aMessage, const otMessageInfo *aMessageInfo); static otUdpSocket sUdpSocket;
ACCIÓN: Agrega llamadas para inicializar los LED y el botón de GPIO.
En main.c
, agrega estas llamadas a la función main()
después de la llamada otSetStateChangedCallback
. Estas funciones inicializan los pines GPIO y GPIOTE, y configuran un controlador de botones para controlar los eventos de presión de botones.
/* init GPIO LEDs and button */ otSysLedInit(); otSysButtonInit(handleButtonInterrupt);
ACCIÓN: Agrega la llamada de inicialización UDP.
En main.c
, agrega esta función a la función main()
después de la llamada otSysButtonInit
que acabas de agregar:
initUdp(instance);
Esta llamada garantiza que se inicialice un socket UDP cuando se inicie la aplicación. Sin esto, el dispositivo no puede enviar ni recibir mensajes UDP.
ACCIÓN: Agrega una llamada para procesar el evento del botón GPIO.
En main.c
, agrega esta llamada a la función main()
después de la llamada otSysProcessDrivers
, en el bucle while
. Esta función, declarada en gpio.c
, verifica si se presionó el botón y, de ser así, llama al controlador (handleButtonInterrupt
) que se configuró en el paso anterior.
otSysButtonProcess(instance);
ACCIÓN: Implementa el controlador de interrupción del botón.
En main.c
, agrega la implementación de la función handleButtonInterrupt
después de la función handleNetifStateChanged
que agregaste en el paso anterior:
/** * Function to handle button push event */ void handleButtonInterrupt(otInstance *aInstance) { sendUdp(aInstance); }
ACCIÓN: Implementa la inicialización de UDP.
En main.c
, agrega la implementación de la función initUdp
después de la función handleButtonInterrupt
que acabas de agregar:
/** * Initialize UDP socket */ void initUdp(otInstance *aInstance) { otSockAddr listenSockAddr; memset(&sUdpSocket, 0, sizeof(sUdpSocket)); memset(&listenSockAddr, 0, sizeof(listenSockAddr)); listenSockAddr.mPort = UDP_PORT; otUdpOpen(aInstance, &sUdpSocket, handleUdpReceive, aInstance); otUdpBind(aInstance, &sUdpSocket, &listenSockAddr, OT_NETIF_THREAD); }
UDP_PORT
es el puerto que definiste antes (1212). La función otUdpOpen
abre el socket y registra una función de devolución de llamada (handleUdpReceive
) para cuando se recibe un mensaje UDP. otUdpBind
vincula el socket a la interfaz de red de Thread mediante el paso OT_NETIF_THREAD
. Para obtener otras opciones de interfaz de red, consulta la enumeración otNetifIdentifier
en la Referencia de la API de UDP.
ACCIÓN: Implementa la mensajería UDP.
En main.c
, agrega la implementación de la función sendUdp
después de la función initUdp
que acabas de agregar:
/** * Send a UDP datagram */ void sendUdp(otInstance *aInstance) { otError error = OT_ERROR_NONE; otMessage * message; otMessageInfo messageInfo; otIp6Address destinationAddr; memset(&messageInfo, 0, sizeof(messageInfo)); otIp6AddressFromString(UDP_DEST_ADDR, &destinationAddr); messageInfo.mPeerAddr = destinationAddr; messageInfo.mPeerPort = UDP_PORT; message = otUdpNewMessage(aInstance, NULL); otEXPECT_ACTION(message != NULL, error = OT_ERROR_NO_BUFS); error = otMessageAppend(message, UDP_PAYLOAD, sizeof(UDP_PAYLOAD)); otEXPECT(error == OT_ERROR_NONE); error = otUdpSend(aInstance, &sUdpSocket, message, &messageInfo); exit: if (error != OT_ERROR_NONE && message != NULL) { otMessageFree(message); } }
Observa las macros otEXPECT
y otEXPECT_ACTION
. Estos garantizan que el mensaje UDP sea válido y esté asignado de forma correcta en el búfer y, si no es así, la función maneja los errores correctamente saltando al bloque exit
, donde se libera el búfer.
Consulta las referencias de IPv6 y UDP en openthread.io para obtener más información sobre las funciones que se usan para inicializar UDP.
ACCIÓN: Implementa el manejo de mensajes UDP.
En main.c
, agrega la implementación de la función handleUdpReceive
después de la función sendUdp
que acabas de agregar. Esta función simplemente activa o desactiva LED4.
/** * Function to handle UDP datagrams received on the listening socket */ void handleUdpReceive(void *aContext, otMessage *aMessage, const otMessageInfo *aMessageInfo) { OT_UNUSED_VARIABLE(aContext); OT_UNUSED_VARIABLE(aMessage); OT_UNUSED_VARIABLE(aMessageInfo); otSysLedToggle(4); }
8. API: Cómo configurar la red Thread
Para facilitar la demostración, queremos que nuestros dispositivos inicien Thread de inmediato y se unan a una red cuando estén encendidos. Para ello, usaremos la estructura otOperationalDataset
. Esta estructura contiene todos los parámetros necesarios para transmitir las credenciales de la red Thread a un dispositivo.
El uso de esta estructura anulará los valores predeterminados de la red integrados en OpenThread para que nuestra aplicación sea más segura y limitar los nodos de Thread en la red solo a los que la ejecuten.
Vuelve a abrir el archivo ./openthread/examples/apps/cli/main.c
en tu editor de texto preferido.
./openthread/examples/apps/cli/main.c
ACCIÓN: Agrega la inclusión del encabezado.
En la sección de inclusiones ubicada en la parte superior del archivo main.c
, agrega el archivo de encabezado de la API que necesitarás para configurar la red de Thread:
#include <openthread/dataset_ftd.h>
ACCIÓN: Agrega la declaración de función para establecer la configuración de red.
Agrega esta declaración a main.c
, después de que el encabezado incluya las sentencias #if
y antes de ella. Esta función se definirá después de la función principal de la aplicación.
static void setNetworkConfiguration(otInstance *aInstance);
ACCIÓN: Agrega la llamada de configuración de red.
En main.c
, agrega esta llamada a función a la función main()
después de la llamada otSetStateChangedCallback
. Esta función configura el conjunto de datos de red Thread.
/* Override default network credentials */ setNetworkConfiguration(instance);
ACCIÓN: Agrega llamadas para habilitar la interfaz y la pila de red de Thread.
En main.c
, agrega estas llamadas a la función main()
después de la llamada otSysButtonInit
.
/* Start the Thread network interface (CLI cmd > ifconfig up) */ otIp6SetEnabled(instance, true); /* Start the Thread stack (CLI cmd > thread start) */ otThreadSetEnabled(instance, true);
ACCIÓN: Implementa la configuración de red Thread.
En main.c
, agrega la implementación de la función setNetworkConfiguration
después de la función main()
:
/** * Override default network settings, such as panid, so the devices can join a network */ void setNetworkConfiguration(otInstance *aInstance) { static char aNetworkName[] = "OTCodelab"; otOperationalDataset aDataset; memset(&aDataset, 0, sizeof(otOperationalDataset)); /* * Fields that can be configured in otOperationDataset to override defaults: * Network Name, Mesh Local Prefix, Extended PAN ID, PAN ID, Delay Timer, * Channel, Channel Mask Page 0, Network Key, PSKc, Security Policy */ aDataset.mActiveTimestamp.mSeconds = 1; aDataset.mActiveTimestamp.mTicks = 0; aDataset.mActiveTimestamp.mAuthoritative = false; aDataset.mComponents.mIsActiveTimestampPresent = true; /* Set Channel to 15 */ aDataset.mChannel = 15; aDataset.mComponents.mIsChannelPresent = true; /* Set Pan ID to 2222 */ aDataset.mPanId = (otPanId)0x2222; aDataset.mComponents.mIsPanIdPresent = true; /* Set Extended Pan ID to C0DE1AB5C0DE1AB5 */ uint8_t extPanId[OT_EXT_PAN_ID_SIZE] = {0xC0, 0xDE, 0x1A, 0xB5, 0xC0, 0xDE, 0x1A, 0xB5}; memcpy(aDataset.mExtendedPanId.m8, extPanId, sizeof(aDataset.mExtendedPanId)); aDataset.mComponents.mIsExtendedPanIdPresent = true; /* Set network key to 1234C0DE1AB51234C0DE1AB51234C0DE */ uint8_t key[OT_NETWORK_KEY_SIZE] = {0x12, 0x34, 0xC0, 0xDE, 0x1A, 0xB5, 0x12, 0x34, 0xC0, 0xDE, 0x1A, 0xB5, 0x12, 0x34, 0xC0, 0xDE}; memcpy(aDataset.mNetworkKey.m8, key, sizeof(aDataset.mNetworkKey)); aDataset.mComponents.mIsNetworkKeyPresent = true; /* Set Network Name to OTCodelab */ size_t length = strlen(aNetworkName); assert(length <= OT_NETWORK_NAME_MAX_SIZE); memcpy(aDataset.mNetworkName.m8, aNetworkName, length); aDataset.mComponents.mIsNetworkNamePresent = true; otDatasetSetActive(aInstance, &aDataset); /* Set the router selection jitter to override the 2 minute default. CLI cmd > routerselectionjitter 20 Warning: For demo purposes only - not to be used in a real product */ uint8_t jitterValue = 20; otThreadSetRouterSelectionJitter(aInstance, jitterValue); }
Como se detalla en la función, los parámetros de red de Thread que usamos para esta aplicación son los siguientes:
- Canal = 15
- ID PAN = 0x2222
- ID de número PAN extendido = C0DE1AB5C0DE1AB5
- Clave de red = 1234C0DE1AB51234C0DE1AB51234C0DE
- Nombre de la red = OTCodelab
Además, aquí es donde disminuimos el Jitter de selección de router, de modo que nuestros dispositivos cambien de roles más rápido para fines de demostración. Ten en cuenta que esto solo se hace si el nodo es un FTD (dispositivo de subproceso completo). Más información sobre esto en el siguiente paso.
9. API: Funciones restringidas
Algunas de las APIs de OpenThread modifican la configuración que solo debe modificarse con fines de demostración o prueba. Estas APIs no deben usarse en una implementación de producción de una aplicación con OpenThread.
Por ejemplo, la función otThreadSetRouterSelectionJitter
ajusta el tiempo (en segundos) que tarda un dispositivo final en convertirse en un router. El valor predeterminado es 120, según la especificación del subproceso. Para facilitar su uso en este codelab, lo cambiaremos a 20, por lo que no tendrás que esperar mucho tiempo a que un nodo de subproceso cambie de función.
Nota: Los dispositivos MTD no se convierten en routers, y la compatibilidad con una función como otThreadSetRouterSelectionJitter
no está incluida en una compilación de MTD. Más adelante, necesitaremos especificar la opción -DOT_MTD=OFF
de CMake; de lo contrario, tendremos un error de compilación.
Para confirmarlo, observa la definición de la función otThreadSetRouterSelectionJitter
, que se encuentra dentro de una directiva del preprocesador de OPENTHREAD_FTD
:
./openthread/src/core/api/thread_ftd_api.cpp
#if OPENTHREAD_FTD #include <openthread/thread_ftd.h> ... void otThreadSetRouterSelectionJitter(otInstance *aInstance, uint8_t aRouterJitter) { Instance &instance = *static_cast<Instance *>(aInstance); instance.GetThreadNetif().GetMle().SetRouterSelectionJitter(aRouterJitter); } ... #endif // OPENTHREAD_FTD
10. Actualizaciones de CMake
Antes de compilar tu aplicación, debes realizar algunas actualizaciones menores para tres archivos CMake. El sistema de compilación los utiliza para compilar y vincular tu aplicación.
./third_party/NordicSemiconductor/CMakeLists.txt
Ahora, agrega algunas marcas al CMakeLists.txt
de NordicSemiconductor para asegurarte de que las funciones GPIO se definan en la aplicación.
ACCIÓN: Agrega marcas al archivo CMakeLists.txt
.
Abre ./third_party/NordicSemiconductor/CMakeLists.txt
en tu editor de texto preferido y agrega las siguientes líneas en la sección COMMON_FLAG
.
... set(COMMON_FLAG -DSPIS_ENABLED=1 -DSPIS0_ENABLED=1 -DNRFX_SPIS_ENABLED=1 -DNRFX_SPIS0_ENABLED=1 ... # Defined in ./third_party/NordicSemiconductor/nrfx/templates/nRF52840/nrfx_config.h -DGPIOTE_ENABLED=1 -DGPIOTE_CONFIG_IRQ_PRIORITY=7 -DGPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS=1 ) ...
./src/CMakeLists.txt
Edita el archivo ./src/CMakeLists.txt
para agregar el nuevo archivo fuente gpio.c
:
ACCIÓN: Agrega la fuente de gpio al archivo ./src/CMakeLists.txt
.
Abre ./src/CMakeLists.txt
en tu editor de texto preferido y agrega el archivo a la sección NRF_COMM_SOURCES
.
... set(NRF_COMM_SOURCES ... src/gpio.c ... ) ...
./third_party/NordicSemiconductor/CMakeLists.txt
Por último, agrega el archivo de controlador nrfx_gpiote.c
al archivo CMakeLists.txt
de NordicSemiconductor para que se incluya en la compilación de la biblioteca de los controladores nórdicos.
ACCIÓN: Agrega el controlador de gpio al archivo CMakeLists.txt
NordicSemiconductor.
Abre ./third_party/NordicSemiconductor/CMakeLists.txt
en tu editor de texto preferido y agrega el archivo a la sección COMMON_SOURCES
.
... set(COMMON_SOURCES ... nrfx/drivers/src/nrfx_gpiote.c ... ) ...
11. Configura los dispositivos
Una vez finalizadas todas las actualizaciones de código, está todo listo para compilar y escribir en la memoria flash la aplicación en las tres placas de desarrollo nRF52840 de Nordic. Cada dispositivo funcionará como un dispositivo de Thread completo (FTD).
Compila OpenThread
Compila los objetos binarios de OpenThread FTD para la plataforma nRF52840.
$ cd ~/ot-nrf528xx $ ./script/build nrf52840 UART_trans -DOT_MTD=OFF -DOT_APP_RCP=OFF -DOT_RCP=OFF
Navega al directorio con el objeto binario de la CLI de OpenThread FTD y conviértelo en formato hexadecimal con la cadena de herramientas incorporadas de ARM:
$ cd build/bin $ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex
Prende el juego
Escribe el archivo ot-cli-ftd.hex
en la memoria flash de cada placa nRF52840.
Conecta el cable USB al puerto de depuración micro-USB junto al pin de alimentación externo en la placa nRF52840 y conéctalo a la máquina Linux. Configura la opción correctamente, significa que la luz LED5 está encendida.
Al igual que antes, toma nota del número de serie de la placa nRF52840:
Dirígete a la ubicación de las herramientas de línea de comandos nRFx y escribe el archivo hexadecimal FTD de la CLI de OpenThread en la placa nRF52840 con el número de serie de la placa:
$ cd ~/nrfjprog $ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \ ~/openthread/output/nrf52840/bin/ot-cli-ftd.hex --reset
El LED 5 se apagará brevemente durante el destello. Si se ejecuta de forma correcta, se genera el siguiente resultado:
Parsing hex file. Erasing user available code and UICR flash areas. Applying system reset. Checking that the area to write is not protected. Programing device. Applying system reset. Run.
Repite este mensaje: "Escribe la memoria en los tableros". para las otras dos pizarras. Cada placa debe estar conectada a la máquina Linux de la misma manera y el comando para escribir en la memoria flash es el mismo, excepto por el número de serie de la placa. Asegúrate de usar el número de serie único de cada placa en el
nrfjprog
comando de flashing.
Si se realiza de forma correcta, se encenderán las luces LED1, LED2 o LED3 en cada placa. Incluso es posible que veas que la luz LED cambia de 3 a 2 (o 2 a 1) poco después de parpadear (la función de cambio de rol del dispositivo).
12. Funcionalidad de la aplicación
Las tres placas nRF52840 deberían estar encendidas y ejecutando nuestra aplicación OpenThread. Como se detalló anteriormente, esta aplicación tiene dos funciones principales.
Indicadores de función del dispositivo
La luz LED de cada placa refleja el rol actual del nodo de Thread:
- LED1 = líder
- LED2 = Router
- LED3 = Dispositivo final
A medida que cambia el rol, también cambia la luz LED. Ya deberías haber visto estos cambios en una o dos placas a los 20 segundos de cada encendido del dispositivo.
Multidifusión UDP
Cuando se presiona Button1 en una placa, se envía un mensaje UDP a la dirección de multidifusión local de la malla, que incluye todos los demás nodos de la red Thread. En respuesta a este mensaje, se activa o desactiva la luz LED en todas las otras placas. LED4 permanece encendida o apagada en cada placa hasta que reciba otro mensaje UDP.
13. Demostración: Observa los cambios en los roles del dispositivo
Los dispositivos que escribiste en la memoria flash son un tipo específico de dispositivo de hilo completo (FTD) denominado dispositivo final apto para el router (REED). Esto significa que pueden funcionar como router o dispositivo final, y pueden pasar de un dispositivo final a un router.
Thread puede admitir hasta 32 routers, pero intenta mantener la cantidad de routers entre 16 y 23. Si un REED se conecta como dispositivo final y la cantidad de routers es inferior a 16, se convierte automáticamente en un router. Este cambio debe ocurrir en un momento aleatorio dentro de la cantidad de segundos en la que estableciste el valor otThreadSetRouterSelectionJitter
en la aplicación (20 segundos).
Cada red Thread también tiene un líder, que es un router responsable de administrar el conjunto de routers en una red Thread. Con todos los dispositivos encendidos, después de 20 segundos, uno de ellos debe ser líder (LED1 encendido) y los otros dos deben ser routers (LED2 encendido).
Quita al líder
Si se quita el líder de la red Thread, un router diferente se convierte en líder para garantizar que la red siga teniendo uno.
Apaga la placa líder (la que tiene la luz LED1) con el interruptor de encendido. Espera unos 20 segundos. En una de las otras dos placas, se apagará el LED2 (router) y se encenderá la luz LED1 (Leader). Este dispositivo ahora es el líder de la red Thread.
Vuelve a activar la junta líder original. Debería volver a unirse automáticamente a la red de Thread como dispositivo final (el LED 3 está encendido). En un plazo de 20 segundos (el Jitter de selección del router), se convierte en un router (el LED2 se enciende).
Restablece las placas
Apaga las tres placas, vuelve a encenderlas y observa las luces LED. La primera placa que se encendió debería comenzar en el rol de líder (el LED 1 está encendido). El primer router de una red Thread se convierte automáticamente en líder.
Las otras dos placas se conectan inicialmente a la red como dispositivos finales (el LED 3 está encendido), pero deberían convertirse en routers (el LED2 está encendido) en un plazo de 20 segundos.
Particiones de red
Si tus placas no reciben suficiente energía o la conexión de la radio entre ellas es débil, es posible que la red Thread se divida en particiones y que se muestre más de un dispositivo como líder.
El subproceso se repara automáticamente, por lo que las particiones deberían volver a combinarse en una sola partición con un líder.
14. Demostración: Enviar multidifusión UDP
Si continúas desde el ejercicio anterior, el LED4 no debería estar encendido en ningún dispositivo.
Elige cualquier tablero y presiona Botón1. El LED4 en todas las demás placas de la red Thread en las que se ejecute la app debería activar o desactivar su estado. Si continúas desde el ejercicio anterior, ahora deberían estar activados.
Vuelve a presionar Button1 para el mismo tablero. La luz LED4 de las demás placas debería volver a activarse.
Presiona Button1 en otra placa y observa cómo LED4 activa o desactiva las otras placas. Presiona Button1 en una de las placas donde esté encendido el LED4. LED4 permanece encendida en esa placa, pero activa las otras.
Particiones de red
Si tus tableros se particionaron y hay más de un líder entre ellos, el resultado del mensaje multicast variará entre los tableros. Si presionas Button1 en una placa particionada (y, por lo tanto, es el único miembro de la red Thread particionada), el LED4 de las otras placas no se encenderá. En ese caso, restablece las placas. Idealmente, se reformarán una sola red Thread, y la mensajería UDP debería funcionar correctamente.
15. ¡Felicitaciones!
Creaste una aplicación que usa las APIs de OpenThread.
Ahora sabes lo siguiente:
- Cómo programar los botones y las luces LED en las placas de desarrollo nórdicas nRF52840
- Cómo usar las APIs comunes de OpenThread y la clase
otInstance
- Cómo supervisar los cambios de estado de OpenThread y reaccionar ante ellos
- Cómo enviar mensajes UDP a todos los dispositivos de una red Thread
- Cómo modificar archivos makefile
Próximos pasos
A partir de este codelab, realiza los siguientes ejercicios:
- Modifica el módulo GPIO para usar pines GPIO en lugar de los LED integrados y conecta LED RGB externos que cambian de color según el rol del router
- Se agregó compatibilidad con GPIO para una plataforma de ejemplo diferente.
- En lugar de usar la multidifusión para hacer ping en todos los dispositivos con solo presionar un botón, usa la API de router/líder para localizar un dispositivo individual y hacer ping en él.
- Conecta la red en malla a Internet con un router de borde OpenThread y realiza la multidifusión desde fuera de la red Thread para iluminar los LED.
Lecturas adicionales
Consulta openthread.io y GitHub para ver una variedad de recursos de OpenThread, incluidos los siguientes:
- Plataformas compatibles: Descubre todas las plataformas compatibles con OpenThread
- Compila OpenThread: Obtén más detalles sobre cómo compilar y configurar OpenThread.
- Primer para subprocesos: una referencia excelente sobre los conceptos de Thread
Referencia: