Rozdział 2. Architektura sprzętu
Rozdział 1. Założenia projektu | OpenDiag - STM32 CAN Tool | Rozdział 3. Architektura oprogramowania
Rozdział 2. Architektura sprzętu
2.1 Cel
Urządzenie OpenDiag jest interfejsem pomiędzy komputerem PC a magistralami CAN pojazdu.
Jego zadaniem jest:
- komunikacja z komputerem przez USB,
- komunikacja z magistralami CAN pojazdu,
- konwersja protokołów diagnostycznych,
- zapewnienie izolacji warstw sprzętowej i programowej.
2.2 Schemat blokowy
Proponuję przyjąć taki schemat jako bazę całego projektu:
. +----------------------+
| Komputer |
| Linux / Windows |
+----------+-----------+
|
USB 2.0 (CDC)
|
+----------------+---------------+
| STM32 MCU |
| |
| USB Device |
| CLI / Parser / ELM / STN |
| |
| CAN1 CAN2 CAN3 |
+---+----------+-----------+-----+
| | |
+-----+---+ +-----+--+ +----+----+
| SN65... | | SN65... | | SN65... |
+-----+---+ +-----+---+ +-----+---+
| | |
HS-CAN MS-CAN I-CAN
2.3 Jednostka centralna
Pierwszą platformą będzie:
STM32F767ZI (Nucleo-144)
Powody:
- łatwe debugowanie,
- ST-Link,
- Virtual COM,
- USB Device,
- trzy kontrolery CAN,
- bardzo wygodne prototypowanie.
Docelowo kod ma być przenoszalny na:
- STM32H723
- STM32H562
bez zmian logiki aplikacji.
2.4 Interfejs USB
Urządzenie posiada dwa niezależne kanały komunikacyjne. Kanał 1 ST-Link Virtual COM.
Przeznaczenie:
- logi,
- debug,
- diagnostyka firmware.
Nigdy nie będzie używany przez FORScan.
Kanał 2
USB Device.
Na początku:
USB CDC.
Docelowo możliwe:
- CDC
- WinUSB/Vendor
- DFU
2.5 Interfejs CAN
Projekt zakłada obsługę trzech niezależnych magistral.
| Kanał | Przeznaczenie |
|---|---|
| CAN1 | HS-CAN |
| CAN2 | MS-CAN |
| CAN3 | I-CAN / przyszłość |
Każdy kanał posiada:
- osobny kontroler CAN,
- osobny transceiver,
- niezależną konfigurację.
Nie stosujemy przełączników HS/MS.
2.6 Transceivery
Pierwsza wersja wykorzystuje:
SN65HVD230
Powody:
- 3,3 V
- zgodność ze STM32
- łatwa dostępność
- niski koszt
Każdy kontroler CAN posiada własny transceiver.
2.7 Złącze OBD-II
| Pierwsza wersja projektu wykorzystuje: | Pin | Funkcja |
|---|---|---|
| 4 | GND | |
| 5 | Signal GND | |
| 6 | HS-CAN H | |
| 14 | HS-CAN L | |
| 3 | MS-CAN H | |
| 11 | MS-CAN L | |
| 1 | I-CAN H (jeśli występuje) | |
| 8 | I-CAN L (jeśli występuje) | |
| 16 | +12V |
Projekt powinien umożliwiać łatwą zmianę mapowania dla innych producentów pojazdów.
2.8 Zasilanie
Źródła zasilania:
- USB (podczas programowania i testów)
- OBD-II (+12 V z pojazdu)
Na etapie prototypu (Nucleo) zasilanie z OBD nie jest wymagane, ale w projekcie docelowym przewidujemy:
- zabezpieczenie przed odwrotną polaryzacją,
- bezpiecznik,
- filtr przeciwzakłóceniowy,
- przetwornicę 12 V → 5 V → 3,3 V.
2.9 Sygnalizacja
Minimalny zestaw:
- LED Power
- LED USB
- LED CAN1
- LED CAN2
- LED CAN3
- LED Error
Na Nucleo wykorzystamy tylko dostępne diody, a pełna sygnalizacja pojawi się na własnej płytce.
2.10 Rozszerzenia sprzętowe
Nie są wymagane w pierwszej wersji, ale architektura ma przewidywać możliwość dodania:
- gniazda microSD,
- Ethernet,
- Bluetooth,
- Wi-Fi,
- izolacji galwanicznej CAN,
- zewnętrznego zasilania.
Jedna propozycja do dyskusji
Tutaj chciałbym zaproponować jedną zmianę względem typowych interfejsów ELM327. Lepiej zdefiniować je jako:
- Port CAN A
- Port CAN B
- Port CAN C
A dopiero w konfiguracji przypisać:
CAN A → HS-CAN
CAN B → MS-CAN
CAN C → I-CAN
Dlaczego? Bo wtedy ten sam sprzęt bez zmian będzie można wykorzystać z Oplem, grupą VAG, PSA czy innymi pojazdami, gdzie przypisanie magistral do złącza OBD wygląda inaczej. Firmware pozostanie uniwersalny, a mapowanie stanie się elementem konfiguracji, a nie projektu. To moim zdaniem lepiej wpisuje się w założenie z Rozdziału 1, że budujemy uniwersalny interfejs diagnostyczny, a nie urządzenie wyłącznie do jednego modelu samochodu.