Możliwości i ograniczenia

Część tego pliku, o nazwie konfigurowanie procesora Cortex-M3 i rdzenia peryferiów (Configuration of Cortex-Mx procesor and Core Peripherals) zawiera pierwszą wskazówkę o ograniczeniach możliwości CMSIS zapewnienia ujednoliconego projektowania interfejsu. Różnice między układami stają się obecnie oczywiste, wynikające z użycia różnych wersji rdzenia Cortex-M3: w układach STM32 jest używana wersja 1 (rev.1), podczas gdy NXP używa w produkowanych przez siebie mikrokontrolerach wersji 2 (rev.2), w której zawarta jest m.in. jednostka zabezpieczenia pamięci (MPU – Memory-Protection Unit). Inna różnica między tymi układami polega na tym, że do określenia wartości priorytetów przerwań w układach STM32 używane są 4 bity, a w mikrokontrolerach firmy NXP 5 bitów.
Dla wielu konstruktorów te różnice nie są istotne, gdyż w popularnych aplikacjach bez systemu operacyjnego zazwyczaj nie jest używany MPU i cztery poziomy priorytetu są na ogół wystarczające.

Ponadto, struktura CMSIS zapewnia jednolitość między różnymi układami na poziomie konfiguracji rdzenia (jednostki centralnej). Core_cm3.h jest plikiem nagłówkowym dla Core Peripheral Access Layer. Definiuje on wszystkie struktury i symbole dla rdzenia CMSIS, wraz z numerem jego wersji, rejestrami rdzeniowymi i polami bitowymi Cortex-M3 oraz mapowaniem bloków peryferyjnych.
Za pomocą pliku core_cm3.c przewidziano możliwość udostępniania rejestrów rdzeniowych i generowania instrukcji charakterystycznych dla Cortex-M3: są one osiągane w postaci stałych funkcji wbudowanych. Warte jest zaakcentowania, że CMSIS dostarcza programiście pełny zestaw funkcji interrupt-related w celu ustawienia zezwoleń i zakazu (enable/disable) oraz zarządzania priorytetami i flagami. Ten sam plik umożliwia sterowanie rdzeniem zegara systemowego SysTick oraz mechanizmem Instrumentation Trace Macrocell.
Zatem przygotowywanie programów z użyciem funkcji „rdzeniowych” jest ułatwione z powodu dużej liczby ujednoliceń dla wszystkich dostępnych na rynku mikrokontrolerów. W każdym razie CMSIS usiłuje zniwelować różnice między układami różnych producentów w odniesieniu do używania bloków peryferyjnych. W pliku device.h uwzględniono te różnice.

Są dwa możliwe podejścia przygotowania oprogramowania dla peryferii: poprzez bezpośredni dostęp do ich rejestrów lub przez użycie biblioteki sterowników bloków peryferyjnych dostarczanych przez producenta układu. W pierwszym przypadku programista może skorzystać z definicji peryferii dostępnych w pliku device.h, a w drugim może być zastosowany interfejs API (Application Programming Interface).
Biblioteki realizujące zadania dostępne w API zawierają makra, typy danych, typy struktur i funkcje, które wykorzystują w pełni możliwości bloków peryferyjnych. Powodują one także dostępność ich funkcjonalności bez żadnych wymagań dotyczących docelowych mikrokontrolerów oraz szczegółowej wiedzy na ich temat. Wraz z bibliotekami dołączony jest pełny zestaw przykładów.
W przypadku bibliotek oferowanych przez NXP i STMicroelectronics, standard CMSIS zapewnia zgodność i jednolitość metody dostępu do peryferii. To oznacza, że realizacja tych samych działań w odpowiadających sobie bloków peryferyjnych w układach STM i NXP jest podobna (patrz rys. 2). Jednak w wielu przypadkach różnice w implementacji występują, ponieważ bloki peryferyjne układów LPC17xx i STM32F10x, takie jak ADC, timery, a nawet GPIO różnią się znacznie.

Rys. 2. Porównanie implementacji bloków peryferyjnych w układach LPC17xx i STM32F10x

CMSIS i przenośność oprogramowania

CMSIS i bardzo użytecznym w przenoszeniu oprogramowania z jednego układu z rdzeniem ARM Cortex-Mx na inny, gdy w aplikacji są używane zasoby rdzenia. Zdefiniowane w CMSIS metody zarządzania przerwaniami i inicjalizacji systemu są bardzo pomocne.
Generalnie, reguły kodowania, zasady, konwencja i styl komentarzy doxygen zastosowany w CMSIS, pomagają programistom w przygotowaniu programów dla różnych układów. Jednakże standardowa technika zarządzania peryferiami, zdefiniowana w bibliotece ich sterowników, jest użyteczna tylko dla mniejszej liczby przypadków, w których ten sam rodzaj bloku peryferyjnego ma podobną funkcjonalność.
Obecnie dyskutuje się nad dodatkową warstwą CMSIS, to jest Middleware Layer. Przyjęte w niej nowe możliwości moją wprowadzić wyższy poziom abstrakcji sprzętu dla bloków komunikacji seryjnej (USART, SPI), prowadzący do nowego poziomu kompatybilności oprogramowania.
Należy także podkreślić, że w ogólnym przypadku, zarówno STMicroelectronics jak i NXP zapewniają doskonałe implementacje CMSIS. Dostarczone przykłady i pliki pomocy umożliwiają projektantom skrócenie czasu przygotowywania aplikacji
Jest nieuniknione, że odmienne realizacje bloków peryferyjnych pochodzących od różnych producentów wprowadzają ograniczenia w projektach sterowników do ich obsługi. Nie zmienia to faktu, że pierwszy krok w stronę znacznego ułatwienia przenośności oprogramowania został wykonany.
Jose Perez, FAE Future Electronics