Rozdział 4. Konfiguracja STM32

Rozdział 3. Architektura oprogramowania | OpenDiag - STM32 CAN Tool | Rozdział 5. Interfejsy

Tak. I tutaj chciałbym oddzielić konfigurację STM32 od konfiguracji projektu. Rozdział 4 dotyczy wyłącznie tego, co ustawiamy w CubeMX/CubeIDE, żeby uzyskać bazę sprzętową dla dalszego rozwoju.

Rozdział 4. Konfiguracja STM32

4.1 Cel

Przygotowanie podstawowej konfiguracji mikrokontrolera STM32F767ZI, zapewniającej obsługę:

  • debugowania,
  • komunikacji USB,
  • komunikacji CAN,
  • sygnalizacji LED,
  • przyszłej rozbudowy projektu.

Po zakończeniu tego etapu firmware ma jedynie uruchomić wszystkie peryferia — bez implementacji ELM327, FORScan czy OBD-II.

4.2 Platforma

Płytka:

STM32 Nucleo-144 F767ZI

IDE:

STM32CubeIDE

Generator:

STM32CubeMX

4.3 Zegar systemowy

Na początek:

  • źródło: HSE z ST-Link (MCO)
  • SYSCLK: 216 MHz (domyślna konfiguracja CubeMX dla F767)

Na tym etapie nie optymalizujemy taktowania.

4.4 Debug

Interfejs:

SWD

Opcje:

  • Serial Wire Debug

Interfejs ST-Link pozostaje aktywny przez cały projekt.

4.5 UART (ST-Link Virtual COM)

Wykorzystujemy UART podłączony do ST-Link.

Przeznaczenie:

  • logi
  • debug
  • diagnostyka

Nie będzie używany przez FORScan.

Przykładowe parametry:

  • 115200 b/s
  • 8N1
  • bez kontroli przepływu

4.6 USB Device

Typ:

USB Device FS

Klasa:

CDC

Przeznaczenie:

  • komunikacja z FORScan
  • terminal
  • przyszła komunikacja z własną aplikacją

Na tym etapie używamy wyłącznie CDC.

4.7 CAN

Aktywujemy wszystkie trzy kontrolery CAN.

CAN1

Status:

Enabled

Tryb:

Normal

CAN2

Status:

Enabled

Tryb:

Normal

CAN3

Status:

Enabled

Tryb:

Disabled w firmware (na razie)

Pozostaje skonfigurowany sprzętowo, aby łatwo go włączyć w przyszłości.

4.8 GPIO

Konfigurujemy:

  • LED USER
  • ewentualne LED diagnostyczne
  • linie CAN
  • USB

Pozostałe piny pozostają w stanie domyślnym.

4.9 NVIC

Aktywujemy przerwania:

  • USB
  • CAN RX
  • CAN TX
  • UART

Priorytety pozostawiamy domyślne.

Na razie bez optymalizacji.

4.10 DMA

Na pierwszym etapie:

Nie używamy DMA.

Powód:

  • prostsze debugowanie,
  • mniejsza liczba zmiennych podczas uruchamiania projektu.

  • DMA będzie można dodać później dla USB lub UART, jeśli okaże się potrzebne.

4.11 Middleware

Na pierwszym etapie:

USB Device (CDC)

Nie włączamy:

  • FreeRTOS
  • FATFS
  • LwIP

4.12 Struktura projektu CubeMX

Pozostawiamy standardowy układ:

Core/
Drivers/
USB_DEVICE/
Middlewares/

Nasze moduły dodamy później we własnych katalogach, bez modyfikowania kodu generowanego przez CubeMX.

4.13 Kod generowany przez CubeMX

Przyjmujemy zasadę:

Kod wygenerowany przez CubeMX jest traktowany jako kod zewnętrzny.

Oznacza to:

nie modyfikujemy plików HAL, nie zmieniamy plików USB Middleware, własny kod dodajemy wyłącznie w sekcjach USER CODE BEGIN/END lub w osobnych modułach.

4.14 Wynik rozdziału

Po wykonaniu tej konfiguracji projekt powinien:

  • uruchamiać STM32,
  • działać pod debuggerem,
  • udostępniać Virtual COM przez ST-Link,
  • udostępniać USB CDC,
  • inicjalizować trzy kontrolery CAN,
  • być gotowy do rozpoczęcia implementacji.

Chciałbym jednak zaproponować jedną zmianę

Nie konfigurowałbym od razu wszystkich trzech kontrolerów CAN w pierwszym projekcie CubeMX.

Moja propozycja:

  • CAN1 – włączony (będzie używany jako pierwszy),
  • CAN2 – włączony (żeby od razu przygotować obsługę HS/MS),
  • CAN3 – pozostawiony wyłączony.

Dlaczego?

  • konfiguracja jest prostsza,
  • mniej przerwań do analizy,
  • łatwiejsze debugowanie,
  • projekt szybciej osiągnie pierwszy działający etap.

CAN3 dodamy w momencie, gdy faktycznie będziemy analizować piny 1/8 w S-Maxie. Architektura z Rozdziału 3 już teraz przewiduje trzeci kanał, więc jego późniejsze dołączenie nie będzie wymagało zmian w strukturze projektu. Moim zdaniem to zmniejszy złożoność startu, nie ograniczając przyszłych możliwości.