Dodanie BLE wydaje się banalne: kup moduł, zaimplementuj obsługę, odpal testową apkę i voilà. Szczególnie, gdy goni nas czas na zrobienie POC (Proof of Concept).

Ale, jak to w życiu bywa, diabeł tkwi w szczegółach. Ci, co mają już na karku kilka projektów embedded, wiedzą, że łatwo nie będzie. Prędzej czy później zaczynamy się zastanawiać nad:

• Kosztami: Jak na ironię, te "niewielkie" moduły mogą mocno nadszarpnąć budżet.
• Miejscem na płytce: Czasem to, co chcielibyśmy upchnąć, a co faktycznie się zmieści, to dwie różne historie.
• Zasobami mikrokontrolera: Flash i RAM to nasze złoto, a czas CPU to nasz czas. Trzeba to wszystko mądrze rozgospodarować.

I tak dalej, i tak dalej. Każdy projekt rzuca przed nami nowe wyzwania.

Wybór BLE to nie tylko kwestia techniczna, ale strategiczna. Trzeba dobrze poznać teren - od sprzętu, przez oprogramowanie, aż po ograniczenia budżetowe. BLE daje nam fajne możliwości, ale jak każda technologia, wymaga rozważnego podejścia.

Zanim zagłębimy się w meandry

Zanim wskoczymy na głęboką wodę, warto rzucić okiem na podstawy BLE. Choć opcji jest co niemiara, skupimy się na kilku kluczowych aspektach, zaczynając od krótkiego wprowadzenia w strukturę BLE.

BLE od podszewki

Urządzenie BLE to nie tylko kawałek sprzętu, ale przemyślana konstrukcja składająca się z trzech warstw, z których każda ma swoje zadanie. Dziś bazujemy na tych trzech filarach, ale dla porządku rzucę też okiem na ich wewnętrzne mechanizmy - bez zbytniego zagłębiania się w techniczne szczegóły.

APP - Tutaj dzieje się magia. To warstwa, gdzie nasza biznesowa logika spotyka się z danymi. Kontrolujemy stąd stos Bluetooth i dajemy życie naszej aplikacji, kształtując ją zgodnie z naszymi potrzebami.

HOST - To mózg operacji, gdzie definiowane są protokoły i organizacja pracy. Składa się z kilku kluczowych elementów:

• GAP (Generic Access Profile) - Tutaj ustalane są role urządzenia (broadcaster, observer, central, peripheral).
• GATT (Generic Attribute Profile) - Zarządza usługami i charakterystykami, pełniąc rolę serwera i/lub klienta.
• ATT (Attribute Protocol) - Protokół atrybutów, który określa, jak identyfikować i pracować z charakterystykami.
• SM (Security Manager) - Pilnuje bezpieczeństwa danych i połączeń.
• L2CAP (Logical Link Controller and Adaptation Protocol) - Dostosowuje dane do standardu Bluetooth, zajmując się ich multiplexingiem.
• HCI - To most między HOST a CONTROLLER, definiujący zasady komunikacji.

CONTROLLER - Tutaj sprzęt bierze sprawy w swoje ręce, dzieląc się na:

• LL (Link Layer) - Zarządza połączeniami, rozgłaszaniem i utrzymaniem łączności.
• PHY (Physical Layer) - Bezpośrednio steruje radiem w paśmie ISM 2.4 GHz, będąc sercem sprzętowej części BLE.
  ‍

Jakie mamy możliwości?

Znając strukturę BLE, możemy wydzielić trzy główne podejścia do implementacji:

1. Wszystko w jednym mikrokontrolerze: Proste, ale wymagające, gdyż zasoby mikrokontrolera są ograniczone.
2. Aplikacja i Host na jednym mikrokontrolerze, Controller na innym: Daje większą elastyczność i pozwala na optymalizację zasobów.
3. Aplikacja na jednym mikrokontrolerze, Host i Controller na drugim: Minimalizuje obciążenie mikrokontrolera aplikacji, ale wymaga więcej miejsca na płytce PCB.

Opcja 1: Wszystko pod jednym dachem

Mamy przed sobą dwie główne ścieżki działania:

1. Wykorzystanie standardowego mikrokontrolera jednordzeniowego do samodzielnej implementacji całego stosu BLE - to podejście wymaga sporego nakładu pracy i czasu, jeśli zdecydujemy się na ręczne budowanie wszystkiego od podstaw.
2. Korzystanie z gotowych bibliotek do implementacji stosu BLE (na przykład bluekitchen/btstack), co pozwala na efektywniejsze wykorzystanie dostępnych narzędzi i szybszą realizację projektu. Jednak taka metoda pochłania znaczną część zasobów mikrokontrolera (Flash, RAM, moc obliczeniowa), co może ograniczać możliwości naszej głównej aplikacji.

Alternatywnie, możemy zdecydować się na mikrokontroler dwurdzeniowy, który oferuje dedykowany rdzeń do obsługi BLE, jak na przykład STM32WB55. Dzięki wykorzystaniu interfejsu IPCC (Inter-processor communication controller), możliwa jest komunikacja między rdzeniami, co znacząco ułatwia zarządzanie i zmniejsza obciążenie zasobów przeznaczonych dla aplikacji użytkownika.

W przypadku wyboru jednego mikrokontrolera dla całego rozwiązania (bez względu na to, czy zdecydujemy się na samodzielną implementację, czy skorzystamy z gotowych bibliotek), mogłoby się wydawać, że jest to opcja najbardziej ekonomiczna. Jednakże, należy pamiętać, że kompleksowa obsługa stosu BLE wymaga odpowiednich zasobów mikrokontrolera, co może oznaczać konieczność wyboru modelu z większą ilością pamięci Flash i/lub RAM, lub nawet specjalizowanego mikrokontrolera z wbudowaną obsługą BLE.

Jedną z zalet tego rozwiązania jest potencjalna oszczędność miejsca na płytce PCB, pod warunkiem, że wybrany mikrokontroler zajmuje mniej miejsca niż alternatywna konfiguracja z dwoma oddzielnymi układami.

‍

Opcja 2: Podział zadań - Aplikacja i Host na głównym mikrokontrolerze, Controller na osobnym układzie

W tej konfiguracji, warstwa Controllera jest przeniesiona do oddzielnego układu, pozostawiając na głównym mikrokontrolerze zarówno aplikację, jak i część stosu BLE określaną jako Host. Przykładem układu, który może pełnić rolę kontrolera, jest CC2564C od Texas Instruments, komunikujący się za pomocą interfejsu UART.

Taki podział pracy daje nam elastyczność w zarządzaniu komponentami. Możliwość wymiany modułu kontrolera na inny w razie potrzeby, bez zakłócania działania reszty systemu, jest tu kluczową zaletą. Dzięki standardowemu protokołowi HCI, mamy wolną rękę w wyborze najodpowiedniejszego układu scalonego dla naszych potrzeb.

Jednocześnie, cała warstwa Host, wraz z zarządzaniem rolami, dostępami, a także definiowaniem atrybutów i charakterystyk, jest implementowana na głównym mikrokontrolerze. To oznacza, że musimy liczyć się z koniecznością alokacji odpowiednich zasobów mikrokontrolera, takich jak pamięć RAM, Flash oraz moc obliczeniowa.

Należy również pamiętać, że wykorzystanie dwóch oddzielnych układów wymaga dodatkowego miejsca na płytce PCB. W przypadku projektowania mniejszych urządzeń, ograniczona przestrzeń na płytce może stanowić wyzwanie.

W skrócie, ta opcja oferuje większą elastyczność i możliwość optymalizacji zasobów, ale wymaga starannego planowania przestrzeni na płytce oraz zarządzania zasobami mikrokontrolera.

‍

Opcja 3: Rozdzielenie aplikacji i stosu BLE na dwa układy

W tej konfiguracji, nasza aplikacja działa na głównym mikrokontrolerze, podczas gdy cały stos BLE jest obsługiwany przez oddzielny układ. To rozwiązanie różni się od poprzedniego tym, że dedykuje cały jeden układ wyłącznie do zarządzania komunikacją BLE, pozostawiając aplikacji pełne zasoby głównego mikrokontrolera.

Zalety i wyzwania tego podejścia:

• Przestrzeń na płytce PCB: Musimy znaleźć miejsce dla obu układów i zapewnić ich skuteczną komunikację, co może być wyzwaniem w projektach o ograniczonej przestrzeni.
• Koszty: Użycie dwóch oddzielnych układów może zwiększyć koszty produkcji w porównaniu do wykorzystania jednego, bardziej zaawansowanego mikrokontrolera.
• Optymalizacja zasobów: Przeniesienie całego stosu BLE na osobny układ znacząco zmniejsza obciążenie głównego mikrokontrolera, co pozwala na lepsze wykorzystanie jego zasobów dla potrzeb aplikacji.
• Elastyczność w wyborze układu BLE: Chociaż gotowe układy BLE często posiadają z góry określony protokół komunikacji, co może utrudniać ich wymianę, to jednak wybór takiego rozwiązania pozwala na łatwiejszą aktualizację i skalowanie systemu.

Podsumowując możliwości BLE

W dzisiejszym omówieniu skoncentrowaliśmy się na różnych metodach wdrażania komunikacji BLE w urządzeniach.
Wybór odpowiedniego podejścia wymaga rozważenia kilku kluczowych czynników:

• Dostępna przestrzeń na płytce PCB: W przypadku projektów o ograniczonych rozmiarach, najbardziej efektywnym rozwiązaniem może okazać się integracja aplikacji i stosu BLE w jednym mikrokontrolerze, co pozwala zaoszczędzić cenne miejsce.
• Łatwość implementacji i zarządzania: Ważne jest, aby wybrać takie rozwiązanie, które nie tylko ułatwi szybkie wdrożenie projektu, ale również zapewni łatwość obsługi i aktualizacji w przyszłości. To klucz do zachowania terminowości i szybkiego wprowadzenia produktu na rynek.
• Dostępne zasoby mikrokontrolera: Należy ocenić, czy posiadany mikrokontroler dysponuje wystarczającymi zasobami (pamięć Flash, RAM, moc obliczeniowa) do obsługi zarówno aplikacji, jak i stosu BLE. W niektórych przypadkach może okazać się konieczne użycie bardziej zaawansowanego mikrokontrolera.
• Koszty produkcji: W kontekście produkcji na większą skalę, koszty komponentów mogą znacząco wpłynąć na ogólny budżet projektu. W sytuacjach, gdzie produkcja jednostkowa jest droższa, ale planowana jest produkcja masowa, bardziej opłacalne może być zintegrowanie wszystkiego w jednym mikrokontrolerze.

‍Referencje

• BLE Fundamentals
• BLE Core Specification

#GoodByte #BLE

‍

‍

‍