OpenThread jest niezależny od systemu operacyjnego i platformy oraz wąską warstwą abstrakcji platformy (PAL). Ten identyfikator PAL definiuje:
- Interfejs alarmu, na którym wyświetla się minutnik z alarmem
- Interfejsy autobusowe (UART, SPI) do komunikacji z wierszami poleceń i wiadomościami Spinel
- Interfejs radiowy do komunikacji z IEEE 802.15.4-2006
- Procedury inicjowania specyficzne dla GCC
- Entropia do prawdziwego generowania liczb losowych
- Usługa ustawień nieulotnej pamięci konfiguracji
- Interfejs logowania do dostarczania wiadomości logu OpenThread
- Procedury inicjowania specyficzne dla systemu
Wszystkie interfejsy API powinny być wdrożone na podstawie odpowiedniego pakietu BSP (Build Layer Layer Layer).
Pliki interfejsów 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 do przechowywania danych ulotnych | /openthread/examples/platforms/utils |
| Wszystkie inne pliki nagłówka | /openthread/include/openthread/platform |
| HAL BSP, | /openthread/third_party/platform-name |
Alarm
Deklaracja dotycząca interfejsu API:
/openthread/include/openthread/platform/alarm-milli.h
Interfejs Alarm API zapewnia dostęp do podstawowych funkcji pomiaru czasu i alarmów w ramach funkcji wdrażania u góry warstwy.
Dostępne są 2 typy usług alarmu: milisekunda i mikrosekunda. W przypadku nowej platformy sprzętowej wymagana jest milisekunda. Mikrosekunda jest opcjonalna.
UART
Deklaracja dotycząca interfejsu API:
/openthread/examples/platforms/utils/uart.h
Interfejs UART API implementuje podstawową komunikację portów szeregowych przez interfejs UART.
Dodatki do wiersza poleceń Coli i NCP zależą od interfejsu UART w celu interakcji z hostem, ale obsługa interfejsu UART API jest opcjonalna. Jednak nawet jeśli nie zamierzasz korzystać z tych dodatków na swojej nowej platformie sprzętowej, z kilku powodów zalecamy dodanie ich do pomocy:
- Interfejs wiersza poleceń przydaje się do sprawdzania, czy port działa prawidłowo.
- Harness Automation Tool wykorzystuje interfejs UART do kontrolowania OpenThread do celów testowych i certyfikacyjnych.
Jeśli docelowa platforma sprzętowa obsługuje moduł USB CDC zamiast UART, pamiętaj o tych kwestiach:
- 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 dotycząca interfejsu API:
/openthread/include/openthread/platform/radio.h
Interfejs Radio API definiuje wszystkie niezbędne funkcje wywołane przez górną warstwę MAC IEEE 802.15.4. Układ radiowy musi być w pełni zgodny ze specyfikacją 2,4 GHz IEEE 802.15.4-2006.
Ze względu na udoskonaloną funkcję niskiego zasilania, OpenThread wymaga, aby wszystkie platformy domyślnie implementowały automatyczną ramkę (transmisja pośrednia). Tabela odpowiedników z adresem źródłowym powinna być również zaimplementowana w pliku źródłowym radio.h.
Jeśli jednak na przykład Twoja nowa platforma sprzętowa jest ograniczona do zasobu, tabelę adresów źródłowych można zdefiniować jako zero. Więcej informacji znajdziesz w sekcji Oczekująca ramka automatyczna.
Różne/resetowanie
Deklaracja dotycząca interfejsu API:
/openthread/include/openthread/platform/misc.h
Interfejs Misc/Reset API udostępnia metodę resetowania oprogramowania na chipze i wysyłanie zapytań o przyczynę ostatniego resetowania.
Entropia
Deklaracja dotycząca interfejsu API:
/openthread/include/openthread/platform/entropy.h
Interfejs API Entropy udostępnia prawdziwy generator liczb losowych (TRNG) do górnej warstwy, który służy do przechowywania zasobów zabezpieczeń w całej sieci OpenThread. Interfejs API powinien zagwarantować, że przy każdym wywołaniu funkcji zostanie wygenerowany nowy losowy numer. Zasób TRNG, którego dotyczy problem:
- Liczba jednorazowa AES CCM
- Losowe opóźnione zakłócenia
- Urządzenia' rozszerzony adres
- Początkowy losowy okres w minutniku
- Tokeny/tokeny CoAP
Pamiętaj, że wiele platform ma już zintegrowany generator liczb losowych, a jego interfejs API jest dostępny w pakiecie BSP. Jeśli docelowa platforma sprzętowa nie obsługuje TRNG, rozważ próbkowanie modułów ADC w celu wygenerowania liczby losowej o stałej długości. Jeśli próbka spełnia wymagania TRNG, zastosuj próbkę w wielu iteracjach (uint32_t).
Gdy makro MBEDTLS_ENTROPY_HARDWARE_ALT ma wartość 1, ten interfejs API powinien też udostępniać metodę generowania entropii 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
Jeden z dwóch wymienionych powyżej interfejsów API może spełnić wymagania dotyczące nieulotnych danych. Flash API implementuje sterownik pamięci flash, a interfejs Settings API udostępnia funkcje bazowej implementacji Flash w górnej warstwie.
Te interfejsy API są widoczne dla górnej warstwy:
- Dostępny rozmiar nieulotnych danych używanych do przechowywania danych aplikacji (np. aktywny/oczekujący zbiór danych operacyjnych, bieżące parametry sieci i urządzenia z wątkami, dane logowania do ponownego dołączenia po zresetowaniu)
- Odczytywanie, zapisywanie, usuwanie i wysyłanie zapytań o stan Flash
Użyj OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE w przykładowym pliku konfiguracji platformy, aby wskazać interfejs API, którego ma używać ta platforma. Jeśli zasada ma wartość 1, trzeba zaimplementować interfejs API Flash. W przeciwnym razie należy zaimplementować interfejs Settings API.
Ta flaga musi być ustawiona w Twoim pliku
/openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h.
Logowanie
Deklaracja dotycząca interfejsu API:
/openthread/include/openthread/platform/logging.h
Interfejs Logging API implementuje funkcję rejestrowania i debugowania, która jest dostępna w trybie OpenThread'. Udostępniamy wiele poziomów danych debugowania. Ten interfejs API jest opcjonalny, jeśli nie planujesz używać usługi OpenThread''s Logging w swojej nowej platformie sprzętowej.
Najwyższy i najbardziej szczegółowy poziom to OPENTHREAD_LOG_LEVEL_DEBG, który drukuje wszystkie nieprzetworzone pakiety i odczytuje wiersze przez port szeregowy lub terminal. Wybierz poziom debugowania, który najlepiej odpowiada Twoim potrzebom.
Właściwe dla systemu
Deklaracja dotycząca interfejsu API:
/openthread/examples/platforms/openthread-system.h
Właściwy interfejs API zapewnia głównie operacje inicjowania i deinicji na wybranej platformie sprzętowej. 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ż zaimplementować inicjowanie innych modułów (np. UART, Radio, Losowo, Inne/Resetuj).
Implementacja tego interfejsu API zależy od konkretnego przypadku użycia. Jeśli chcesz używać wygenerowanych aplikacji wiersza poleceń i NCP na przykładowej platformie, musisz wdrożyć ten interfejs API. W przeciwnym razie możesz zaimplementować dowolny interfejs API, aby zintegrować przykładowe sterowniki platform z Twoim systemem/RTOS.