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

Ver código fuente en GitHub

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

Arquitectura de la portabilidad
  • Interfaz de alarma para un temporizador en funcionamiento con alarma
  • Interfaces de autobuses (UART, SPI) para comunicar mensajes Spinel y CLI
  • 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 asistencia de compilación de la capa de abstracción de hardware (HAL) subyacente.

Los archivos de API deben colocarse 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 API:

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

La API de Alarma proporciona servicios fundamentales 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. Se requiere milisegundo para una plataforma de hardware nueva. El microsegundo es opcional.

UART

Declaración de API:

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

La API de UART implementa la comunicación básica de puertos 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 la plataforma de hardware, te recomendamos que agregues compatibilidad por algunas razones:

  • La CLI es útil para validar que el puerto funciona correctamente
  • La herramienta Harness Automation usa la interfaz 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 de CDC (junto con BSP) en el lado de OpenThread, con 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 que llama la capa MAC superior IEEE 802.15.4. El chip de Radio debe cumplir con todos los requisitos de la especificación IEEE 802.15.4-2006 de 2.4 GHz.

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

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

Varios/Restablecer

Declaración de 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 el motivo del último restablecimiento.

Entropía

Declaración de API:

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

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

  • Nonce de CCM de AES
  • Jitter aleatorio aleatorio
  • Dirección extendida de los dispositivos
  • 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 BSP. Si la plataforma de hardware de destino no admite TRNG, considera aprovechar el muestreo de módulos de ADC para generar un número aleatorio de longitud fija. Muestra de varias iteraciones si es necesario para cumplir con los requisitos de TRNG (uint32_t).

Cuando la macro MBEDTLS_ENTROPY_HARDWARE_ALT se establece en 1, esta API también debe proporcionar un método para generar la entropía de hardware usada 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 implementar mediante la implementación de una de las dos API mencionadas anteriormente. La API de Flash implementa un controlador de almacenamiento Flash, mientras que la API de configuración proporciona funciones para una implementación subyacente de la operación de Flash en la capa superior.

Estas API 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, un conjunto de datos operativos activos o pendientes, parámetros de red actuales y credenciales de dispositivos de subprocesos para volver a conectar después de restablecer)
  • Permite leer, escribir, borrar y consultar las operaciones de estado del flash.

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

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

Registros

Declaración de 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 deseas utilizar el registro de OpenThread en el nuevo ejemplo de la 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 registra las líneas 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 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, aleatorio, varios/restablecer) en este archivo de origen.

La implementación de esta API depende de tu caso práctico. Si deseas usar las aplicaciones de la CLI y 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.