Implementa API Platform Abstraction Layer

Visualizza il codice sorgente su GitHub

Di Mason Tran

Collaboratore di SiLabs

OpenThread è indipendente dal sistema operativo e dalla piattaforma, con un livello di astrazione della piattaforma (PAL) ridotto. Questo PAL definisce:

• Interfaccia di sveglia per timer a tempo libero con sveglia
• Interfacce bus (UART, SPI) per la comunicazione dei messaggi CLI e Spinel
• Interfaccia radio per la comunicazione IEEE 802.15.4-2006
• Routine di inizializzazione specifiche per GCC
• Entropia per la generazione di numeri casuali veri
• Servizio Impostazioni per lo spazio di archiviazione della configurazione non volatile
• Interfaccia di logging per l'invio di messaggi di log OpenThread
• Routine di inizializzazione specifiche del sistema

Tutte le API devono essere implementate in base al pacchetto di supporto per la compilazione (BSP) del livello di astrazione hardware (HAL) sottostante.

Punto chiave: a meno che non sia indicato come facoltativo, le API del livello di astrazione della piattaforma sono obbligatorie e devono essere implementate in base alle definizioni in ogni file di intestazione dell'API.

I file API devono essere posizionati nelle seguenti directory:

Tipo	Directory
Implementazione di PAL specifica per la piattaforma	/openthread/examples/platforms/platform-name
File di intestazione: API di archiviazione non volatile	/openthread/examples/platforms/utils
Tutti gli altri file di intestazione	/openthread/include/openthread/platform
HAL BSP	/openthread/third_party/platform-name

Sveglia

Dichiarazione API:

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

L'API Alarm fornisce servizi di temporizzazione e sveglia di base per l'implementazione del timer di livello superiore.

Esistono due tipi di servizi di avviso: millisecondi e microsecondi. Millisecond è necessario per una nuova piattaforma hardware. Il microsecondo è facoltativo.

UART

Nota: questa API è facoltativa.

Dichiarazione API:

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

L'API UART implementa la comunicazione di base della porta seriale tramite l'interfaccia UART.

Sebbene i componenti aggiuntivi CLI e NCP di OpenThread dipendano dall'interfaccia UART per interagire con il lato host, il supporto dell'API UART è facoltativo. Tuttavia, anche se non prevedi di utilizzare questi componenti aggiuntivi sul nuovo esempio di piattaforma hardware, ti consigliamo vivamente di aggiungerne il supporto per alcuni motivi:

• L'interfaccia a riga di comando è utile per verificare il corretto funzionamento della porta
• Lo strumento di automazione del cablaggio utilizza l'interfaccia UART per controllare OpenThread a fini di test e certificazione

Se la piattaforma hardware di destinazione supporta un modulo CDC USB anziché UART, assicurati di:

• Installa il driver CDC USB corretto sul lato host
• Sostituisci l'implementazione dell'API UART con il driver USB CDC (insieme al BSP) sul lato OpenThread, utilizzando gli stessi prototipi di funzione

Radio

Dichiarazione API:

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

L'API Radio definisce tutte le funzioni necessarie chiamate dal livello MAC IEEE 802.15.4 superiore. Il chip radio deve essere completamente conforme alla specifica IEEE 802.15.4-2006 a 2,4 GHz.

Grazie alla sua funzionalità di risparmio energetico avanzata, OpenThread richiede a tutte le piattaforme di implementare per impostazione predefinita il frame automatico in attesa (trasmissione indiretta) e la tabella di corrispondenza dell'indirizzo di origine deve essere implementata anche nel file di origine radio.h.

Tuttavia, se l'esempio della nuova piattaforma hardware è limitato alle risorse, la tabella degli indirizzi di origine può essere definita di lunghezza pari a zero. Per saperne di più, consulta Auto Frame Pending.

Nota: l'API Radio otPlatRadioGetIeeeEui64 DEVE restituire un valore EUI-64 IEEE assegnato in fabbrica e gestito in modo univoco che includa l'OUI del produttore. L'EUI-64 viene utilizzato per l'associazione ai dati di orientamento durante la fase di rilevamento dei joiner.

Varie/Ripristino dei dati di fabbrica

Dichiarazione API:

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

L'API Misc/Reset fornisce un metodo per reimpostare il software sul chip e eseguire query sul motivo dell'ultimo ripristino.

Entropia

Nota: l'implementazione di questa API è obbligatoria in ogni porta di OpenThread.

Dichiarazione API:

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

L'API Entropy fornisce un generatore di numeri casuali veri (TRNG) per il livello superiore, che viene utilizzato per gestire gli asset di sicurezza per l'intera rete OpenThread. L'API deve garantire che venga generato un nuovo numero casuale per ogni chiamata di funzione. Gli asset di sicurezza interessati dal TRNG includono:

• Nonce AES CCM
• Jitter ritardato casuale
• Indirizzo esteso dei dispositivi
• Il periodo casuale iniziale nel timer graduale
• ID token/messaggio CoAP

Tieni presente che molte piattaforme hanno già integrato un generatore di numeri casuali, esponendo l'API nel relativo pacchetto BSP. Se la piattaforma hardware di destinazione non supporta la TRNG, valuta la possibilità di utilizzare il campionamento del modulo ADC per generare un numero casuale di lunghezza fissa. Esegui il campionamento su più iterazioni se necessario per soddisfare i requisiti della TRNG (uint32_t).

Quando la macro MBEDTLS_ENTROPY_HARDWARE_ALT è impostata su 1, questa API deve anche fornire un metodo per generare l'entropia hardware utilizzata nella libreria mbedTLS.

Spazio di archiviazione non volatile

Nota: è necessario implementare solo una di queste API in ogni porta di OpenThread.

Dichiarazioni API:

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

o

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

Il requisito di archiviazione non volatile può essere soddisfatto implementando una delle due API elencate sopra. L'API Flash implementa un driver di archiviazione flash, mentre l'API Impostazioni fornisce funzioni per un'implementazione di operazioni flash di base al livello superiore.

Queste API espongono al livello superiore:

• La dimensione dello spazio di archiviazione non volatile disponibile utilizzata per memorizzare i dati dell'applicazione (ad esempio, set di dati operativi attivi/in attesa, parametri di rete attuali e credenziali dei dispositivi Thread per il ricoinvolgimento dopo il ripristino dei dati di fabbrica)
• Operazioni di lettura, scrittura, reset e query dello stato del flash

Utilizza OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE nel file di configurazione di base dell'esempio di piattaforma per indicare quale API deve utilizzare la piattaforma. Se impostato su 1, l'API Flash deve essere implementata. In caso contrario, è necessario implementare l'API Impostazioni.

Questo flag deve essere impostato nel /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h file.

Logging

Nota: questa API è facoltativa.

Dichiarazione API:

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

L'API Logging implementa le funzionalità di logging e debug di OpenThread, con diversi livelli di output di debug disponibili. Questa API è facoltativa se non hai intenzione di utilizzare il logging di OpenThread sulla tua nuova piattaforma hardware di esempio.

Il livello più alto e dettagliato è OPENTHREAD_LOG_LEVEL_DEBG, che stampa tutte le informazioni non elaborate dei pacchetti e le righe dei log tramite la porta seriale o sul terminale. Scegli un livello di debug che soddisfi al meglio le tue esigenze.

Specifico del sistema

Dichiarazione API:

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

L'API specifica per il sistema fornisce principalmente operazioni di inizializzazione e disinizializzazione per la piattaforma hardware selezionata. Questa API non viene chiamata dalla stessa libreria OpenThread, ma potrebbe essere utile per il sistema/RTOS. Puoi anche implementare l'inizializzazione di altri moduli (ad esempio UART, Radio, Random, Misc/Reset) in questo file di origine.

L'implementazione di questa API dipende dal caso d'uso. Se vuoi utilizzare le applicazioni CLI e NCP generate per una piattaforma di esempio, devi implementare questa API. In caso contrario, è possibile implementare qualsiasi API per integrare i driver della piattaforma di esempio nel sistema/RTOS.