Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Implementa las API de capa de abstracción de la plataforma

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Ver el código fuente en GitHub

OpenThread es independiente del SO y la plataforma, con una capa de abstracción de plataforma (PAL) angosta. Este PAL define lo siguiente:

Arquitectura de portación
  • Interfaz de alarma para un temporizador libre con alarma
  • Interfaces de autobús (UART, SPI) para comunicar mensajes de CLI y Spinel
  • Interfaz de radio para la comunicación de IEEE 802.15.4-2006
  • Rutinas de inicialización específicas de GCC
  • Entropía para la generación aleatoria de números reales
  • Servicio de configuración para el almacenamiento de configuración no volátil
  • Interfaz de registro para entregar mensajes de registro de OpenThread
  • Rutinas de inicialización específicas del sistema

Todas las API deben implementarse en función del paquete de asistencia de compilación (BSP) de la capa de abstracción de hardware (HAL) subyacente.

Los archivos de API se deben colocar en los siguientes directorios:

Tipo Directorio
Implementación de PAL específica de la plataforma /openthread/examples/platforms/platform-name
Archivos de encabezado: API de almacenamiento no volátil /openthread/examples/platforms/utils
Todos los demás archivos de encabezado /openthread/include/openthread/platform
HAL BSP /openthread/third_party/platform-name

Alarma

Declaración de la API:

/openthread/include/openthread/platform/alarm-milli.h

La API de Alarma proporciona servicios básicos de sincronización y sincronización para la implementación del temporizador de la capa superior.

Existen dos tipos de servicios de alarma: milisegundos y microsegundos. Los milisegundos son obligatorios para las plataformas de hardware nuevas. El microsegundo es opcional.

UART

Declaración de la API:

/openthread/examples/platforms/utils/uart.h

La API de UART implementa la comunicación fundamental del puerto en serie a través de la interfaz de UART.

Si bien los complementos de CLI y NCP de OpenThread dependen de la interfaz de UART para interactuar con el host, la compatibilidad con la API de UART es opcional. Sin embargo, incluso si no planeas usar estos complementos en tu nuevo ejemplo de plataforma de hardware, te recomendamos que agregues compatibilidad por varios motivos:

  • La CLI es útil para validar que el puerto funciona correctamente.
  • La herramienta de automatización de arneses utiliza la interfaz de UART para controlar OpenThread con fines de prueba y certificación.

Si la plataforma de hardware de destino admite un módulo de CDC por USB en lugar de UART, asegúrate de lo siguiente:

  • Instala el controlador USB de CDC correcto en el lado del host.
  • Reemplaza la implementación de la API de UART por el controlador USB CDC (junto con BSP) del lado de OpenThread, con los mismos prototipos de función

Radio

Declaración de la API:

/openthread/include/openthread/platform/radio.h

La API de Radio define todas las funciones necesarias que llama la capa MAC superior IEEE 802.15.4. El chip Radio debe cumplir con todas las especificaciones de los IEEE 802.15.4-2006 de 2.4 GHz.

Debido a su función mejorada de baja potencia, OpenThread requiere que todas las plataformas implementen el marco automático pendiente (transmisión indirecta) y la tabla de coincidencia de direcciones de origen también debe implementarse en el archivo de origen radio.h.

Sin embargo, si tu nuevo ejemplo de plataforma de hardware tiene un recurso limitado, la tabla de direcciones de origen se puede definir como la longitud cero. Consulta Marco automático pendiente para obtener más información.

Varios/Restablecer

Declaración de la API:

/openthread/include/openthread/platform/misc.h

La API de Misc/Reset proporciona un método para restablecer el software en el chip y consulta la razón del último restablecimiento.

Entropía

Declaración de la API:

/openthread/include/openthread/platform/entropy.h

La API de Entropy proporciona un generador de números aleatorios reales (TRNG) para la capa superior, que se usa a fin de mantener los elementos de seguridad para toda la red de OpenThread. La API debe garantizar que se genere un número al azar nuevo para cada llamada a función. Entre los elementos de seguridad que afecta el TRNG, se incluyen los siguientes:

  • Nonce de CCM de AES
  • Jitter aleatorio aleatorio
  • Dispositivos extendidos
  • El período aleatorio inicial en el temporizador de goteo
  • ID de mensaje o token de CoAP

Ten en cuenta que muchas plataformas ya integraron un generador de números al azar, lo que expuso la API en su paquete de BSP. En el caso de que la plataforma de hardware de destino no sea compatible con TRNG, considera aprovechar el muestreo de módulos de ADC para generar un número al azar de longitud fija. Realiza muestras en varias iteraciones si es necesario para cumplir con los requisitos de TRNG (Uint32_t).

Cuando la macro MBEDTLS_ENTROPY_HARDWARE_ALT se configura en 1, esta API también debe proporcionar un método para generar la entropía de hardware que se usa en la biblioteca mbedTLS.

Almacenamiento no volátil

Declaraciones de la API:

/openthread/include/openthread/platform/flash.h

o

/openthread/include/openthread/platform/settings.h

El requisito de almacenamiento no volátil se puede satisfacer mediante la implementación de una de las dos API mencionadas anteriormente. La API de Flash implementa un controlador de almacenamiento en Flash, mientras que la API de Configuración proporciona funciones para una implementación subyacente de operación de flash en la capa superior.

Estas API se exponen a la capa superior:

  • El tamaño de almacenamiento no volátil disponible que se usa para almacenar datos de la aplicación (por ejemplo, el conjunto de datos operativos activos/pendientes, los parámetros de red actuales y los dispositivos de subprocesos > las credenciales que se deben volver a conectar después del restablecimiento)
  • Leer, escribir, borrar y consultar operaciones de estado del flash

Usa OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE en el archivo de configuración principal de tu plataforma para indicar qué API debe usar la plataforma. Si se configura en 1, se debe implementar la API de Flash. De lo contrario, se debe implementar la API de Settings.

Esta marca debe establecerse en tu archivo /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h.

Logging

Declaración de la API:

/openthread/include/openthread/platform/logging.h

La API de Logging implementa la funcionalidad de registro y depuración de OpenThread, con varios niveles de salida de depuración disponibles. Esta API es opcional si no planeas usar el registro de OpenThread en tu nuevo ejemplo de plataforma de hardware.

El nivel más alto y detallado es OPENTHREAD_LOG_LEVEL_DEBG, que imprime toda la información del paquete sin procesar y las líneas de registro a través del puerto en serie o en la terminal. Elige el nivel de depuración que mejor se adapte a tus necesidades.

Específico del sistema

Declaración de la API:

/openthread/examples/platforms/openthread-system.h

La API específica del sistema proporciona principalmente operaciones de inicialización y de inicialización para la plataforma de hardware seleccionada. La biblioteca de OpenThread no llama a esta API, pero puede ser útil para tu sistema o RTOS. También puedes implementar la inicialización de otros módulos (por ejemplo, UART, Radio, Shuffle, Misc/Reset) en este archivo fuente.

La implementación de esta API depende de tu caso de uso. Si deseas usar las aplicaciones de la CLI y el NCP generadas para una plataforma de ejemplo, debes implementar esta API. De lo contrario, se puede implementar cualquier API para integrar los controladores de la plataforma de ejemplo en tu sistema o RTOS.