OpenThread jest niezależna od systemu i niezależna od platformy (AAL) do warstwy abstrakcji platformy. Ten przewodnik PAL definiuje:

- Interfejs alarmu z uruchomionym minutnikiem i alarmem
- Interfejsy autobusów (UART, SPI) do przekazywania wiadomości dotyczących interfejsu wiersza poleceń i Spinel
- Interfejs radiowy dla komunikacji IEEE 802.15.4-2006
- Procedury inicjowania GCC
- Entropia generowania liczb losowych
- Usługa ustawień dla niezmiennej pamięci konfiguracji
- Interfejs logowania do przesyłania komunikatów logu OpenThread
- Procedury inicjowania systemu
Wszystkie interfejsy API należy wdrażać na podstawie bazowego pakietu BSP (Hardware Abstraction Layer Build).
Pliki interfejsu API należy umieścić w tych katalogach:
Typ | Katalog |
---|---|
Implementacja PAL na danej platformie | /openthread/examples/platforms/platform-name |
Pliki nagłówków – interfejs API niezmienny | /openthread/examples/platforms/utils |
Wszystkie inne pliki nagłówków | /openthread/include/openthread/platform |
BAL BSP | /openthread/third_party/platform-name |
Alarm
Deklaracja interfejsu API:
/openthread/include/openthread/platform/alarm-milli.h
Alarm API zapewnia podstawowe usługi synchronizacji i synchronizacji czasu dla implementacji wyższego poziomu.
Istnieją dwa typy usług alarmowych: milisekunda i mikrosekunda. Nowa platforma sprzętowa wymaga milisekundy. Mikrosekunda jest opcjonalna.
Plik UART
Deklaracja interfejsu API:
/openthread/examples/platforms/utils/uart.h
UART API stosuje podstawowe komunikację przez port szeregowy przez interfejs UART.
Mimo że dodatki OpenThread CLI i NCP zależą od interfejsu UART, to od interakcji z hostem zależy od interfejsu UART jest opcjonalne. Nawet jeśli nie planujesz używać tych dodatków w swoim nowym platformie sprzętowym, zdecydowanie zalecamy dodanie pomocy z kilku powodów:
- Interfejs wiersza poleceń przydaje się do sprawdzania, czy port działa prawidłowo
- The Harness Automation Tool używa interfejsu UART do kontrolowania OpenThread do celów testowych i certyfikacyjnych
Jeśli docelowa platforma sprzętowa obsługuje moduł CDC (USC) zamiast UART, pamiętaj, by:
- Zainstaluj prawidłowy sterownik USBCC po stronie hosta.
- Zastąp implementację interfejsu UART API sterownikiem CDC (razem z BSP) po stronie OpenThread, korzystając z tych samych prototypów funkcji
Radio
Deklaracja interfejsu API:
/openthread/include/openthread/platform/radio.h
Interfejs Radio API definiuje wszystkie niezbędne funkcje wywoływane przez górną warstwę IEEE 802.15.4. Element radiowy musi być w pełni zgodny ze specyfikacją IEEE 802.15.4-2006 (2.4 GHz).
Ze względu na ulepszoną funkcję małej mocy OpenThread wymaga, aby wszystkie platformy domyślnie implementowały automatyczną ramkę (transmisję pośrednią), a tabela dopasowania adresu źródłowego powinna być również zaimplementowana w pliku źródłowym radio.h
.
Jeśli jednak nowa przykładowa platforma sprzętowa jest ograniczona przez zasoby, tabelę adresów źródłowych można zdefiniować jako długość zero. Więcej informacji znajdziesz na stronie Oczekiwanie na automatyczną ramkę.
Różne/Resetuj
Deklaracja interfejsu API:
/openthread/include/openthread/platform/misc.h
Interfejs Misc/Reset API służy do resetowania oprogramowania elementu i wysyła zapytanie o przyczyny ostatniego zresetowania.
Entropia
Deklaracja interfejsu API:
/openthread/include/openthread/platform/entropy.h
Interfejs Entropy API zapewnia generator liczb losowych (TRNG) dla górnej warstwy, który służy do utrzymywania zasobów zabezpieczeń dla całej sieci OpenThread. Interfejs API powinien zagwarantować wygenerowanie nowej liczby losowej dla każdego wywołania funkcji. Zasoby zabezpieczeń, których dotyczy TRNG, to:
- Jednorazowa wartość AES CCM
- Losowe opóźnienia zakłóceń
- Rozszerzony adres urządzenia
- Początkowy okres losowy w minutniku
- Identyfikatory tokenów/wiadomości CoAP
Wiele platform integruje już generator liczb losowych, udostępniając interfejs API w pakiecie BSP. Jeśli docelowa platforma sprzętowa nie obsługuje TRNG, spróbuj wykorzystać próbkowanie modułu ADC do wygenerowania liczby losowej o stałej długości. Próbuj przez wiele iteracji, jeśli to konieczne, aby spełnić wymagania TRNG (uint32_t).
Gdy makro MBEDTLS_ENTROPY_HARDWARE_ALT
jest ustawione na 1
, ten interfejs API powinien również dostarczyć metodę generowania entropii sprzętowej używanej w bibliotece mbedTLS.
Pamięć nietrwała
Deklaracje interfejsu API:
/openthread/include/openthread/platform/flash.h
lub
/openthread/include/openthread/platform/settings.h
Aby można było spełnić wymóg dotyczący niezmienności miejsca na dane, trzeba wdrożyć jeden z dwóch wymienionych powyżej interfejsów API. Flash API implementuje sterownik pamięci flash, a interfejs Settings API udostępnia funkcje bazowej implementacji Flash na górnej warstwie.
Te interfejsy API wyświetlają się w górnej warstwie:
- Dostępny nietrwały rozmiar miejsca do przechowywania danych aplikacji (na przykład aktywny/oczekujący zbiór danych operacyjnych, bieżące parametry sieci i dane logowania urządzeń wątków do ponownego dołączenia po zresetowaniu)
- Operacje odczytu, zapisu i usuwania danych oraz zapytania o stan lampy błyskowej
Użyj OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE
w podstawowym pliku konfiguracji platformy, aby wskazać, którego interfejsu API powinna używać platforma. Jeśli jest ustawiony 1
, należy zaimplementować interfejs API Flash. W przeciwnym razie trzeba zaimplementować interfejs Settings API.
Flagę należy ustawić w pliku /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h
.
Logowanie
Deklaracja interfejsu API:
/openthread/include/openthread/platform/logging.h
Interfejs Logging API implementuje funkcję rejestrowania i debugowania OpenThread z wieloma poziomami wyjścia do debugowania. Ten interfejs API jest opcjonalny, jeśli nie planujesz używać logowania OpenThread na nowej platformie sprzętowej.
Najwyższy i najbardziej szczegółowy poziom to OPENTHREAD_LOG_LEVEL_DEBG
, który pozwala wydrukować wszystkie nieprzetworzone informacje o pakietach i wiersze dziennika przez port szeregowy lub terminal. Wybierz poziom debugowania, który najlepiej odpowiada Twoim potrzebom.
W zależności od systemu
Deklaracja interfejsu API:
/openthread/examples/platforms/openthread-system.h
Interfejs API specyficzny dla systemu obsługuje głównie operacje inicjowania i deinicjowania dla wybranej platformy sprzętowej. Interfejs ten nie jest wywoływany przez bibliotekę OpenThread, ale może być przydatny dla Twojego systemu/RTOS. W tym pliku źródłowym możesz też zaimplementować inicjowanie innych modułów (np. UART, Radio, Losowe, Różne/Resetuj).
Implementacja tego interfejsu API zależy od konkretnego przypadku użycia. Jeśli chcesz użyć wygenerowanych aplikacji wiersza poleceń i NCP na przykładowej platformie, musisz zaimplementować ten interfejs API. W przeciwnym razie można wdrożyć dowolny interfejs API, aby zintegrować przykładowe sterowniki platformy z systemem/RTOS.