Nowoczesne wydajne mikrokontrolery przeznaczone są głównie dla układów sterowania w urządzeniach wbudowanych (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 wykonywanie w zasadzie jednocześnie. Czas procesora dzieli się na wykonywanie poszczególnych wątków oraz na przełączanie i nadzór nad prawidłową ich pracą. 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 możliwe stało się umieszczenie w strukturze mikroprocesora więcej niż jednego rdzenia. Można wtedy tak podzielić zadania, że są rzeczywiście wykonywane jednocześnie przez poszczególne rdzenie. Wymaga to podobnego podejścia do programowania jak w przypadku RTOS: dzielenia wykonywania algorytmu na wątki, synchronizacji wymiany danych pomiędzy tymi watkami oraz dodatkowych mechanizmów fizycznej komunikacji pomiędzy rdzeniami. Takie rozwiązanie znane z „dużych” mikroprocesorów ostatnio zaczęło być implementowane także w mikrokontrolerach. Mogą to być dwie (lub więcej) równoprawne uniwersalne jednostki w jednej obudowie. Inne podejście zakłada, że jest jeden wydajny rdzeń uniwersalny i drugi rdzeń zoptymalizowany do wykonywania zadań specjalnych. Takie rozwiązanie zastosowała firma ST w swojej rodzinie 32-bitowych mikrokontrolerów opartych o rdzeń Cortex – STM32WB.

STM32WB to połączenie uniwersalnego wydajnego rdzenia ARM Cortex-M4 zoptymalizowanego dla małego zużycia energii, a także rdzenia ARM Cortex-M0+ oraz modułu transceivera radiowego pracującego w paśmie 2,4 GHz i zgodnego z normą IEEE 802.15.4. Jak się łatwo domyśleć, mikrokontrolery STM32WB są przeznaczone do stosowania w układach, w których istnieje potrzeba wykorzystania łącza radiowego ze szczególnym naciskiem na standard Bluetooth 5.0 (BLE). Jest też możliwa implementacja innych protokołów takich jak Open Thread, ZigBee i oczywiście własnych protokołów autorskich – rysunek 1.

Rysunek 1. Właściwości toru radiowego zintegrowanego z rdzeniem Cortex-M0+

Rysunek 2. Wyposażenie mikrokontrolera STM32WB

Na rysunku 2 pokazano zasoby i właściwości mikrokontrolerów STM32WB. Tak wyposażone jednostki moża wykorzystywać w wielu aplikacjach, w tym szczególnie w zastosowaniach Internetu Rzeczy (IoT). Na rysunku 3 pokazano przykładowe zastosowania proponowane przez producenta.

Rysunek 3. Przykłady zastosowania mikrokontrolerów STM32WB

Współdzielenie zasobów

Dwa rdzenie w jednej strukturze mają wspólną część fizycznych zasobów, które muszą dzielić między sobą. Rysunek 4 pokazuje jak to zrealizowano dla CPU1 (Cortex-M4) i CPU2 (Cortex-M0+). Widać tu wyraźnie, że nie są to dwie równorzędne jednostki. Wspólna domena zasobów obejmuje pamięć Flash, część pamięci SRAM (SRAM2), układy RVV, PWR i EXTI. Jeżeli chodzi o układy peryferyjne, to dzielone są IPCC, HSEM, AES2, PKA i RNG. Rdzeń główny CPU1 ma wyłączny dostęp do wszystkich standardowych układów peryferyjnych: DMA, liczników TIM, USART, I2C, USB oraz QUADSPI. Ponadto CPU1 ma swoją pamięć SRAM (SRAM1).

Rysunek 4. Podział zasobów mikrokontrolera pomiędzy rdzenie CPU1 i CPU2

Art Accelerator

Mikrokontroler oparty o dwa rdzenie oparte o różną architekturę (Cortex-M4 i Cortex-M0+) taktowane zegarami o różnej częstotliwości, musi mieć możliwość dostępu do swoich wspólnych zasobów niezależnie od prędkości z którą pracuje. Dlatego też w strukturę układu wbudowano specjalny moduł ART-Accelerator (Adaptive real-time memory accelerator) zapewniający prawidłowy czasowo dostęp do pamięci programu Flash przez oba rdzenie, a także układ arbitrażu rozstrzygający konflikty przy jednoczesnej próbie dostępu. Pokazano to na rysunku 5.

Rysunek 5. ART Accelerator

Podobnie jak w przypadku 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 zabezpieczenie przed konfliktami dostępu do współdzielonych zasobów. W klasycznych systemach RTOS do komunikacji pomiędzy uruchomionymi zadaniami służy kolejka (queue) oparta o bufor FIFO, natomiast do synchronizacji pomiędzy procesami i wykluczania niepożądanego dostępu do wspólnych zasobów wykorzystuje się semafory.

Moduł HSEM

W mikrokontrolerach 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 składa się z dwóch elementów: interfejsu AHB i układu zarządzania przerwaniami. Układ zarządzenia przerwaniami wydzielono dla każdej jednostki oddzielnie. Dedykowane przerwania mają swoje własne uprawnienia (blokowanie/odblokowanie), rejestr statusu i maskę. Dostępnych są 32 semafory ponumerowane od 0 do 31. Każdy z nich składa się z dwóch rejestrów:

• Write/Read register przeznaczony do zablokowania (lock) semafora w procedurze dwuetapowej i odczytywania statusu potwierdzenia,
• ReadLock register używany do blokowania semafora w procedurze jednoetapowej.

Rysunek 6. Moduł semaforów sprzętowych HSEM

Numer identyfikacyjny ID magistrali AHB identyfikuje procesor uzyskujący 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.

Dwuetapowa procedura blokady

W dwuetapowej procedurze zapisu blokady „wolny” semafor zostaje zablokowany przez zapisanie bitu LOCK rejestru Write/Read semafora. Identyfikator Core ID oraz Process ID użyte podczas zapisu, są przechowywane w semaforze. Proces musi sprawdzić czy semafor został zablokowany przez niego odczytując rejestr Write/Read. 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.

Rysunek 7. Dwuetapowe blokowanie semafora

Jednoetapowa procedura blokady

W procedurze jednoetapowej “wolny” semafor zostaje zablokowany po odczytaniu rejestru ReadLock. Kiedy wartość Core ID zawarta w rejestrze semafora jest równa Core ID CPU, który blokuje semafor, a 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, a Process ID nie jest równy 0x0000, to znaczy, że semafor został zablokowany przez inny proces.

Rysunek 8. Jednoetapowe blokowanie semafora

Semafor można odblokować przez wyzerowanie bitu LOCK z odpowiednim Core ID i Process ID (rysunek 8).

Procedury blokowania jedno i dwuetapowego można stosować jednocześnie, ale procedura dwuetapowa nie może używać ID procesu równego 0x0000.