Zaimplementuj interfejsy API abstrakcji platformy

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Wyświetl źródło na GitHubie

OpenThread jest niezależny od systemu operacyjnego i platformy oraz wąską warstwą abstrakcji platformy (PAL). Ten identyfikator PAL definiuje:

Architektura portowa
  • 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&#39. Udostępniamy wiele poziomów danych debugowania. Ten interfejs API jest opcjonalny, jeśli nie planujesz używać usługi OpenThread&#39'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.