OpenThread es independiente del SO y la plataforma, con una capa de abstracción de plataforma (PAL) estrecha. Este PAL define lo siguiente:
- Interfaz de alarma para temporizador de funcionamiento continuo con alarma
- Interfaces de bus (UART, SPI) para comunicar mensajes de CLI y Spinel
- Interfaz de radio para la 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 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 APIs deben implementarse en función del paquete de compatibilidad de compilación (BSP) de la capa de abstracción de hardware (HAL) subyacente.
Los archivos de la 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 |
| BSP de HAL | /openthread/third_party/platform-name |
Alarma
Declaración de la API:
/openthread/include/openthread/platform/alarm-milli.h
La API de Alarm proporciona servicios de alarma y sincronización fundamentales para la implementación del temporizador de la capa superior.
Existen dos tipos de servicios de alarma: milisegundo y microsegundo. Se requiere milisegundos para una nueva plataforma de hardware. 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 serie a través de la interfaz UART.
Si bien los complementos de CLI y NCP de OpenThread dependen de la interfaz 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 ejemplo de plataforma de hardware nueva, te recomendamos que agregues compatibilidad por los siguientes motivos:
- La CLI es útil para validar que el puerto funcione correctamente.
- La herramienta de automatización de arneses 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 USB CDC en lugar de UART, asegúrate de lo siguiente:
- Instala el controlador USB CDC correcto en el host
- Reemplaza la implementación de la API de UART por el controlador CDC de USB (junto con el BSP) en el 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 de IEEE 802.15.4. El chip de radio debe cumplir completamente con 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 la trama automática pendiente (transmisión indirecta) de forma predeterminada, y la tabla de coincidencia de direcciones de origen también debe implementarse en el archivo fuente radio.h.
Sin embargo, si tu ejemplo de plataforma de hardware nueva tiene recursos limitados, la tabla de direcciones de origen se puede definir como de longitud cero. Consulta Marco automático pendiente para obtener más información.
Misc/Reset
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 consultar el motivo 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 verdaderos (TRNG) para la capa superior, que se usa para mantener los recursos de seguridad de toda la red de OpenThread. La API debe garantizar que se genere un número aleatorio nuevo para cada llamada a función. Entre los recursos de seguridad afectados por la TRNG, se incluyen los siguientes:
- Número nonce de AES CCM
- Jitter retrasado aleatorio
- Dirección extendida de los dispositivos
- El período aleatorio inicial en el temporizador de filtración
- IDs de token o mensaje de CoAP
Ten en cuenta que muchas plataformas ya integraron un generador de números aleatorios, lo que expone la API en su paquete de BSP. En caso de que la plataforma de hardware objetivo no admita TRNG, considera aprovechar el muestreo del módulo ADC para generar un número aleatorio de longitud fija. Toma muestras en varias iteraciones si es necesario para cumplir con los requisitos de la 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 que se usa en la biblioteca de mbedTLS.
Almacenamiento no volátil
Declaraciones de API:
/openthread/include/openthread/platform/flash.h
o
/openthread/include/openthread/platform/settings.h
Para satisfacer el requisito de almacenamiento no volátil, se puede implementar una de las dos APIs que se mencionaron anteriormente. La API de Flash implementa un controlador de almacenamiento flash, mientras que la API de Settings proporciona funciones para una implementación subyacente de operaciones de flash en la capa superior.
Estas APIs exponen a la capa superior lo siguiente:
- Es 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 activo o pendiente, los parámetros de red actuales y las credenciales de los dispositivos de subproceso para volver a conectarlos después del restablecimiento).
- Operaciones de lectura, escritura, borrado y consulta de estado de la memoria flash
Usa OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE en el archivo de configuración principal del ejemplo de tu plataforma para indicar qué API debe usar la plataforma. Si se establece en 1, se debe implementar la API de Flash. De lo contrario, se debe implementar la API de Configuración.
Esta marca se debe establecer en el 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 ejemplo de plataforma de hardware nueva.
El nivel más alto y detallado es OPENTHREAD_LOG_LEVEL_DEBG, que imprime toda la información de paquetes sin procesar y registra líneas a través del puerto serie o en la terminal. Elige un nivel de depuración que se adapte mejor 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 deinicializació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, Random, Misc/Reset) en este archivo fuente.
La implementación de esta API depende de tu caso de uso. Si deseas usar las aplicaciones de 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 plataforma de ejemplo en tu sistema o RTOS.