W zakładce Pinout przypisuje się wyprowadzeniom mikrokontrolera funkcje alternatywne. Wyprowadzenie może być linią GPIO wejściową, lub wyjściową, może być wejściem analogowym, lub spełniać rolę wyprowadzenia sygnałów modułów peryferyjnych.

Rys. 4. Okno Pinout

Okno zakładki Pinout składa się z rozwijanej listy z nazwami modułów peryferyjnych i okna z narysowaną obudową mikrokontrolera z wyprowadzeniami – rysunek 4. Wyprowadzenia są zaznaczane kolorami:

• szarym, kiedy do wyprowadzenia nie jest przypisana żadna funkcja,
• zielonym, kiedy do wyprowadzenia jest przypisana i zdefiniowana funkcja (na przykład sygnał modułu I2C, lub GPIO),
• pomarańczowym, kiedy do modułu jest przypisana funkcja, ale nie jest aktywna,
• żółtym wyprowadzenia zasilania.

Najłatwiej konwencję kolorowania wyprowadzeń jest pokazać na przykładzie:

1. Klikamy na wyprowadzenie PC5 i wybieramy GPIO_Input. Ponieważ funkcja portów nie wymaga dodatkowej konfiguracji, to wyprowadzenie przebarwia się na zielono.
2. Jeżeli chcemy żeby wyprowadzenie PC5 było wejściem przetwornika ADC, to ponownie na nie klikamy i wybieramy ADC1_IN15. Wyprowadzenie przebarwia się na pomarańczowo.
3. Żeby wyprowadzenie zdefiniowane jako ADC1_IN15 przebarwiło się na zielono trzeba w oknie Configuration wybrać ADC1 i zaznaczyć IN15 – zostało to pokazane na rysunku 5.

Rys. 5. Konfigurowanie wyprowadzenia PC5 jako wejścia ADC1_IN15

W taki sam sposób są konfigurowane pozostałe wyprowadzenia używane w projekcie. Każdy układ peryferyjny prawidłowo przypisany do wyprowadzenia jest wyświetlany na zielono w oknie Configurations zakładki Pinout. Ma to też inne konsekwencje: prawidłowo przypisany do wyprowadzenia układ peryferyjny pojawi się w oknie Configuration, gdzie można go dokładnie skonfigurować. Definiowanie przypisania w oknie Pinout nie pozwala przypisać funkcji peryferii do już zajętego wyprowadzenia. W naszym przykładzie w konfiguracji przypisania przetwornika ADC1 są zaznaczone na czerwono wejścia IN0, IN4. IN5, IN6, IN7, IN10 i IN3. Na przykład wyprowadzenie PA4 jest już przypisane do I2S3_WS i nie może zostać przypisane do ADC1_IN4.

STM32CubeMX skutecznie zabezpiecza przed próbą przypisania do jednego wyprowadzenia funkcji więcej niż jednego modułu peryferyjnego.

Po przypisaniu do wyprowadzenia PC5 wejścia IN15 przetwornika ADC1 przechodzimy do zakładki Configuration, gdzie przetwornik zostanie skonfigurowany. Zakładka Configurations jest podzielona na dwa okna. W oknie Configurations wyświetlono wszystkie elementy, które mogą zostać skonfigurowane w projekcie. W naszym przypadku są to elementy Middleware FATFS i FreeRTOS, oraz układy peryferyjne możliwe do konfiguracji, w tym również nasz przetwornik ADC1. Drugie okno zawiera pola: Middlewares, Multimedia, Control, Analog, Connectivity i System.

W polu Analog jest wyświetlana ikona naszego przetwornika ADC1, a w polu System ikony: DMA, GPIO, NVIC i RCC. Żeby skonfigurować przetwornik trzeba kliknąć na ikonę ADC1 w polu Analog i pojawia się okno ADC1 Configuration – rysunek 6.

Rys. 6. Okno konfiguracji przetwornika ADC1

Okno konfiguracji ma cztery zakładki: Parameter Settings, NVIC Settings, DMA Settings i GPIO Settings.

W zakładce Parameter Settings ustawia się parametry pracy przetwornika, miedzy innymi tryb pracy, częstotliwość taktowania (preskaler PCLK2), rozdzielczość w bitach, umieszczenie danych w słowie (data alignment) itp.

W zakładce NVIC odblokowuje się przerwania od modułu ADC1, ADC2 i ADC3.

W zakładce DMA można zdefiniować kanał DMA do przesyłania danych z konwersji bezpośrednio do pamięci.

Ostatnia zakładka GPIO Settings jest przeznaczona do konfigurowania trybu pracy wyprowadzenia ADC1_IN15. Ponieważ w trakcie przypisywania wejście PC5 zostało skonfigurowane jako Analog Input, to w naszym przypadku nie potrzeba wykonywać tu żadnych zmian.

Można teraz zobaczyć jak STM32CubeMX poradzi sobie z wygenerowaniem plików źródłowych dla konfiguracji przetwornika. W pierwszym kroku trzeba określić sposób generowania plików źródłowych. Klikamy na Project-> Settings (Alt+P). Trzeba tu ustawić:

• nazwę projektu,
• ścieżkę dostępu do katalogu projektu,
• środowisko projektowe IDE.

STM32CubeMX może wygenerować kompletny projekt dla EWARM, uVision4 i uVision 5 (MDK-ARM), True STUDIO i SW4STM32. Ja wybrałem pakiet uVision4 firmy Keil (ARM).

W zakładce Code Generator okna Project Settings można zdecydować, czy generator kodu skopiuje wszystkie biblioteki warstwy HAL do projektu, czy tylko skopiuje tylko te biblioteki, które są potrzebne po wygenerowaniu kodu przez STM32CubeMX.

W przypadku projektów generowanych przez tego typu aplikacje zawsze jest problem co zrobić z kodem już napisanym przez użytkownika w momencie, kiedy decydujemy się zmienić konfigurację peryferii lub middleware przez STM32CubeMX. Najlepiej gdyby automatycznie nowo generowany kod nie niszczył kodu użytkownika, a robił tylko w plikach niezbędne zmiany konfiguracyjne. Dlatego w opcjach generowania kodu należy zaznaczyć Keep User Code when Re-generatting. Pewnym ograniczeniem tej funkcji jest to, że kod przeznaczony do zachowania musi znaleźć się pomiędzy komentarzami /* USER CODE BEGIN */ i /* USER CODE END */. Jeżeli nasze procedury łącznie z definicjami zmiennych zostaną umieszczone poza komentarzami, to przy kolejnym generowaniu projektu z konfiguracja zostaną usunięte. Trzeba o tym pamiętać, żeby sobie nie zniszczyć efektów swojej pracy.