Stos czujników

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

Poniższy rysunek przedstawia stos czujników Androida. Każdy komponent komunikuje się tylko z komponentami bezpośrednio nad i pod nim, chociaż niektóre czujniki mogą ominąć koncentrator czujników, gdy jest on obecny. Sterowanie przepływa z aplikacji do czujników, a dane przepływają od czujników do aplikacji.

Warstwy i właściciele stosu czujników Android

Rysunek 1. Warstwy stosu czujników Androida i ich właściciele

SDK

Aplikacje uzyskują dostęp do czujników za pośrednictwem interfejsu API Sensors SDK (Software Development Kit) . SDK zawiera funkcje do wyświetlania listy dostępnych czujników i rejestracji w czujniku.

Podczas rejestracji w czujniku aplikacja określa preferowaną częstotliwość próbkowania i wymagania dotyczące opóźnień.

  • Na przykład aplikacja może zarejestrować się w domyślnym akcelerometrze, żądając zdarzeń z częstotliwością 100 Hz i umożliwiając zgłaszanie zdarzeń z 1-sekundowym opóźnieniem.
  • Aplikacja będzie odbierać zdarzenia z akcelerometru z częstotliwością co najmniej 100Hz i ewentualnie z opóźnieniem do 1 sekundy.

Więcej informacji o pakiecie SDK znajdziesz w dokumentacji dla programistów.

Struktura

Struktura odpowiada za połączenie kilku aplikacji z warstwą HAL . Sam HAL jest pojedynczym klientem. Bez tego multipleksowania na poziomie struktury tylko jedna aplikacja może uzyskać dostęp do każdego czujnika w danym momencie.

  • Gdy pierwsza aplikacja rejestruje się w czujniku, struktura wysyła do warstwy HAL żądanie aktywacji czujnika.
  • Gdy dodatkowe aplikacje rejestrują się w tym samym czujniku, struktura uwzględnia wymagania każdej aplikacji i wysyła zaktualizowane żądane parametry do warstwy HAL.
    • Częstotliwość próbkowania będzie maksymalną żądaną częstotliwością próbkowania, co oznacza, że ​​niektóre aplikacje będą otrzymywać zdarzenia z częstotliwością wyższą niż żądana.
    • Maksymalne opóźnienie raportowania będzie minimalne z żądanych. Jeśli jedna aplikacja zażąda jednego czujnika z maksymalnym opóźnieniem raportowania równym 0, wszystkie aplikacje będą otrzymywać zdarzenia z tego czujnika w trybie ciągłym, nawet jeśli niektóre zażądały czujnika z niezerowym maksymalnym opóźnieniem raportowania. Aby uzyskać więcej informacji, zobacz Parting .
  • Gdy ostatnia aplikacja zarejestrowana w jednym czujniku wyrejestruje się z niego, framework wysyła do HAL żądanie dezaktywacji czujnika, aby nie zużywać niepotrzebnie energii.

Wpływ multipleksowania

Ta potrzeba warstwy multipleksowania w ramach struktury wyjaśnia niektóre decyzje projektowe.

  • Gdy aplikacja żąda określonej częstotliwości próbkowania, nie ma gwarancji, że zdarzenia nie pojawią się szybciej. Jeśli inna aplikacja zażądała tego samego czujnika w szybszym tempie, pierwsza aplikacja również otrzyma je z większą szybkością.
  • Ten sam brak gwarancji dotyczy żądanego maksymalnego opóźnienia raportowania: aplikacje mogą otrzymywać zdarzenia ze znacznie mniejszym opóźnieniem niż żądały.
  • Poza częstotliwością próbkowania i maksymalnym opóźnieniem raportowania aplikacje nie mogą konfigurować parametrów czujnika.
    • Na przykład wyobraźmy sobie fizyczny czujnik, który może działać zarówno w trybie „wysokiej dokładności”, jak i „małego poboru mocy”.
    • Tylko jeden z tych dwóch trybów może być używany na urządzeniu z Androidem, ponieważ w przeciwnym razie aplikacja może zażądać trybu wysokiej dokładności, a inny trybu niskiego poboru mocy; nie byłoby sposobu, aby framework spełniał wymagania obu aplikacji. Framework musi zawsze być w stanie zadowolić wszystkich swoich klientów, więc nie jest to opcja.
  • Nie ma mechanizmu przesyłania danych z aplikacji do czujników lub ich sterowników. Gwarantuje to, że jedna aplikacja nie może modyfikować zachowania czujników, łamiąc inne aplikacje.

Połączenie czujników

Struktura systemu Android zapewnia domyślną implementację niektórych czujników złożonych. Gdy żyroskop , akcelerometr i magnetometr są obecne na urządzeniu, ale nie ma czujników wektora obrotu , grawitacji i przyspieszenia liniowego , platforma implementuje te czujniki, dzięki czemu aplikacje mogą nadal z nich korzystać.

Domyślna implementacja nie ma dostępu do wszystkich danych, do których mają dostęp inne implementacje, i musi działać na SoC, więc nie jest tak dokładna ani tak energooszczędna, jak inne implementacje. W miarę możliwości producenci urządzeń powinni zdefiniować własne połączone czujniki (wektor obrotu, przyspieszenie grawitacyjne i liniowe, a także nowsze czujniki kompozytowe, takie jak wektor obrotu gry ), zamiast polegać na tej domyślnej implementacji. Producenci urządzeń mogą również poprosić dostawców chipów czujników o dostarczenie im implementacji.

Domyślna implementacja fuzji czujników nie jest utrzymywana i może spowodować awarię CTS urządzeń opierających się na niej.

Pod maską

Ta sekcja jest dostarczana jako informacje ogólne dla osób utrzymujących kod platformy Android Open Source Project (AOSP). Nie dotyczy producentów sprzętu.

JNI

Framework wykorzystuje interfejs Java Native Interface (JNI) powiązany z android.hardware i znajdujący się w katalogu frameworks/base/core/jni/ . Ten kod wywołuje kod natywny niższego poziomu, aby uzyskać dostęp do sprzętu czujnika.

Natywna platforma

Framework natywny jest zdefiniowany w frameworks/native/ i zapewnia natywny odpowiednik pakietu android.hardware . Natywna platforma wywołuje serwery proxy Binder IPC w celu uzyskania dostępu do usług specyficznych dla czujników.

segregator IPC

Serwery proxy Binder IPC ułatwiają komunikację ponad granicami procesu.

HAL

Interfejs API warstwy abstrakcji sprzętu czujników (HAL) jest interfejsem między sterownikami sprzętu a platformą Android. Składa się z jednego interfejsu HAL sensor.hi jednej implementacji HAL, którą nazywamy sensorami.cpp.

Interfejs jest definiowany przez współtwórców Androida i AOSP, a implementację zapewnia producent urządzenia.

Interfejs HAL czujnika znajduje się w hardware/libhardware/include/hardware . Więcej informacji można znaleźć w pliku sensors.h .

Cykl wydania

Implementacja warstwy HAL określa, którą wersję interfejsu HAL implementuje, ustawiając your_poll_device.common.version . Istniejące wersje interfejsu HAL są zdefiniowane w sensorach.h, a ich funkcjonalność jest powiązana z tymi wersjami.

Platforma Android obsługuje obecnie wersje 1.0 i 1.3, ale wkrótce wersja 1.0 nie będzie już obsługiwana. Ta dokumentacja opisuje zachowanie wersji 1.3, do której powinny zostać uaktualnione wszystkie urządzenia. Aby uzyskać szczegółowe informacje na temat uaktualniania do wersji 1.3, zobacz Zaniechanie wersji HAL .

Sterownik jądra

Sterowniki czujników wchodzą w interakcję z urządzeniami fizycznymi. W niektórych przypadkach implementacja warstwy HAL i sterowniki są tą samą jednostką oprogramowania. W innych przypadkach integrator sprzętu prosi producentów układów czujników o dostarczenie sterowników, ale to oni piszą implementację HAL.

We wszystkich przypadkach za implementację warstwy HAL i sterowniki jądra odpowiadają producenci sprzętu, a system Android nie zapewnia preferowanych metod ich pisania.

Piasta czujnika

Stos czujników urządzenia może opcjonalnie zawierać koncentrator czujników, przydatny do wykonywania niektórych obliczeń niskiego poziomu przy małej mocy, podczas gdy SoC może być w trybie wstrzymania. Na przykład na tych chipach można przeprowadzić liczenie kroków lub fuzję czujników. Jest to również dobre miejsce do zaimplementowania grupowania czujników, dodając sprzętowe FIFO dla zdarzeń czujnika. Aby uzyskać więcej informacji, zobacz Tworzenie partii .

Uwaga: Aby opracować nowe funkcje ContextHub, które wykorzystują nowe czujniki lub diody LED, możesz również użyć Neonkey SensorHub podłączonego do płytki rozwojowej Hikey lub Hikey960.

Sposób zmaterializowania koncentratora czujników zależy od architektury. Czasami jest to oddzielny chip, a czasami jest zawarty w tym samym chipie, co SoC. Ważną cechą koncentratora czujników jest to, że powinien on zawierać wystarczającą ilość pamięci do przetwarzania wsadowego i zużywać bardzo mało energii, aby umożliwić implementację czujników Android o niskim poborze mocy. Niektóre koncentratory czujników zawierają mikrokontroler do obliczeń ogólnych oraz akceleratory sprzętowe, które umożliwiają obliczenia bardzo małej mocy dla czujników o małej mocy.

Jaka jest architektura koncentratora czujników i jak komunikuje się z czujnikami i SoC (szyna I2C, magistrala SPI, …) nie jest określona przez Androida, ale powinna mieć na celu zminimalizowanie ogólnego zużycia energii.

Jedną z opcji, która wydaje się mieć znaczący wpływ na prostotę implementacji, jest posiadanie dwóch linii przerwań biegnących z koncentratora czujnika do SoC: jedna dla przerwań budzenia (dla czujników budzenia), a druga dla przerwań bez przebudzenia (dla czujników bez wybudzenia).

Czujniki

To fizyczne chipy MEM dokonujące pomiarów. W wielu przypadkach na tym samym chipie znajduje się kilka fizycznych czujników. Na przykład niektóre chipy zawierają akcelerometr, żyroskop i magnetometr. (Takie chipy są często nazywane chipami 9-osiowymi, ponieważ każdy czujnik dostarcza dane w 3 osiach.)

Niektóre z tych chipów zawierają również pewną logikę do wykonywania zwykłych obliczeń, takich jak wykrywanie ruchu, wykrywanie kroków i 9-osiowa fuzja czujników.

Chociaż wymagania i zalecenia dotyczące mocy i dokładności CDD dotyczą czujnika systemu Android, a nie czujników fizycznych, wymagania te wpływają na wybór czujników fizycznych. Na przykład wymóg dokładności wektora rotacji gry ma wpływ na wymaganą dokładność żyroskopu fizycznego. To do producenta urządzenia należy określenie wymagań dotyczących czujników fizycznych.