Dieser Post wurde nach einem Fact-Check gegen die reale SWS EthSwt
überarbeitet (siehe Korrektur-Issue #145): SPI-Zugriff bei EthSwt ist kein
reiner Vendor-Mechanismus außerhalb von AUTOSAR, sondern durch eigene
ARXML-Container ( |
Wann SPI statt MII als Host-Interface?
Laut Kapitel 1 der SWS erfolgt der Zugriff für switch-spezifische
Konfiguration oder Funktionen über ein SPI- oder MII/MDIO-Interface
— vermittelt über den Eth-Treiber (MII/MDIO) oder direkt über den
Spi-Treiber (SPI). SPI kommt insbesondere dann zum Einsatz, wenn der Host
keinen eigenen dedizierten Ethernet-MAC-Port zum Switch hat oder wenn die
Konfiguration bereits vor dem Aufbau eines Ethernet-Links erfolgen muss.
Die reale ARXML-Konfiguration: EthSwtSpi / EthSwtSpiSequence
EthSwtConfig
└── EthSwtSpi (0..1 — nur vorhanden, wenn SPI genutzt wird)
└── EthSwtSpiSequence (1..* — eine oder mehrere SPI-Sequenzen)
├── EthSwtSpiAccessSynchronous (optional, boolean)
└── Referenz auf eine reale SpiSequence
des Spi-Treibers (SpiSequenceId, symbolischer Name)Die SWS ist hier ungewöhnlich explizit: Eine |
Ist am Switch-Chip gar kein SPI-Interface vorhanden, existiert schlicht
keine Instanz von EthSwtSpi in der Konfiguration — der Container ist
optional (0..1) genau aus diesem Grund.
Generische Register-APIs — MII und SPI hinter derselben Schnittstelle
Der entscheidende Punkt: EthSwt exponiert nach oben eine generische
API für Registerzugriffe, unabhängig davon, ob darunter MII oder SPI
liegt:
| API | Beschreibung laut SWS |
|---|---|
| "Generic API for reading the content of a switch register" — laut
|
| Das Gegenstück zum Schreiben; ebenfalls generisch über MII/SPI |
| Transceiver-Register "through the MII or SPI of the indexed switch port" — für Register, die einen bestimmten Port betreffen |
Für den Aufrufer eines dieser APIs ist es transparent, ob im
Hintergrund eine SPI-Transaktion über die konfigurierte
|
Synchron vs. asynchron
Der optionale Parameter EthSwtSpiAccessSynchronous steuert, ob der
SPI-Zugriff blockierend (synchron) oder nicht-blockierend erfolgt. Bei
zeitkritischen Zugriffen während der Initialisierung (siehe
EthSwt_BackgroundTask in Teil 2 dieser Serie) ist das eine relevante
Stellschraube, um die Register-Konfiguration nicht unnötig zu verzögern.
Typische Einsatzszenarien
Initial-Konfiguration beim Boot — bevor überhaupt ein Ethernet-Link zum Switch besteht
Statistik-Auslese ohne zusätzlichen Ethernet-Traffic — MIB-Zähler (Teil 4) über SPI abfragen, ohne den eigentlichen Datenpfad zu belasten
Diagnose bei defektem Ethernet-Link — wenn MII/MDIO aus irgendeinem Grund nicht verfügbar ist, bleibt SPI als unabhängiger Zugriffsweg
Fehlerbild: Registerzugriff schlägt fehl
Wie im Inbetriebnahme-Post dieser Serie beschrieben, führt ein
fehlschlagender Registerzugriff — egal ob über MII oder SPI — zum Extended
Production Error ETHSWT_E_ACCESS. Bei SPI-Setups lohnt es sich zusätzlich,
CPOL/CPHA-Einstellungen und das Timing der konfigurierten
EthSwtSpiSequence mit einem Logic-Analyzer zu prüfen.
Zusammenfassung
| Aspekt | Kernaussage |
|---|---|
ARXML-Container |
|
API-Abstraktion |
|
Synchronität | Über |
Fehlerfall |
|