Druga część artykułu jest dostępna w naszym serwisie.

Wprowadzenie na rynek przez firmę Microchip 32-bitowych mikrokontrolerów PIC32MX, a ostatnio PIC323MZ było impulsem do uporządkowania udostępnianego przez producenta bezpłatnego oprogramowania. Zdecydowano się zaprzestania rozwijania bibliotek w dotychczasowej formie (jak prezentowane przez nas MLA – Microchip Libraries for Applications), zamiast nich wprowadzono nowe rozwiązanie nazwane Harmony.

Po co ta zmiana? Załóżmy, że programista lub zespół programistów, projektują i wykonują oprogramowania na konkretny mikrokontroler. Projekt jest wykonany, przetestowany i wdrożony. Ale z powodu zmiany wymagań klienta, lub z powodu wymogów konkurencyjności rynku trzeba coś zmienić – na przykład zastosować nowszy, bardziej wydajny mikrokontroler lub – odwrotnie – w celu zmniejszenia kosztów zastosować prostszy i tańszy mikrokontroler. Jeżeli program był napisany w postaci warstw od warstwy obsługującej sprzęt do warstwy aplikacji, to może nie będzie trzeba pisać wszystkiego od nowa. W każdym razie zmiana mikrokontrolera będzie wymagała zmiany procedur odpowiedzialnych za obsługę sprzętu. Jest to bardzo pracochłonne i łatwo przy tym popełnić błędy. Harmony oprócz tego, że dostarcza bibliotek tak jak MLA, to te biblioteki są tak napisane, że łatwo jest je implementować po zmianie typu mikrokontrolera i ogólnie dużo łatwiej i szybciej jest modyfikować działanie całego projektu.

MPLAB Harmony – założenia ogólne

Pakiet MPLAB Harmony został prawie całkowicie napisany w języku C (ze wsparciem C++). Kluczowe elementy mają budowę modułową i są zorientowane obiektowo. Projekt może pracować w zależności od wymagań, wiedzy i doświadczenia programisty pod kontrolą systemu czasu rzeczywistego RTOS lub bez niego. Harmony zapewnia moduły programowe, które są łatwe w użyciu, w pełni konfigurowalne i współpracują ze sobą jak zapewnia producent w pełnej harmonii – stąd zapewne marketingowa nazwa MPALB Harmony.

Jednym z ważnych założeń jest łatwa przenośność oprogramowania. Harmony oferuje proste funkcje zapewniające z jednej strony obsługę układów peryferyjnych a z drugiej strony pewien stopień abstrakcji. Przy zmianie mikrokontrolera trzeba wymienić funkcje na te odpowiednie dla danego typu układu. Ta wymiana następuje w dużej części automatycznie i jest wykonywana przez MPLAB Harmony. Oczywiście nie zwalnia to całkowicie programisty od orientowania się w szczegółach sprzętowych mikrokontrolera. Trzeba znać jak są zbudowane układy peryferyjne i jak działa system przerwań. Harmony tylko znacznie ułatwia ich użycie.

Rys. 1. Schemat blokowy pakietu MPLAB Harmony

Jedną z głównych właściwości MPLAB Harmony jest stosowanie driverów urządzeń – device drivers. Sterowniki urządzeń, to funkcje realizujące warstwę interfejsu pomiędzy elementarnymi funkcjami dostępu do sprzętu (PLIB), a wyższymi warstwami projektu. Device driver jest odpowiedzialny za zarządzaniem dostępem do układów peryferyjnych, tak by żądania dostępu do nich z wyższych warstw nie kolidowały między sobą. Zapewnia to nie zakłóconą pracę urządzeń peryferyjnych.

Funkcje biblioteki peryferii Peripheral Library PLIB zapewniają dostęp do układów peryferyjnych konkretnego mikrokontrolera. PLIB umożliwiają ukrycie szczegółów rejestrów sterujących SFR i przez to ułatwiają funkcjom warstwy drivera urządzeń obsługę wielu różnych mikrokontrolerów. Funkcje warstwy aplikacji nie powinny bezpośrednio używać funkcji biblioteki peryferii, pomimo że zapewniają one pewien poziom abstrakcji. Jak już wspominałem w celu bezkolizyjnego zarządzania dostępem do peryferii PLIB są wywoływane przez procedury funkcji drivera urządzeń. Zapobiega to na przykład sprzecznym żądaniom dostępu od różnych modułów programu.

Kolejną właściwością MPLAB Harmony jest budowa modułowa. Pozwala to na dzielenie aplikacji na części – moduły i działanie według zasady „dziel i rządź”. Każdy z modułów zarządza własnym obszarem zasobów.  Interfejs każdej biblioteki zawiera spójny zestaw funkcji (bez zmiennych globalnych lub współdzielenia rejestrów). Jeżeli jeden moduł musi korzystać z zasobów innego modułu, to w tym wywołuje funkcję interfejsu. Takie podejście pomaga wyeliminować konflikty pomiędzy modułami i pozwala budować aplikacje na zasadzie klocków Lego.

Drivery urządzeń są przeznaczone do obsługi w miarę prostych układów peryferyjnych – na przykład timerów, UART, I2C, SPI, DAC. ADC itp. Bardziej skomplikowane peryferia na przykład USB, czy obsługa LAN z protokołem TCP/IP wymaga obsługi złożonych protokołów. Równie rozbudowane są procedury graficzne. Do obsługi tych skomplikowanych zadań przewidziano warstwę nazwaną middleware znajdująca się pomiędzy driverami urządzeń, a warstwą aplikacji użytkownika. MPALB Harmony oferuje obecnie w tej warstwie bezpłatnie stos obsługi USB, stos TCP/IP, oraz bibliotekę graficzną. W wersji płatnej mogą być dostępne inne biblioteki na przykład stos Bluetooth.

Uruchamianie skomplikowanych procesów w warstwie aplikacji i w warstwie middleware może spowodować kolizje dostępu do zasobów. Na przykład jeżeli nasz program korzysta ze stosu USB i jednocześnie z procedur graficznych, to będą one wykonywały sekwencyjnie swoje zadania. Te zadania mogą w pewnym momencie żądać na przykład jednoczesnego dostępu do systemowego licznika Timer2. Żeby temu zapobiec stosuje się usługę systemową SYS_TMR_Callback(); opartą o działanie licznika Timer2. Jej zadaniem jest zapobieganie kolizjom dostępu i jednocześnie zapewnienie dostępu do usługi czasowej każdemu z żądających procesów – rysunek 2. Każdy z procesów korzysta z odseparowanych żądań i dzięki temu nie przeszkadzają sobie nawzajem.

Rys. 2. Działanie usługi systemowej dostępu do czasu systemowego