Do tej pory nasza płytka deweloperska nRF5340DK działała jako urządzenie typu peripheral, czyli serwer w architekturze Bluetooth Low Energy. Po włączeniu moduł rozpoczynał rozgłaszanie (advertising) i oczekiwał na połączenie z telefonem lub innym klientem (central). Po nawiązaniu połączenia możliwe było sterowanie diodą LED za pomocą aplikacji nRF Connect, z użyciem charakterystyk zdefiniowanych w oprogramowaniu płytki.
O ile wygodniej byłoby jednak, gdybyśmy mogli włączać i wyłączać diodę za pomocą dedykowanego pilota BLE, bez potrzeby korzystania ze smartfona. Taki pilot pozwoliłby na szybkie i wygodne sterowanie urządzeniem, szczególnie w sytuacjach, gdy sięganie po telefon jest niepraktyczne.
Piloty zdalnego sterowania oparte na BLE można znaleźć na portalach aukcyjnych i w sklepach z elektroniką. Często są oferowane pod nazwą „Bluetooth Media Button” lub „przycisk Bluetooth” i domyślnie są przeznaczone do sterowania funkcjami multimedialnymi, takimi jak regulacja głośności czy odtwarzanie utworów na smartfonach. Aby taki pilot współpracował z naszą płytką, niezbędne jest, aby działał w standardzie Bluetooth Low Energy (BLE), ponieważ zestaw nRF5340DK obsługuje jedynie tę wersję protokołu Bluetooth.
Warto pamiętać, że wielu producentów nie podaje jednoznacznie, czy ich urządzenie wspiera standard BLE, a klasyczny Bluetooth nie jest kompatybilny z BLE. Dlatego – dla pewności – najlepiej wybrać pilot przynajmniej w wersji Bluetooth 4.2, który niemal zawsze zawiera BLE. Kupno odpowiedniego modelu pozwoli na integrację z płytką nRF5340DK i umożliwi wykorzystanie pilota jako urządzenia HID (Human Interface Device), co otwiera możliwość użycia funkcji BLE do komunikacji i sterowania. Możemy też skorzystać z klawiatury pracującej w standardzie BLE.
Co to jest HID?
HID to standard komunikacji określający zasady wymiany danych między urządzeniami typu Device (np. pilotem lub klawiaturą) a urządzeniami typu Host (takimi jak smartfon, komputer czy, w omawianym przypadku, nasza płytka deweloperska). Standard ten pierwotnie powstał na potrzeby urządzeń USB, aby mogły one pracować na jednolitych zasadach, bez konieczności instalowania dodatkowych sterowników.
W technologii Bluetooth rozróżniamy dwa jego warianty:
- Classic Bluetooth HID – standard działający w ramach tradycyjnego protokołu Bluetooth, stosowany tam, gdzie wymagana jest większa przepustowość i szybkość transmisji danych.
- Bluetooth Low Energy HID – zoptymalizowany pod kątem urządzeń o niskim poborze mocy, takich jak piloty, klawiatury czy myszki. Często nazywany jest też HID over GATT (HoG).
My przyjrzymy się drugiemu wariantowi.
W kontekście BLE, HID to profil Bluetooth – czyli specyfikacja opisująca konkretny przypadek użycia komunikacji. Profil można uznać za zbiór scenariuszy użycia określających, jak serwisy i charakterystyki współpracują ze sobą w celu realizacji konkretnej funkcjonalności. Aby lepiej zobrazować zagadnienie, posłużymy się przykładem: profil baterii opisuje nam, jak i kiedy informacja o stanie baterii zostanie przesłana przez cały stos Bluetooth.
Konfiguracja płytki
Zaczniemy od rekonfiguracji projektu w pliku prj.conf.
Ponieważ pilot działa jako urządzenie peryferyjne (peripheral), zadaniem naszej płytki będzie połączenie się z nim jako urządzenie centralne (central). Pierwsza z nowych opcji konfiguracyjnych włącza tę rolę na poziomie warstwy GAP. Kolejna opcja pozwala płytce działać jako klient na poziomie warstwy GATT.
Zephyr umożliwia kontrolę nad Bluetooth za pomocą poleceń dostępnych w shellu, co pozwala na skonfigurowanie połączenia bez potrzeby pisania dodatkowego kodu. Trzecia opcja dodaje komendy związane z BLE do konsoli.
Aby uniknąć konfliktów, wyłączmy dotychczasowe użycie Bluetooth, które mogłoby przeszkadzać w eksperymentach. Wystarczy zakomentować wywołanie funkcji bt_control_init() w pliku main.c z poprzedniej części kursu. To właśnie zaleta modułowego kodu – sterowanie rozbudowaną funkcjonalnością można realizować za pomocą pojedynczych linii.
Teraz wystarczy skompilować projekt, wgrać go na płytkę i można zaczynać zabawę.
Zabawa shellem
W trzecim odcinku naszego kursu dość powierzchownie zapoznaliśmy się z shellem Zephyra. W tej części będziemy go intensywnie używać. Aby lepiej go poznać i sprawdzić, czy komendy Bluetooth zostały poprawnie dodane, wpiszmy polecenie help w terminalu z logami i shellem. Port tego terminalu jest wyświetlony we wtyczce nRF Connect w sekcji CONNECTED DEVICES.
Warto zauważyć, że shell w Zephyrze wspiera autouzupełnianie poleceń za pomocą klawisza <Tab>. Możemy także wygodnie przeglądać i wywoływać wcześniej wprowadzone komendy, korzystając z klawiszy strzałek w górę i w dół. Na liście wyświetlonych komend możemy zauważyć dodaną już przez nas komendę led – jednak to, co nas teraz interesuje, to komendy bt i gatt.
Ponieważ wyłączyliśmy automatyczny proces inicjalizacji Bluetooth, teraz musimy uruchomić go ręcznie za pomocą komendy bt init. Więcej informacji o komendach shell dla Bluetooth można znaleźć pod linkiem [2]. Następnie, zgodnie z działaniem prawdziwego projektu, rozpoczniemy skanowanie – jak przystało na każde porządne urządzenie typu central.
Włączenie trybu szczegółowego (verbose) skanowania powoduje wyświetlanie dodatkowych informacji o wykrytych urządzeniach Bluetooth. Dzięki temu uzyskamy szczegółowe dane, takie jak moc sygnału (RSSI), typy urządzeń czy treść wysyłanych danych rozgłoszeniowych.
Kolejno wpisujemy polecenia w konsoli:
- bt init
- bt scan-verbose-output on
- bt scan on