OpenThread to rozwiązanie niezależne od systemu operacyjnego i platformy, z wąską warstwą abstrakcji platformy (PAL). Ten kod PAL definiuje:
- Interfejs alarmu z wolno działających minutnikiem i alarmem
- Interfejsy autobusowe (UART, SPI) do komunikacji z wierszami poleceń i wiadomościami Spinel
- Interfejs komunikacji z IEEE 802.15.4-2006
- Procedury inicjowania specyficzne dla GCC
- Entropia do prawdziwego generowania liczb losowych
- Usługa ustawień pamięci nieulotnej
- Interfejs logowania do obsługi komunikatów logu OpenThread
- Rutyny inicjowania właściwe dla systemu
Wszystkie interfejsy API powinny być wdrożone w oparciu o bazowy pakiet HSP (sprzętu warstwowego)
Pliki API powinny znajdować się w tych katalogach:
| Typ | Katalog |
|---|---|
| Implementacja PAL dla poszczególnych platform | /openthread/examples/platforms/platform-name |
| Pliki nagłówków – nieulotny interfejs API | /openthread/examples/platforms/utils |
| Wszystkie inne pliki nagłówka | /openthread/include/openthread/platform |
| HAL BSP | /openthread/third_party/platform-name |
Alarm
Deklaracja interfejsu API:
/openthread/include/openthread/platform/alarm-milli.h
Interfejs Alarm API udostępnia funkcje podstawowych pomiarów czasu i alarmów do wdrożenia licznika czasu w górnej warstwie.
Dostępne są 2 typy alarmów: milisekunda i mikrosekunda. W przypadku nowej platformy sprzętowej wymagany jest milisekunda. Mikrosekunda jest opcjonalna.
UART
Deklaracja interfejsu API:
/openthread/examples/platforms/utils/uart.h
Interfejs UART API implementuje podstawową komunikację portów szeregowych przez interfejs UART.
Dodatki Thread API i NCP zależą od interfejsu UART w zakresie interakcji z hostem, ale obsługa interfejsu UART API jest opcjonalna. Jednak nawet jeśli nie zamierzasz używać tych dodatków na nowej platformie sprzętowej, zalecamy dodanie ich z kilku powodów:
- Interfejs wiersza poleceń jest przydatny do sprawdzania, czy port działa prawidłowo
- Narzędzie do automatyzacji interfejsu Harness wykorzystuje interfejs UART do kontrolowania OpenThread do celów testowych i certyfikacji
Jeśli docelowa platforma sprzętowa obsługuje moduł CDC USB, a nie UART:
- Zainstaluj odpowiedni sterownik USB CDC po stronie hosta
- Zastąp implementację interfejsu UART API sterownikiem USB CDC (wraz 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ę MAC IEEE 802.15.4. Element radiowy musi być w pełni zgodny ze specyfikacją 2.4 GHz IEEE 802.15.4-2006.
Ze względu na udoskonaloną funkcję niskiego poboru energii OpenThread wymaga, aby wszystkie platformy domyślnie stosowały automatyczną ramkę (transmisję pośrednią), a tabelę odpowiedników adresów źródłowych należy też zaimplementować w pliku źródłowym radio.h.
Jeśli jednak nowa przykładowa platforma sprzętowa ma ograniczoną liczbę zasobów, tabelę adresów źródłowych można zdefiniować jako zerową długość. Więcej informacji znajdziesz w sekcji Oczekująca automatyczna ramka.
Różne/resetowane
Deklaracja interfejsu API:
/openthread/include/openthread/platform/misc.h
Misc/Reset API udostępnia metodę resetowania oprogramowania w układzie scalonym i wysyłania zapytań o powód ostatniego resetowania.
Entropia
Deklaracja interfejsu API:
/openthread/include/openthread/platform/entropy.h
Interfejs Entropy API udostępnia prawdziwy generator liczb losowych (TRNG) dla górnej warstwy, który służy do utrzymywania zasobów zabezpieczeń w całej sieci OpenThread. Interfejs API powinien generować nowy losowy numer dla każdego wywołania funkcji. Komponenty z zabezpieczeniami TRNG:
- Identyfikator jednorazowy CES AES
- Losowe zakłócenia
- Rozszerzony adres urządzeń
- Początkowy losowy okres w liczniku czasu
- Identyfikator tokena/wiadomości CoAP
Pamiętaj, że wiele platform zintegrowało generator liczb losowych, udostępniając interfejs API w pakiecie BSP. Jeśli docelowa platforma sprzętowa nie obsługuje TRNG, możesz użyć próbkowania modułu ADC, aby wygenerować losową liczbę o stałej długości. Jeśli musisz spełniać wymagania TRNG, próbuj w wielu iteracjach (uint32_t).
Jeśli makro MBEDTLS_ENTROPY_HARDWARE_ALT jest ustawione na 1, ten interfejs API powinien też udostępniać metodę generowania entropy sprzętowej używanej w bibliotece mbedTLS.
Pamięć nieulotna
Deklaracje interfejsu API:
/openthread/include/openthread/platform/flash.h
lub
/openthread/include/openthread/platform/settings.h
Wymagania dotyczące pamięci nieulotnej można spełnić, implementując jeden z dwóch interfejsów API wymienionych powyżej. Interfejs Flash API ma zainstalowany sterownik pamięci flash, natomiast interfejs API ustawień udostępnia w górnej warstwie funkcje bazowej operacji Flash.
Te interfejsy API ujawniają górną warstwę:
- Rozmiar pamięci nieulotnej służący do przechowywania danych aplikacji (np. aktywny/oczekujący zbiór danych operacyjnych, bieżące parametry sieci i dane logowania urządzeń do wątków po zresetowaniu)
- Odczytywanie, zapisywanie i usuwanie zapytań o stan Flash
Użyj OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE w podstawowym pliku konfiguracyjnym przykładowej platformy, aby wskazać interfejs API, którego ma używać platforma. Jeśli jest ustawiona wartość 1, trzeba wdrożyć interfejs Flash API. W przeciwnym razie należy zaimplementować interfejs Settings API.
Ta flaga musi być ustawiona 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ę logowania i debugowania w OpenThread, mając do dyspozycji wiele poziomów danych wyjściowych 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 drukuje nieprzetworzone dane pakietów i rejestruje wiersze przez port szeregowy lub na terminalu. Wybierz poziom debugowania, który najlepiej odpowiada Twoim potrzebom.
Zależnie od systemu
Deklaracja interfejsu API:
/openthread/examples/platforms/openthread-system.h
Właściwy dla konkretnego interfejsu API interfejs inicjuje i deinicjonuje wybraną platformę sprzętową. Ten interfejs API nie jest wywoływany przez bibliotekę OpenThread, ale może być przydatny w Twoim systemie/RTOS. W tym pliku źródłowym możesz też wdrożyć inicjowanie innych modułów (np. UART, Radio, losowy, inny/resetowany).
Implementacja tego interfejsu API zależy od konkretnego przypadku użycia. Jeśli na potrzeby przykładowej platformy chcesz korzystać z wygenerowanych aplikacji wiersza poleceń i NCP, musisz wdrożyć ten interfejs API. W przeciwnym razie można wdrożyć każdy interfejs API, aby zintegrować z systemem/RTOS przykładowe sterowniki platform.