[NOWY FRAMEWORK] Microchip Harmony dla PIC32, część 1

Strony: 1 2 3

Usługa timera systemowego może być skonfigurowana według potrzeb. Domyślnie jest to Timer2, ale można użyć na przykład Timer3. Używanie usługi systemowej jest podobne do używania drivera urządzenia. Różnica polega tylko na tym, że driver wymaga użycia polecenia „open” dla utworzenia unikalnego połączenia klient-driver. W przypadku usługi systemowej nie jest to konieczne, bo są one współdzielone przez wielu klientów w systemie.

Moduły MPLAB Harmony: drivery urządzeń, usługi systemowe oraz middleware (bez modułów PLIB) są wstanie aktywnym. Oznacza to, że kiedy aplikacja wywołuje funkcję interfejsu modułu, to moduł odpowiada natychmiast a potem kontynuuje swoją pracę żeby zakończyć operację. Większość modułów wystawia zgłoszenie i aplikacja (klient) wie kiedy operacja została zakończona.

Moduły są implementowane jako maszyna stanu (cooperative state machine). Użytkownik definiuje zestaw dopuszczalnych stanów i wykonuje inicjalizację maszyny stanów. Każdy z modułów ma swoją funkcję inicjalizacji i jedną z lub więcej funkcji wykonujących zadania (task functions). Funkcje inicjalizacji realizujące między innymi stan początkowy maszyny stanu powinny być wykonane tak szybko jak to tylko możliwe po zerowaniu mikrokontrolera. Moduły pod kontrolą warstwy aplikacji współpracują każdy z każdym przez wywoływanie funkcji interfejsu innych modułów. Po inicjalizacji w konfiguracji z poolingiem (bez RTOS) system przechodzi do nieskończonej pętli głównej, w której moduły są wywoływane cyklicznie i przez to utrzymywane przez system w stanie aktywnym do ewentualnego wykonania swojego zadania. Ta technika pozwala na prostą implementację wielozadaniowości.

Taka metoda nie jest uniwersalna i może się nie sprawdzić we wszystkich przypadkach. Dlatego w Harmony przewidziano inne konfiguracje. Jednak metoda maszyny stanów z poolingiem jest najprostsza do zrozumienia, łatwa w implementacji i debugowaniu. Ponadto pokazuje w najbardziej przystępny sposób jak moduły w MPLAB Harmony współdziałają ze sobą – rysunek 3.

Rys. 3. Współpraca modułów w MPLAB Harmony

Podstawowy model MPLAB Harmony, w którym moduły ze sobą kooperują ze sobą i są konfigurowalne zaspokaja potrzeby niemal każdego systemu wbudowanego. Na przykład, kiedy chcemy użyć wielu identycznych peryferii Harmony potrafi skonfigurować dynamiczną implementację drivera urządzenia. Wtedy wielu klientów może w tym samym czasie korzystać z układu peryferyjnego (przykład timera systemowego opisanego powyżej). Dynamiczny driver w sposób inteligentny zarządza wieloma próbami dostępu od wielu klientów do jednego zasobu – rysunek 4.

Rys. 4. Przykład implementacji dynamicznego drivera USART-a

Taki driver jest oczywiście rozbudowany programowo. Jeżeli nasza aplikacja nie przewiduje wykorzystania dynamicznego drivera, to można zastosować konfigurację statyczną zajmującą mniej pamięci procesora.

Są systemy, które wykorzystują middleware i muszą mieć „otwartych” kilka potencjalnie niezależnych aplikacji jednocześnie. W tym przypadku opisywana metoda poolingu używająca pętli głównej do sekwencyjnego wywoływania modułów może nie być wystraczająca. Tak się dobrze składa, że moduły Harmony mogą być uruchamiane bezpośrednio z procedurach obsługi przerwania ISR, lub przez wątki systemu RTOS. Użycie przerwań z odpowiednio zaprogramowanymi priorytetami eliminuje opóźnienie spowodowane oczekiwaniem na uruchomienie przez inny moduł. To opóźnienie może być spowodowane oczekiwaniem na dokończenie pollingu w pętli głównej maszyny stanów.

Gdy system jest na tyle skomplikowany, że trudno jest zapanować nad spełnieniem wykonania zadania przy użyciu maszyny stanu i systemu przerwań, to można zastosować system czasu rzeczywistego RTOS. Na szczęście wszystkie funkcje, które są wywoływane poprzez pooling mogą być równie łatwo wywoływane przez RTOS wykorzystując zbór funkcji OSAL (Operating System Abstraction Layer). OSAL umożliwia wywoływanie modułów przez różne systemy operacyjne RTOS, ale może tez być użyte samodzielnie (bez RTOS)

Rys. 5. Zastosowanie RTOS

MPLAB Harmony wspiera różne możliwości konfiguracji:

wybór mikrokontrolera,
wybór sposobu działania: pooling lub przerwania,
konfiguracja driverów urządzenia: statyczna lub dynamiczna,
konfiguracja driverów urządzenia: pojedynczy klient lub wielu klientów,
konfiguracja innych właściwości biblioteki.

Potrzebę wybierania środowiska do wykonania zadania (pooling, przerwania, RTOS) wyjaśniłem wcześniej. Moduły MPLAB Harmony zostały tak zaprojektowane, żeby możliwy był wybór różnych konfiguracji i by w ten sposób można było dostosować działanie do konkretnej aplikacji. Na przykład można skonfigurować rozmiar bufora danych dla modułów transmisyjnych, lub źródło sygnału zegarowego dla modułów czasowych (liczników). Zestaw konfiguracji jest wyczerpująco opisany w dokumentacji MPLAB Harmony. Dostępne jest też narzędzie konfiguracyjne znacznie upraszczające proces konfigurowania skomplikowanych projektów.

Struktura projektu MPLAB Harmony

MPLAB Harmony jest dystrybuowany w formie spakowanego pliku instalacyjnego. Po pobraniu ze strony www.microchip.com, rozpakowaniu i uruchomieniu wszystkie niezbędne pliki są umieszczane w katalogu o nazwie tożsamej z numerem wersji. W testowanym przypadku jest to wersja V.1.03.01, a katalog ma nazwę v1_03_01. Lokalizacja tego folderu jest istotna. Wszystkie projekty użytkownika powinny być umieszczone w katalogu v1_03_01 i podkatalogu \apps. Inna lokalizacja jest oczywiście możliwa, ale wymaga definiowania w projekcie ścieżek dostępu do plików źródłowych i nagłówkowych bibliotek Harmony. Jest to żmudne i raczej niepotrzebne zajęcie.

Projekt Harmony w MPLAB X IDE

Pełne wsparcie MPLAB Harmony rozpoczyna się od momentu generowania projektu dla środowiska projektowego MPLAB X IDE. Po wybraniu File->New Project i kategorii Microchip Embeded mamy możliwość wybrania projektu typu MPLAB Harmony Project. Kreator takiego projektu pozwala wybrać (rysunek 6):