Zaimplementuj interfejsy API abstrakcji platformy

Wyświetl kod źródłowy na GitHubie

Autorzy Mason Tran

Współtwórca z SiLabs

OpenThread jest niezależny od systemu operacyjnego i platformy, a jego interfejs abstrakcyjny jest ograniczony (PAL). Ten profil określa:

• Interfejs alarmu dla minutnika z alarmem
• interfejsy magistrali (UART, SPI) do przesyłania komunikatów CLI i Spinel;
• Interfejs radiowy do komunikacji IEEE 802.15.4-2006
• Procedury inicjowania specyficzne dla GCC
• Entropia do generowania prawdziwych liczb losowych
• Usługa ustawień do przechowywania konfiguracji w pamięci trwałej
• Interfejs logowania do przesyłania komunikatów logowania OpenThread
• Procedury inicjowania specyficzne dla systemu

Wszystkie interfejsy API powinny być implementowane na podstawie pakietu Build Support Package (BSP) na poziomie warstwy abstrakcji sprzętowej (HAL).

Ważne: o ile nie zaznaczono inaczej, interfejsy API platformy abstrakcji są obowiązkowe i muszą być zaimplementowane zgodnie z definicjami w każdym pliku nagłówka interfejsu API.

Pliki interfejsu API należy umieszczać w tych katalogach:

Typ	Katalog
Implementacja PAL na poszczególnych platformach	/openthread/examples/platforms/platform-name
Pliki nagłówka – interfejs API nieulotnego magazynu danych	/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 zapewnia podstawowe usługi dotyczące ustawiania czasu i alarmów dla implementacji zegara na wyższym poziomie.

Istnieją 2 rodzaje alarmów: milisekundowy i mikrosekundowy. Millisecond jest wymagany na nowej platformie sprzętowej. Mikrosekunda jest opcjonalna.

UART

Uwaga: ten interfejs API jest opcjonalny.

Deklaracja interfejsu API:

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

Interfejs UART API implementuje podstawową komunikację przez port szeregowy za pomocą interfejsu UART.

Dodatki OpenThread CLI i NCP są zależne od interfejsu UART, który umożliwia interakcję z hostem. Obsługa interfejsu UART jest opcjonalna. Nawet jeśli nie planujesz używać tych dodatków na nowej platformie sprzętowej, zdecydowanie zalecamy dodanie obsługi z kilku powodów:

• Wiersz poleceń jest przydatny do sprawdzania, czy port działa prawidłowo.
• Narzędzie automatyzacji Harness używa interfejsu UART do sterowania OpenThread na potrzeby testowania i certyfikacji.

Jeśli docelowa platforma sprzętowa obsługuje moduł USB CDC, a nie UART, pamiętaj o tym, aby:

• Zainstaluj odpowiedni sterownik CDC USB po stronie hosta
• Zastąp implementację interfejsu UART interfejsem sterownika USB CDC (wraz z BSP) po stronie OpenThread, używając 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 wyższą warstwę MAC IEEE 802.15.4. Układ radiowy musi być w pełni zgodny ze specyfikacją IEEE 802.15.4-2006 dla częstotliwości 2,4 GHz.

Ze względu na funkcję zwiększonego zużycia energii OpenThread wymaga, aby wszystkie platformy domyślnie implementowały automatyczne oczekujące ramki (transmisja pośrednia), a tabela dopasowania adresów źródłowych powinna być również zaimplementowana w pliku źródłowym radio.h.

Jeśli jednak nowa platforma sprzętowa jest ograniczona pod względem zasobów, tabela adresów źródłowych może być zdefiniowana jako tabela o długości 0. Więcej informacji znajdziesz w artykule Auto Frame Pending.

Uwaga: interfejs API otPlatRadioGetIeeeEui64 Radio MUSI zwracać unikalny, zarządzany fabrycznie identyfikator IEEE EUI-64, który zawiera identyfikator OUI producenta. EUI-64 służy do dopasowywania danych kierowania w fazie wykrywania uczestników.

Inne/Reset

Deklaracja interfejsu API:

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

Interfejs Misc/Reset API udostępnia metodę resetowania oprogramowania na chipie oraz umożliwia wysłanie zapytania o przyczynę ostatniego zresetowania.

Entropia

Uwaga: implementacja tego interfejsu API jest wymagana w przypadku każdego portu OpenThread.

Deklaracja interfejsu API:

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

Interfejs Entropy API udostępnia prawdziwy generator liczb losowych (TRNG) dla warstwy wyższej, który służy do utrzymywania zasobów bezpieczeństwa w całej sieci OpenThread. Interfejs API powinien gwarantować, że nowe losowe liczby są generowane dla każdego wywołania funkcji. Zasoby zabezpieczeń, na które wpływa TRNG:

• AES CCM nonce
• Losowe opóźnienie
• Rozszerzony adres urządzeń
• Początkowy losowy okres w timerze ścieżki
• Identyfikatory tokenów/wiadomości CoAP

Pamiętaj, że wiele platform ma już zintegrowany generator liczb losowych, który udostępnia interfejs API w pakiecie BSP. Jeśli docelowa platforma sprzętowa nie obsługuje TRNG, rozważ użycie próbkowania modułu ADC do generowania liczb losowych o stałyej długości. W razie potrzeby wypróbuj kilka iteracji, aby spełnić wymagania dotyczące TRNG (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

Uwaga: w każdym porcie OpenThread musi być zaimplementowany jeden z tych interfejsów API.

Deklaracje interfejsu API:

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

lub

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

Wymaganie dotyczące pamięci trwałej można spełnić, wdrażając jeden z 2 wymienionych powyżej interfejsów API. Interfejs Flash API implementuje sterownik pamięci flash, a interfejs Settings API udostępnia funkcje dla implementacji operacji flash w warstwie wyższej.

Te interfejsy API udostępniają warstwie wyższej:

• Dostępny rozmiar pamięci trwałej używanej do przechowywania danych aplikacji (np. aktywnego lub oczekującego zbioru danych operacyjnych, bieżących parametrów sieci i danych logowania urządzeń wątku do ponownego dołączenia po resecie).
• operacje odczytu, zapisu, kasowania i zapytań dotyczących stanu pamięci flash;

W pliku konfiguracji platformy przykładowej użyj interfejsu OPENTHREAD_CONFIG_PLATFORM_FLASH_API_ENABLE, aby wskazać, którego interfejsu API ma używać platforma. Jeśli ustawisz wartość 1, musisz zaimplementować interfejs Flash API. W przeciwnym razie musisz zaimplementować interfejs API ustawień.

Ten parametr musi być ustawiony w pliku /openthread/examples/platforms/platform-name/openthread-core-platform-name-config.h.

Logowanie

Uwaga: ten interfejs API jest opcjonalny.

Deklaracja interfejsu API:

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

Interfejs Logging API implementuje funkcje rejestrowania i debugowania OpenThread, oferując wiele poziomów wyjścia debugowania. Ten interfejs API jest opcjonalny, jeśli nie planujesz korzystać z logowania OpenThread na nowej platformie sprzętowej.

Najwyższy i najbardziej szczegółowy poziom to OPENTHREAD_LOG_LEVEL_DEBG, który drukuje wszystkie informacje o nieprzetworzonych pakietach i rejestruje wiersze przez port szeregowy lub na terminalu. Wybierz poziom debugowania, który najlepiej odpowiada Twoim potrzebom.

Specyficzne dla systemu

Deklaracja interfejsu API:

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

Interfejs API dla systemu zapewnia głównie operacje inicjalizacji i dezinicjalizacji na wybranej platformie sprzętowej. Biblioteka OpenThread nie wywołuje tego interfejsu API, ale może być przydatna dla systemu lub RTOS. W tym pliku źródłowym możesz też zaimplementować inicjalizację innych modułów (np. UART, Radio, Random, Misc/Reset).

Implementacja tego interfejsu API zależy od przypadku użycia. Jeśli chcesz użyć wygenerowanych aplikacji interfejsu wiersza poleceń i NCP na danej platformie, musisz zaimplementować ten interfejs API. W przeciwnym razie można zaimplementować dowolny interfejs API, aby zintegrować przykładowe sterowniki platformy z systemem lub RTOS.