STM32WB - mechanizmy współpracy rdzeni w mikrokontrolerze dual-core
| TechnikaSTM32WB to nowa w ofercie STMicroelectronics rodzina dwurdzeniowych mikrokontrolerów wyposażonych w rdzenie Cortex-M oraz zintegrowany tor radiowy pracujący w pasmie 2,4 GHz. W artykule przedstawiamy szczegóły współpracy rdzeni Cortex-M użytych w tych układach.
STM32WB to rodzina układów typu System-on-Chip, będących połączeniem rdzenia Cortex-M4 z rdzeniem ARM-Cortex-M0+ oraz modułu transceivera radiowego pracującego w paśmie 2,4 GHz, zgodnego ze standardem IEEE802.15.4. Schemat blokowy pokazano na rysunku 1.
Budowę tych układów zoptymalizowano pod kątem standardu Bluetooth 5.0 (BLE), możliwa jest także implementacja innych protokołów transmisji danych, jak Open Thread czy ZigBee (rys. 2).
Dwa rdzenie w jednej strukturze mają wspólną część zasobów fizycznych, którymi się muszą między sobą dzielić, a konstruktorzy STM32WB przyjęli założenie, że zastosowane CPU nie są jednostkami równorzędnymi. Wspólna domena zasobów obejmuje pamięć Flash, część pamięci SRAM, układy RVV, PWR i EXTI.
Układy peryferyjne, to współdzielone moduły 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, I²C, USB QUADSPI. Ponadto CPU1 ma przydzielony na wyłączność obszar pamięci SRAM.
W układy STM32WB wbudowano moduł ART-Accelerator (Adaptive real-time memory Accelerator), zapewniający prawidłowy czasowy dostęp do pamięci programu Flash obu rdzeniom oraz układ arbitrażu rozstrzygający konflikty przy jednoczesnej próbie dostępu (rys. 3).
Podobnie jak w przypadku systemów czasu rzeczywistego RTOS praca więcej niż jednego wątku na dwu lub więcej rdzeniach wymaga rozwiązania problemów synchronizacji przesyłania danych pomiędzy wątkami i zabezpieczenia przed konfliktami dostępu do współdzielonych zasobów. W klasycznych systemach RTOS do komunikacji pomiędzy uruchomionymi zadaniami jest przeznaczona kolejka (queue) oparta na buforze FIFO, a do synchronizacji pomiędzy procesami i wykluczania niepożądanego dostępu do wspólnych zasobów wykorzystuje się semafory.
Mikrokontrolery STM32WB wyposażono w sprzętowy moduł HSEM (rys. 4) 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 dwu elementów: interfejsu AHB i układu zarządzania przerwaniami.
Układ zarządzenia przerwaniami jest wydzielony dla każdej jednostki oddzielnie. Dedykowane przerwania mają swoje własne 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 dwu rejestrów:
- Write/Read - przeznaczony do zablokowania (lock) semafora w procedurze dwuetapowej i odczytywania statusu potwierdzenia,
- ReadLock - jest używany 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. Proces musi sprawdzić, czy semafor został zablokowany przez niego przez odczytanie rejestru Write/Read. Jeżeli odczytane zwrotnie Core ID i Process ID nie są takie same jak zapisane, to semafor został zablokowany przez inny proces. Jeżeli są takie same, to semafor został zablokowany przez nasz proces.
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 0×0000, to semafor zostanie zablokowany. W procedurze jednoetapowej nie stosuje się identyfikatora procesu. Jeżeli odczytany Core ID nie jest zgodny z ID CPU i Process ID nie jest równy 0×0000, to semafor został zablokowany przez inny proces.
Do wymiany danych pomiędzy rdzeniami jest przeznaczony kolejny moduł peryferyjny IPCC (Inter-Processor Communication Controller). Komunikacja może być jednokierunkowa simplex lub dwukierunkowa half duplex. W trybie simplex dedykowany 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 powiązane z generowaniem przerwań. IPCC nie ma swoich dedykowanych 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 (rys. 5). Kanałów przerwań może być maksymalnie sześć, 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 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 (rys. 6).
W trybie wysyłania danych simplex 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 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.
Podczas odbioru danych w trybie simplex, po zapisaniu danych do bufora kanału, jest zgłaszane przerwanie RX Occupied w CPU pełniącym funkcję odbiorcy danych. W procedurze przerwania jest odczytywany status kanału, określane jest, który kanał jest zajęty i maskowane jest 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 odmaskowuje przerwanie, żeby przygotować moduł na odbiór kolejnej porcji danych.
Na rysunku 7 pokazano cykl przesyłania wiadomości i odczytywania potwierdzenia w trybie half duplex w przypadku, kiedy 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 w 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.
Tomasz Jabłoński
