Teil 1 dieser Serie hat den Zustandsautomaten und die Architektur von EthSwt geklärt. Dieser Teil zeigt die konkrete API — und räumt dabei mit einer verbreiteten Vereinfachung auf: EthSwt_Init initialisiert nicht synchron die komplette Switch-Hardware. Laut SWS (Kapitel 8.3.1) kann das zu lange dauern, um es aus EcuM oder BswM heraus aufzurufen — die eigentliche Hardware-Konfiguration übernimmt ein separater Background-Task.

Init-Sequenz im Detail

EthSwt_Init(CfgPtr)
   │
   ├─ Speichert Zeiger auf Konfigurationsstruktur
   ├─ Zustand: ETHSWT_STATE_UNINIT → ETHSWT_STATE_INIT
   ├─ Alle EthSwtPorts → ETH_MODE_DOWN
   └─ Nicht konfigurierte Hardware-Ports werden abgeschaltet
       (und bleiben es für die gesamte Laufzeit)

   ... wiederholte Aufrufe ...

EthSwt_BackgroundTask()            ◄── "so oft wie möglich" aufrufen,
   │                                    wenn keine andere Task läuft
   ├─ Übernimmt Port- und Switch-Initialisierung,
   │  falls EthSwt_Init dafür zu lange bräuchte
   ├─ Prüft Registerzugriff (sonst: ETHSWT_E_ACCESS)
   ├─ Aktiviert ggf. konfiguriertes Port-Mirroring
   │  (SWS_EthSwt_00421/00422)
   └─ Zustand: ETHSWT_STATE_INIT → ETHSWT_STATE_PORTINIT_COMPLETED

   ... danach, nach EthSwtLowPowerModeSupport ...

   ├─ TRUE  → Switch bleibt zunächst im Low-Power-/Inaktiv-Zustand
   └─ FALSE → Switch geht direkt in einen aktiven Zustand

EthSwt_SetSwitchPortMode(SwitchIdx, PortIdx, ETH_MODE_ACTIVE)
   │                                   ◄── pro Port explizit aufrufen
   ├─ Falls EthSwtPort einen EthTrcv referenziert:
   │  zusätzlicher Aufruf von EthTrcv_SetTransceiverMode
   │  (über die EthIf-API-Abstraktion)
   └─ Zustand: ETHSWT_STATE_PORTINIT_COMPLETED → ETHSWT_STATE_ACTIVE

Die im ursprünglichen Planungs-Issue angenommene einfache Reihenfolge “EthSwt_Init` → Eth_Init → EthIf_Init” greift zu kurz. Die reale SWS modelliert `EthSwt_Init als reine Zustands- und Zeigerinitialisierung, die zeitkritische Hardware-Konfiguration läuft asynchron über EthSwt_BackgroundTask — analog zu EthSwt_MainFunction, die laut SWS "asynchronous behavior of API calls" unterstützt und direkt vom BSW-Scheduler aufgerufen wird.

Wichtigste APIs im Überblick

APIZweck

EthSwt_Init(CfgPtr)

Zustands- und Zeigerinitialisierung; setzt alle Ports auf ETH_MODE_DOWN

EthSwt_BackgroundTask()

Übernimmt ggf. die eigentliche Switch-/Port-Hardware-Initialisierung

EthSwt_SetSwitchPortMode(SwitchIdx, PortIdx, PortMode)

Port auf ETH_MODE_DOWN / ETH_MODE_ACTIVE / ETH_MODE_ACTIVE_WITH_WAKEUP_REQUEST schalten

EthSwt_GetSwitchPortMode(SwitchIdx, PortIdx, SwitchModePtr)

Aktuellen Port-Modus auslesen

EthSwt_GetLinkState(SwitchIdx, PortIdx, LinkStatePtr)

Link-Status eines Ports abfragen

EthSwt_GetPortMacAddr(SwitchIdx, PortIdx, MacAddrPtr)

MAC-Adresse eines Ports lesen

EthSwt_MainFunction()

Wird vom BSW-Scheduler zyklisch aufgerufen, unterstützt asynchrones API-Verhalten (z. B. verzögerte EthIf_SwitchPortModeIndication)

Port-Modi im Detail

EthSwt_SetSwitchPortMode erwartet einen von drei Eth_ModeType-Werten:

ModusBedeutung

ETH_MODE_DOWN

Port deaktivieren — laut Spec möglichst direkt zur Reduktion des Energieverbrauchs

ETH_MODE_ACTIVE

Port aktivieren

ETH_MODE_ACTIVE_WITH_WAKEUP_REQUEST

Port aktivieren und einen WakeUp im Netzwerk auslösen — laut SWS z. B. relevant für zu OPEN Alliance TC10 kompatible Hardware

Referenziert ein EthSwtPort einen EthTrcv (also einen echten PHY-Chip am Port), ruft EthSwt_SetSwitchPortMode intern zusätzlich EthTrcv_SetTransceiverMode über die EthIf-Abstraktion auf — die beiden Treiber laufen hier bewusst synchronisiert. Bei einem MAC-only-Port ohne EthTrcv-Referenz entfällt dieser zweite Aufruf.

Link-Status: mit und ohne EthTrcv

EthSwt_GetLinkState verhält sich unterschiedlich, je nachdem, ob der Port einen EthTrcv referenziert:

  • Mit EthTrcv-Referenz — der Link-Status kommt von EthTrcv_GetLinkState (über EthIf), genau wie bei einem einfachen Transceiver-Setup

  • Ohne EthTrcv-Referenz (z. B. interner Port zu einem eingebetteten PHY, den der Switch-Chip selbst verwaltet) — der Status kommt vom MAC-Interface des Ports; kann die Hardware das nicht liefern, wird er aus dem aktuellen Port-Modus abgeleitet: ETH_MODE_ACTIVE → Link aktiv, ETH_MODE_DOWN → Link down

Stimmen Port-Modus und PHY-Modus nicht überein, meldet EthSwt_GetSwitchPortMode den Extended-Production-Error ETHSWT_E_SYNCPORT2PHY und liefert E_NOT_OK zurück — ein nützliches Signal beim Debuggen, wenn Switch und Transceiver aus unterschiedlichen Gründen unterschiedliche Zustände melden.

Fehlerbehandlung & Determinismus

Alle in diesem Post genannten APIs prüfen laut SWS zunächst den Registerzugriff auf die Switch-Hardware; schlägt er fehl, wird der Extended-Production-Error ETHSWT_E_ACCESS gesetzt und E_NOT_OK zurückgegeben. Außerdem gilt für jede API: Wird sie im Zustand ETHSWT_STATE_UNINIT oder ETHSWT_STATE_INIT aufgerufen (also bevor die Port-Initialisierung abgeschlossen ist), liefert sie ebenfalls E_NOT_OK.

Praktische Konsequenz: Wer EthSwt_GetLinkState direkt nach EthSwt_Init aufruft, ohne vorher den Background-Task laufen zu lassen, bekommt zuverlässig E_NOT_OK — nicht weil etwas kaputt ist, sondern weil der Zustandsautomat noch gar nicht bei PORTINIT_COMPLETED angekommen ist.

Minimalbeispiel: Init-Aufrufsequenz für einen 4-Port-Switch

EthSwt_Init(&EthSwtConfig_0);
// ... Background-Task-Zyklen laufen lassen, bis PORTINIT_COMPLETED ...
EthSwt_BackgroundTask();   // ggf. mehrfach, je nach Scheduling

for (portIdx = 0; portIdx < 4; portIdx++) {
    EthSwt_SetSwitchPortMode(0, portIdx, ETH_MODE_ACTIVE);
}

// Zyklischer Betrieb:
EthSwt_MainFunction();     // regelmäßig vom BSW-Scheduler

Serie

TeilThemaStatus

1

Grundlagen, SWS & Architektur

fertig

2

API & Initialisierung

dieser Post

3

ARXML-Konfiguration

folgt

4

VLAN-Management, Mirroring & Diagnose

folgt

Weiter in der EthSwt-Serie: EthSwt Teil 3 — ARXML-Konfiguration in der Praxis