Zaloguj
Nowoczesne, wydajne mikrokontrolery są głównie przeznaczone do układów sterowania w urządzeniach embeded. W rozbudowanych, skomplikowanych zadaniach, wykonywanych przez te urządzenia zasadne staje się stosowanie systemów czasu rzeczywistego RTOS. Umożliwia on podział algorytmów sterowania na mniejsze zadania i ich realizację z wykorzystaniem multitaskingu. Czas procesora jest dzielony na poszczególne wątki, na ich przełączanie i monitorowanie prawidłowej pracy. Dlatego RTOS wymaga z jednej strony dużych zasobów mikrokontrolera, a z drugiej sporej wiedzy programistów.
Geneza
Jakiś czas temu dzięki rozwojowi mikroelektroniki stało się możliwe umieszczenie że w strukturze mikroprocesora więcej niż jednego rdzenia. Można wtedy tak podzielić zadania, że są wykonywane przez poszczególne rdzenie jednocześnie, bez użycia multitaskingu. Wymaga to podobnego podejścia do programowania, jak w wypadku użycia RTOS: dzielenia wykonywania algorytmu na wątki, synchronizacji wymiany danych pomiędzy nimi oraz dodatkowych mechanizmów fizycznej komunikacji pomiędzy rdzeniami.
Jak wspomniano we wstępie, mikrokontrolery z rodziny STM32WB to połączenie uniwersalnego, wydajnego rdzenia Cortex-M4, zoptymalizowanego dla małego zużycia energii, z rdzeniem Cortex M0+ i modułem transceivera radiowego pracującego w paśmie 2,4 GHz, zgodnego z normą IEEE 802.15.4. Jak się łatwo domyślić, mikrokontrolery STM32WB są przeznaczone do stosowania w aplikacjach, w których istnieje potrzeba wykorzystania łącza radiowego ze szczególnym naciskiem na standard Bluetooth 5.0 (BLE). Dzięki zgodności z normą IEE 802.15.4 jest też możliwa implementacja innych protokołów komunikacyjnych, takich jak Thread, ZigBee i oczywiście własnych, tzw. autorskich (rysunek 1).
Zasoby i właściwości mikrokontrolerów STM32WB pokazano na rysunku 2. Tak wyposażone układy mogą być z powodzeniem stosowane w wielu aplikacjach, szczególnie w zastosowaniach Internetu Rzeczy. Na rysunku 3 pokazano przykładowe aplikacje proponowane przez producenta.
Współdzielenie zasobów
Dwa rdzenie w jednej strukturze mają wspólną część zasobów fizycznych, którą muszą dzielić się między sobą. Na rysunku 4 zilustrowano sposób, w który jest to realizowane dla CPU1 (Cortex M4) i CPU2 (Cortex M0+). Widać wyraźnie, że nie są to dwie równorzędne jednostki. Wspólne zasoby obejmują pamięć Flash, część pamięci SRAM (nazwaną SRAM2), bloki RVV, PWR i EXTI. Jeżeli chodzi o moduły peryferyjne, to współdzielone są: IPCC, HSEM, AES2, PKA i RNG. Rdzeń główny CPU1 ma wyłączny dostęp do wszystkich standardowych modułów peryferyjnych: kontrolera DMA, liczników TIM, interfejsów USART, I2C, USB, QUADSPI. Ponadto, CPU1 ma pamięć SRAM nazwaną SRAM1.
Mikrokontroler oparty o dwa rdzenie oparte o różnej architekturze (Cortex-M4 vs Cortex-M0+), taktowane przebiegami o różnej częstotliwości musi mieć możliwość dostępu do współdzielonych zasobów niezależnie od prędkości, z którą pracuje. Dlatego w strukturę układu wbudowano specjalny moduł ART-Accelerator (Adaptive Real-Time memory Accelerator) zapewniający prawidłowy rozdział czasowy przy dostępie do pamięci programu Flash przez oba rdzenie oraz układ arbitrażu rozstrzygający konflikty przy jednoczesnej próbie dostępu. Pokazano to na rysunku 5.
Podobnie jak w wypadku systemów czasu rzeczywistego RTOS, praca więcej niż jednego wątku na dwóch lub więcej rdzeniach wymaga rozwiązania problemów synchronizacji przesyłania danych pomiędzy wątkami i zabezpieczenia przed konfliktami dostępu do zasobów współdzielonych. W typowych systemach RTOS do komunikacji pomiędzy uruchomionymi zadaniami jest przeznaczona kolejka oparta o bufor FIFO, a do synchronizacji pomiędzy procesami i wykluczania niepożądanego dostępu do wspólnych zasobów używa się semaforów.
W mikrokontrolerach z rodziny STM32WB wbudowano moduł HSEM (rysunek 6) będący sprzętową implementacją mechanizmu semaforów. Jego podstawowym zadaniem jest synchronizacja procesów i zarządzanie dostępem do współdzielonych zasobów. HSEM jest częścią magistrali AHB i jest zbudowany z dwóch elementów: interfejsu AHB i kontrolera przerwań. Kontroler przerwań jest oddzielny dla każdej z jednostki. Przerwania mają uprawnienia (blokowanie/odblokowanie), rejestr statusu i maskę. Dostępnych jest 32 semaforów ponumerowanych od 0 do 31. Każdy z nich składa się z dwóch rejestrów:
- Write/Read register przeznaczonego do zablokowania (lock) semafora w procedurze dwuetapowej i odczytywania statusu potwierdzenia.
- ReadLock register używanego do blokowania semafora w procedurze jednoetapowej.
Numer identyfikacyjny ID magistrali AHB jest używany do identyfikacji procesora uzyskującego dostęp do semafora. Ten ID jest przechowywany w semaforze w czasie jego blokowania i może być odczytywany zwrotnie z jego statusu, jako Core ID.
W dwuetapowej procedurze zapisu blokady „wolny” semafor zostanie zablokowany przez zapisanie bitu LOCK rejestru Write/Read semafora. Identyfikator Core ID oraz Process ID użyte podczas zapisu są przechowywane w semaforze. Odczytując rejestr Write/Read proces musi sprawdzić, czy semafor został przez niego zablokowany. Jeżeli odczytane zwrotnie Core ID i Process ID nie są takie same, jak zapisane w rejestrze, to semafor został zablokowany przez inny proces. Jeżeli są takie same, to semafor został zablokowany przez nasz proces. Dwuetapową procedurę blokowania semaforów pokazano na rysunku 7. Odblokowanie semafora odbywa się przez wyzerowanie bitu LOCK.
W procedurze jednoetapowej „wolny” semafor zostanie zablokowany po odczytaniu rejestru ReadLock. Kiedy wartość Core ID zawarta w rejestrze semafora jest równa Core ID CPU, który blokuje semafor i identyfikator procesu jest równy 0x0000, to semafor zostanie zablokowany. W procedurze jednoetapowej nie stosuje się identyfikatora procesu. Jeżeli odczytany core ID nie jest zgodny z ID CPU i Proces ID nie jest równy 0x0000, to semafor został zablokowany przez inny proces. Semafor można odblokować przez wyzerowanie bitu LOCK z odpowiednim Core ID i Process ID, jak pokazano na rysunku 8.
Procedury blokowania jedno- i dwuetapowego można stosować jednocześnie, ale procedura dwuetapowa nie może używać ID procesu równego 0x0000.
Do wymiany danych pomiędzy rdzeniami jest przeznaczony moduł IPCC (Inter-Processor Communication Controller). Komunikacja może być jednokierunkowa (simplex) lub dwukierunkowa (half duplex). W trybie simplex kanał transmisji pozwala na przesyłanie wiadomości w jednym kierunku od jednostki „A” do jednostki „B”. Tryb half duplex wykorzystuje jeden kanał transmisji do przesyłania wiadomości i potwierdzeń, naprzemiennie w obu kierunkach pomiędzy obiema jednostkami. Przesyłanie wiadomości jest związane z generowaniem przerwań. IPCC nie ma swoich buforów danych i dane przeznaczone do przesyłania powinny być umieszczone we współdzielonej pamięci RAM. Moduł jest częścią modułu AHB Slave i logicznie można go podzielić na 2 części: AHB Interface i układ zarządzający przerwaniami Interrupt management (rysunek 9).
Kanałów może być maksymalnie 6, a każdy z nich ma swój znacznik statusu używany jako status wysyłania dla jednego z CPU i status odbierania wiadomości dla drugiego z CPU. Ponieważ rejestr statusowy jest wspólny dla obu CPU, to jest zabezpieczony przed konfliktami dostępu.
Każdy z kanałów transmisji ma zdefiniowany kierunek przepływu danych od CPU nadawcy do CPU odbiorcy. CPU nadawcy może sygnalizować zajęcie kanału przez ustawienie bitu statusu zajętości CHnF. Bit CHnF jest ustawiany przez ustawienie bitu CHnS, sygnalizując zajęcie kanału przez CPU nadawcy (occupied). CPU odbiorcy może zasygnalizować bitem statusowym CHnF zwolnienie kanału transmisji zerując bit CHnC (free). Każda zmiana bitu statusowego generuje odpowiednie przerwanie. Pokazane to na rysunku 10. Proces wysyłania danych w trybie simplex pokazano na rysunku 11.
Najpierw jest odczytywany status kanału. Jeżeli kanał jest wolny, to dane są zapisywane do bufora kanału i status kanału jest zmieniany na zajęty. Jeżeli przy próbie przesłania danych status wskazuje na stan zajęty, to jest od maskowane przerwanie TX Free. Kiedy kanał się zwolni, to przychodzi przerwanie Tx Free. Przerwanie to zostaje zamaskowane i do bufora kanału można zapisać dane. Cała procedura nie blokuje procesora w przypadku zajętości kanału. Po jego zwolnieniu dane są przesyłane automatycznie.
Po zapisaniu danych do bufora kanału jest zgłaszane przerwanie RX Occupied w CPU pełniącym rolę odbiorcy danych. W procedurze przerwania jest odczytywany status kanału, określane który kanał jest zajęty i maskowane przerwanie dla zajętego kanału. Po tych czynnościach można odczytać bufor kanału wykrytego jako zajęty. Po odczytaniu ustawia się status kanału jako wolny i zezwala na przerwanie, aby przygotować moduł na odbiór kolejnej porcji danych. Na rysunku 13 pokazano cykl przesyłania wiadomości i odczytywania potwierdzenia w trybie half- duplex, gdy kanał jest wolny.
Sprzętowe semafory i moduł IPCC to dwa mechanizmy podobne do semaforów i kolejek w klasycznych systemach RTOS. Programiści układów wbudowanych embeded programujący pod kontrolą RTOS nie powinni mieć większych problemów z implementowaniem wymiany danych i ich synchronizacji pomiędzy zadaniami uruchamianymi na niezależnych CPU mikrokontrolerów STM32WB.
Interfejs radiowy
Rdzeń CPU2 ARM-Cortex M0+ jest połączony z modułem transceivera radiowego pracującego w paśmie 2,4 GHz. Oba te elementy umożliwiają budowę łącza radiowego Bluetooth Low Energy (BLE) v5.0, zgodnego z IEEE 802.15.4-2011. Protokół BLE ma budowę warstwową i składa się z warstwy fizycznej, warstwy łącza danych oraz warstwy HCI (Host Controller Interface). W warstwach wyższych jest umieszczony GATT (Generic Attribute Profile) i GAP (Generic Access Profile).
Bluetooth Low Energy (BLE) specification v5.0 wspiera:
- Użycie profili GAP: central, peripherial, observer lub broadcaster.
- ATT/GATT klient i serwer.
- SM autentykację i autoryzację.
- W warstwie link kodowanie AES-128.
Obsługa protokołu (stos BLE) jest umieszczona w pamięci Flash i uruchamiana na rdzeniu CPU2 (Cortex M0+). Umożliwia to stosowanie komercyjnego firmware, na przykład dostarczonego przez ST lub stosowanie własnych rozwiązań niestandardowych. Wsparcie standardu IEEE 802.15.4-2011 pozwala na implementowanie protokołów radiowych o mniejszej przepustowości danych, na przykład takich, jak ZigBee.
Umieszczony w strukturze mikrokontrolera moduł transceivera jest kompletnym torem radiowym. Jego schemat blokowy pokazano na rysunku 14. Układ nadajnika jest oparty o bezpośrednią modulację nośnej w kanale nadawczym TX. Układ odbiornika wykorzystuje przemianę częstotliwości z niską częstotliwością pośrednią IF. Dzięki wbudowanemu transformatorowi w.cz. antenę o impedancji ok 50 V można dołączyć bezpośrednio do wyprowadzenia RF1 mikrokontrolera (jednożyłowe połączenie SE). Naturalna charakterystyka pasmowa transformatora w pewnym stopniu filtruje szkodliwe częstotliwości harmoniczne i eliminuje zakłócenia zewnętrzne.
Moc wyjściowa TX jest regulowana przez programowe ustawianie napięcia wyjściowego stabilizatora LDO zasilającego nadajnik transceivera. Odbiornik może pracować w trybach programowanych charakteryzujących się dużą wydajnością lub ograniczonym poborem mocy. Wbudowana w odbiornik automatyczna regulacja wzmocnienia ARW obejmuje zarówno tor wzmocnienia wielkiej częstotliwości, jak też pośredniej częstotliwości. Źródłem przebiegu zegarowego taktującego moduł RF jest oscylator kwarcowy o częstotliwości 32 MHz z wbudowanymi kondensatorami o programowanej pojemności. Rezonator 32 MHz oraz nieskomplikowany, dodatkowy filtr w.cz są jedynymi elementami zewnętrznym potrzebnymi do pracy. Antena może być wykonana ma płytce drukowanej. Można również dołączyć przez złącze RF antenę zewnętrzną na pasmo 2,4 GHz. Układ antenowy powinien mieć na wejściu filtr pasmowy lub dolnoprzepustowy, ograniczający pasmo sygnału wejściowo/ wyjściowego oraz układ kompensacji niedopasowania impedancji. Przykładową implementację obwodu antenowego pokazano na rysunku 15.
Transmisja radiowa ma bardzo wiele zalet. Główną z nich jest mobilność, ale też w zastosowaniach przemysłowych może to być na przykład sposób na izolację różnicy potencjałów pomiędzy dwoma urządzeniami stosowanymi w elektroenergetyce. Łącza radiowe obniżają koszty związane z kanałem transmisji, bo nie są potrzebne fizyczne kanały przesyłania danych: skrętki, kable współosiowe, światłowody itp. Ale połączenie radiowe ma też wady: dane są podatne na przekłamania w wyniku zaburzeń elektromagnetycznych. Dlatego trzeba transmisję zabezpieczać sumami kontrolnymi, próbować odtwarzać zagubione dane na podstawie tych sum kontrolnych lub potwierdzać pakiety danych i ewentualnie je powtarzać. To jednak nie wszystko. We wrażliwych systemach transmisji danych lub sterowania trzeba stosować metody kryptograficzne, żeby nie było możliwe łatwe „podsłuchanie” przesyłanego strumienia danych i wykorzystania go w celach nieprzewidzianych przez producenta i użytkownika urządzeń. Każdy świadomy użytkownik radiowych sieci Wi-Fi wie, że trzeba skonfigurować swój router w taki sposób, aby używał protokołów bezpieczeństwa i certyfikacji WPA2.
Oprócz zabezpieczeń transmisji urządzenia zbudowane w oparciu o mikrokontrolery i pracujące w miejscach, do których jest nieograniczony dostęp powinny być zabezpieczone przez odczytem pamięci programu i przez możliwością debugowania kodu. Mając to na uwadze, w mikrokontrolerach STM32WB, a w szczególności w CPU2 pracującym z firmware odpowiadającym za transmisję danych, wprowadzono rozbudowany system zabezpieczeń obejmujący pamięć Flash, RAM, port debugowania JTAG/SW oraz bloki AES (Advanced Encryption Standard), PKA (Private Key Accelerator) i RNG (Random Number Generator).
Narzędzia
Dla tak rozbudowanego mikrokontrolera producent przygotował wsparcie w postaci modułów ewaluacyjnych i odpowiednich narzędzi programowych. Obecnie jest dostępny zestaw STM32WB Nucleo-68 pack, w skład którego wchodzą dwa moduły: USB dongle (rysunek 16) i Nucleo (rysunek 17). Dwa elementy zestawu pozwalają na zbudowanie toru radiowego i testowanie oprogramowania z wykorzystaniem specjalnie do tego celu przeznaczonego narzędzia STM32CubeMonitor-RF. Oprócz STM32CubeMonitor-RF można korzystać ze standardowego konfiguratora STM32CubeMX do tworzenia projektu i konfigurowania układów peryferyjnych. STM32CubeMX wspiera rodzinnę STM32WB od wersji V5.1. W chwili pisania tego artykułu wsparcie dla projektów mikrokontrolerów rodziny STM32WB było możliwe tylko z poziomu selektora modułu ewaluacyjnego (rysunek 19).
Konfigurowanie nietypowych modułów, czyli HSEM lub IPCC jest albo bardzo ubogie, albo nie ma go w ogóle. Moduł HSMEM można tylko włączyć/wyłączyć, a IPCC nie ma w ogóle na liście. Na rysunku 20 pokazano konfigurowanie elementu RF z menu Conectivity. Można go tylko aktywować, a w uwagach podano, ze jeżeli ktoś chce więcej, to może to zrobić samodzielnie. Mam nadzieję, że to z powodu bardzo świeżej wersji STM32CubeMX i w nowszych wersjach ta sytuacja ulegnie zmianie.
Do testowania i programowania toru radiowego jest przeznaczony specjalny program narzędziowy STM32Cube Monitor-RF. Monitor umożliwia testowanie torów radiowych mikrokontrolerów STM32 zgodnych z IEEE 802.15.4 i BLE. Program wykonuje weryfikację jakości toru RF, testy nadawania i odbioru danych oraz pomiary elementarnej stopy błędów transmisji. Wyniki są wyświetlane w formie graficznej na ekranie interfejsu użytkownika. Do testowania można wykorzystać połączenie radiowe wykonane z USB Dongle i modułu Nucleo Board STM32WB (rysunek 21). W czasie testowania STM32CubeMonitor- RF wysyła komendy ACI do modułu ST Nucelo 32WB lub USB Dongle. Komendy mogą też być wysyłane do urządzenia wykonanego przez użytkownika. Do połączenia modułu z komputerem jest wykorzystywany port UART lub połączenie USB używające VCP (Virtual Com Port). Obsługiwane są komendy z kategorii HCI, HAL, HCI test, GAP, GATT i L2CAP. Możliwe jest tworzenie skryptów z sekwencjami komend. Program jest rozbudowany i daje użytkownikowi szereg możliwości od wspomnianego już wysyłania komend ACI, poprzez testowanie łącza RF do pomiaru PER (Packet Error Rate).
Podsumowanie
Mikrokontrolery z rodziny STM32WB są komponentami, które znacznie ułatwiają tworzenie projektów wykorzystujących łącza radiowe. Zintegrowanie w jednej obudowie dwóch rdzeni i kompletnego modułu radiowego daje nie tylko szerokie możliwości elastycznego projektowania urządzeń wykorzystujących standaryzowane łącza Bluetooth 5 (BLE) lub Thread, ale też możliwość implementacji własnych protokołów. Wsparcie w postaci modułów zabezpieczających transmisję powoduje, że może ona być bezpiecznie stosowana w krytycznych aplikacjach. Podział na rdzeń wykorzystywany do obsługi transmisji oraz wydajny, uniwersalny, energooszczędny rdzeń z bogatym wyposażeniem w moduły peryferyjne daje możliwość łatwego projektowania zaawansowanych urządzeń. Nie bez znaczenia jest wsparcie producenta w postaci modułów ewaluacyjnych i programów narzędziowych, w tym również nieco niedomagającego STM32CubeMX (mam jednak nadzieję, że szybko to się zmieni) i bardzo przydatnego z punktu widzenia testowania łącza RF STM32CubeMonitor-RF.
Tomasz Jabłoński, EP
