W artykule przedstawiamy wyniki analizy wpływu zastosowania bibliotek CMSIS na przenośność oprogramowania miedzy dwoma mikrokontrolerami z rdzeniem ARM Cortex-M3: STM32F10x firmy STMicroelectronics oraz LPC17xx firmy NXP Semiconductors.

CMSIS (Cortex Microcontroller Software Interface Standard) to opracowany przez ARM, unormowany programowy interfejs dla programistów mikrokontrolerów Cortex-M, niezależny od ich producentów. Wykorzystanie bibliotek CMSIS tworzy środowisko projektowe niezależne od sprzętu (HAL – Hardware Abstractions Layer), co ułatwia przenoszenie programów pomiędzy mikrokontrolerami z rdzeniem Cortex-M pochodzącymi od różnych producentów.

Przenośność

Strategia ARM, polegająca na ułatwieniu przenoszenia oprogramowania pomiędzy mikrokontrolerami różnych producentów, opiera się na dwóch elementach: sprzęcie i oprogramowaniu. Od strony sprzętowej w architekturze Cortex-Mx zintegrowano więcej bloków zwiększających ich możliwości funkcjonalne niż w architekturze wcześniejszych rdzeni ARM7. Na przykład układy Cortex-Mx od różnych producentów mają nie tylko taką samą część procesorową (CPU), ale także taki sam wektorowy kontroler przerwań z zagnieżdżeniami (NVIC – Nested Vectored Interrupt Controller), taki sam rdzeń timera systemowego (SysTick) i taki sam moduł logiczny do wykrywania błędów w programie (debugowania).To gwarantuje, że każde oprogramowanie standardowe (firmware) będzie miało te same właściwości funkcjonalne po uruchomieniu na wszystkich mikrokontrolerach wyposażonych w rdzeń Cortex-Mx.
Na rys. 1 zaprezentowano podstawową architekturę środowiska programistycznego z CMSIS.

Rys. 1. Zastosowanie CMSIS w aplikacjach bez systemu operacyjnego

Chociaż funkcjonalność systemu musi być zawsze realizowana w kodzie programu, który jest wspólny dla mikrokontrolerów wszystkich producentów, to odwołanie do CMSIS jest wymagane. CMSIS został także pomyślany, aby umożliwić projektantowi łatwą migrację od jednego dostarczyciela narzędzi programowych do innego. Dlatego przy używaniu w aplikacji systemu operacyjnego czasu rzeczywistego (RTOS – Real-Time OS), dostęp do jednostki centralnej (CPU) umożliwia interfejs niezależny od typu mikrokontrolera, włączając w to kanał debugowania.

Rozpoczęcie pracy z CMSIS

Pliki zawierające CMSIS są udostępniane bezpłatnie przez producenta mikrokontrolerów. Są one zazwyczaj spakowane w jednym archiwum z producencką biblioteką obsługi peryferii. W artykule porównamy następujące pakiety plików:

• STM32F10x_StdPeriph_Lib/V3.2.0 oraz
• lpc17xx.cmsis.driver.library.zip/V1.3,

obydwa w wersji v1.3 CMSIS.
Rozpakowane na twardy dysk te dwa zestawy plików tworzą różne struktury katalogowe. Jednakże ich porównanie nie jest trudne, ponieważ pliki CMSIS są zgrupowane w folderze: \\core\cm3 Umieszczone w nim pozostałe podfoldery o nazwach NXP i STM, zawierają podobne do siebie biblioteki sterowników bloków peryferyjnych, szablony projektów, przykładowe projekty i pliki pomocy.
Większość projektantów rozpoczynając przygotowywanie nowego projektu programu korzysta albo z szablonu projektu, albo z przykładowych projektów. W tym celu ARM dostarcza szablony, które wspierają każdą typową konfigurację oprogramowania narzędziowego (toolchain), a każdy dostawca układów półprzewodnikowych dostosowuje je tak, aby zawierały wektory przerwań charakterystyczne dla programów obsługi wszystkich bloków (plik startup_device.s). W przypadku zbioru narzędzi firmy IAR jest on odpowiedzialny za:

• ustawienie wartości tablicy wektorów z wyjątkami i przerwaniami, do których odwołuje się procedura obsługi przerwań (ISR – Interrupt Sernice Routine),
• definiowanie podprogramu obsługi przerwania jako funkcji nie akceptowalnej dla fikcyjnego handlera (dummy handler),
• inicjalizację wskaźnika stosu,
• wywołanie funkcji SystemInit() i przejście do programu to_iar_program_start.

Typowo, w ostatniej funkcji, w zależności od potrzeb, zmienne są zerowane albo ustawiane na wartości z pamięci ROM, a funkcja Main() uruchamia aplikację.
We fragmencie funkcji SystemInit() zdefiniowanej w pliku system_device.c, jest inicjalizowany system oscylatora i jest uaktualniana zmienna SystemCoreClock.
Podsumowując, pliki startup_dev.s i system_device.c, dostarczane przez sprzedawcę, zawierają zdefiniowane pod użytkownika wektory przerwań i podprogramy ich obsługi, inicjalizację oscylatora z PLL oraz ustawianie częstotliwości sygnału zegarowego rdzenia.
Ponieważ ARM ma zestaw szablonów dla tych plików, to funkcjonalność obu plików i oprogramowania firmware jest prawie taka sama dla STM32F10x i dla LPC17xx. Jest tylko jedna niewielka różnica: w układach produkowanych przez NXP program SystemInit() inicjalizuje także akcelerator pamięci Flash (Flash Accelerator). Wynika to stąd, że moduł ten nie występuje w mikrokontrolerach STM32.
Innym ważnym plikiem, który programista aplikacji musi uwzględnić w kodzie źródłowym w języku C, jest plik device.h (lpc17xx.h albo stm32f10x.h). Pliki te są częścią mechanizmu Device Peripheral-Access Layer i są dostarczane przez dostawcę układu. Zawierają numery przerwań dla wszystkich wyjątków i przerwań oraz zapewniają zdefiniowanie struktur danych dla urządzeń peryferyjnych oraz mapowanie ich adresów.