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

Implementar API de capa de abstracción de plataforma

Ver fuente en GitHub

OpenThread es independiente del sistema operativo y la plataforma, con una capa de abstracción de plataforma (PAL) estrecha. Este PAL define:

Arquitectura de portabilidad
  • Interfaz de alarma para temporizador de funcionamiento libre con alarma
  • Interfaces de bus (UART, SPI) para comunicar mensajes CLI y Spinel
  • Interfaz de radio para comunicación IEEE 802.15.4-2006
  • Rutinas de inicialización específicas de GCC
  • Entropía para la generación de números aleatorios verdaderos
  • Servicio de configuración para 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 soporte de compilación (BSP) de la capa de abstracción de hardware (HAL) subyacente.

Los archivos API deben colocarse en los siguientes directorios:

Tipo Directorio
Implementación 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 API:

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

La API de alarma proporciona servicios fundamentales de temporización y alarma para la implementación del temporizador de capa superior.

Hay dos tipos de servicios de alarma, milisegundos y microsegundos . Se requieren milisegundos para una nueva plataforma de hardware. El microsegundo es opcional.

UART

Declaración de API:

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

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

Mientras que el OpenThread CLI y NCP complementos dependen de la interfaz UART para interactuar con la cara de acogida, apoyo API UART es opcional. Sin embargo, incluso si no planea usar estos complementos en su nuevo ejemplo de plataforma de hardware, le recomendamos que agregue soporte por algunas razones:

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

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

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

Radio

Declaración de API:

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

La API de radio define todas las funciones necesarias llamadas por la capa MAC IEEE 802.15.4 superior. El chip de radio debe ser totalmente compatible con la especificación IEEE 802.15.4-2006 de 2,4 GHz.

Debido a su característica de baja potencia mejorada, OpenThread requiere que todas las plataformas para poner en práctica el marco de automóviles en espera (transmisión indirecta) por defecto, y la tabla de coincidencias dirección de origen también debe aplicarse en el radio.h archivo de origen.

Sin embargo, si el ejemplo de su nueva plataforma de hardware tiene recursos limitados, la tabla de direcciones de origen se puede definir como de longitud cero. Ver Auto Frame pendiente para más información.

Misc / Reset

Declaración de API:

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

La API Misc / Reset proporciona un método para restablecer el software en el chip y consultar el motivo del último restablecimiento.

Entropía

Declaración de API:

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

La API de Entropy proporciona un verdadero generador de números aleatorios (TRNG) para la capa superior, que se utiliza para mantener los activos de seguridad para toda la red OpenThread. La API debe garantizar que se genere un nuevo número aleatorio para cada llamada de función. Los activos de seguridad afectados por el TRNG incluyen:

  • AES CCM nonce
  • Jitter retardado aleatorio
  • Dirección extendida de dispositivos
  • El período aleatorio inicial en el temporizador de goteo.
  • ID de mensaje / token de CoAP

Tenga en cuenta que muchas plataformas ya han integrado un generador de números aleatorios, exponiendo la API en su paquete BSP. En el caso de que la plataforma de hardware de destino no admita TRNG, considere aprovechar el muestreo del módulo ADC para generar un número aleatorio de longitud fija. Tome muestras de varias iteraciones si es necesario para cumplir con los requisitos de TRNG (uint32_t).

Cuando el macro MBEDTLS_ENTROPY_HARDWARE_ALT se establece en 1 , este API también debe proporcionar un método para generar la entropía hardware utilizado en la biblioteca mbedTLS.

Almacenamiento no volátil

Declaraciones de API:

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

o

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

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

Estas API exponen a la capa superior:

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

Uso OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE en el archivo de configuración principal de su plataforma de ejemplo para indicar qué API de la plataforma debe utilizar. Si se establece en 1 , el API de Flash debe ser implementada. De lo contrario, se debe implementar la API de configuración.

Esta opción debe ser en su /openthread/examples/platforms/ platform-name /openthread-core- platform-name -config.h archivo.

Inicio sesión

Declaración de API:

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

La API de registro implementa la funcionalidad de registro y depuración de OpenThread, con múltiples niveles de salida de depuración disponibles. Esta API es opcional si no planea utilizar el registro de OpenThread en su nuevo ejemplo de plataforma de hardware.

El nivel más alto y más detallada es OPENTHREAD_LOG_LEVEL_DEBG , que imprime todas las líneas de información de paquetes en bruto y troncos través del puerto serie o en el terminal. Elija el nivel de depuración que mejor se adapte a sus necesidades.

Específico del sistema

Declaración de API:

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

La API específica del sistema proporciona principalmente operaciones de inicialización y desinicialización para la plataforma de hardware seleccionada. Esta API no es llamada por la propia biblioteca OpenThread, pero puede ser útil para su sistema / RTOS. También puede implementar la inicialización de otros módulos (por ejemplo, UART, Radio, Random, Misc / Reset) en este archivo fuente.

La implementación de esta API depende de su caso de uso. Si desea utilizar los generados aplicaciones CLI y NCP para una plataforma de ejemplo , debe implementar esta API. De lo contrario, se puede implementar cualquier API para integrar los controladores de la plataforma de ejemplo en su sistema / RTOS.