Dieser Post wurde nach einem Fact-Check gegen die reale SWS EthSwt
überarbeitet (siehe Korrektur-Issue #145): Die SWS verwendet den Begriff
SMI tatsächlich selbst — nicht als Vendor-Jargon, sondern als Bezeichnung
für den Registerraum, den |
SMI vs. MDIO — dieselbe Elektrik, erweiterter Zugriff
Die Serial Management Interface (SMI) nutzt dieselbe elektrische Basis wie
das aus der EthTrcv-MDIO-Post
bekannte MDIO (IEEE 802.3 Clause 22/45). Der Unterschied liegt darin, worauf
zugegriffen wird: Bei einem einfachen EthTrcv-Setup adressiert MDIO reine
PHY-Register. Bei EthSwt erlaubt dieselbe elektrische Schnittstelle den
Zugriff auf switch-interne Transceiver-Register über einen erweiterten
Registerraum — dafür stellt die SWS mit EthSwt_ReadMmd/WriteMmd eine
eigene API bereit.
Die reale API
Std_ReturnType EthSwt_ReadMmd(
uint8 SwitchIdx,
uint8 SwitchPortIdx,
uint8 Mmd, // MDIO Manageable Device
uint16 RegIdx, // Index des Transceiver-Registers auf der SMI
uint16* RegValPtr
);
Std_ReturnType EthSwt_WriteMmd(
uint8 SwitchIdx,
uint8 SwitchPortIdx,
uint8 Mmd,
uint16 RegIdx,
uint16 RegVal
);Beide Funktionen sind laut SWS reentrant für unterschiedliche
|
Clause 45 — nativ oder emuliert
Der vielleicht wichtigste Satz der Spec zu diesen beiden Funktionen: "Reads/writes a transceiver register using Clause 45 access if supported by hardware, or implements a Clause 45 access using Clause 22 operations." Das heißt konkret:
Unterstützt der Switch-Chip Clause 45 (erweiterter Registerraum mit Device-Adresse + 16-Bit-Register-Index) nativ, nutzt der Treiber das direkt
Unterstützt die Hardware nur Clause 22 (klassische 5-Bit-Registeradresse), emuliert der Treiber den Clause-45-Zugriff intern über mehrere Clause-22-Operationen
Diese Emulation ist für den Aufrufer vollständig transparent — |
Konfigurierbarkeit
Wie die meisten optionalen EthSwt-APIs sind auch EthSwt_ReadMmd und
EthSwt_WriteMmd Pre-Compile-Time an-/abschaltbar — über
EthSwtReadMmdApi bzw. EthSwtWriteMmdApi. Wird die Funktion nicht
gebraucht (z. B. weil der Chip-Hersteller-Treiber Diagnoseregister über
einen anderen Weg bereitstellt), lässt sie sich aus dem generierten Code
entfernen.
SMI direkt im Diagnose-Code
Für Fälle, in denen kein AUTOSAR-API-Zugriff möglich ist (z. B. während
eines sehr frühen Bring-up, bevor EthSwt_Init überhaupt erfolgreich
durchgelaufen ist), bleibt der direkte SMI-Zugriff über einen externen
MDIO-Adapter oder ein Debug-Board eine gängige Praxis — inhaltlich
deckungsgleich mit dem, was der EthTrcv-MDIO-Post dieses Blogs für den
Transceiver-Fall beschreibt.
Fallstudie: VLAN-Tabelle stimmt nicht mit der Konfiguration überein
EthSwt_GetArlTablebzw. die entsprechende VLAN-Diagnose-API liefert unerwartete WerteDirekter Registerzugriff über
EthSwt_ReadMmdauf das herstellerspezifische VLAN-Tabellenregister, um den tatsächlichen Hardware-Zustand zu sehenAbgleich mit der erwarteten ARXML-Konfiguration (Teil 3 dieser Serie)
Bei Abweichung: prüfen, ob zwischenzeitlich ein
EthSwt_EnableVlan-Aufruf den Zustand zur Laufzeit verändert hat
Zusammenfassung
| Aspekt | Kernaussage |
|---|---|
SMI vs. MDIO | Gleiche Elektrik (Clause 22/45), aber erweiterter Registerraum für switch-interne Transceiver-Register |
API |
|
Clause 45 | Nativ genutzt, falls Hardware es unterstützt — sonst transparent über Clause-22-Operationen emuliert |
Reentrancy | Parallel für unterschiedliche Switches, seriell für denselben Switch |