Ethernet Driver (Eth)

La fonction Eth_Init sert à initialiser le pilote Ethernet [SWS_Eth_00027]. Elle est déclarée via le fichier d'en-tête Eth.h, possède l'ID de service 0x01 et ne comporte aucune valeur de retour (void) [SWS_Eth_00027]. Elle attend comme paramètre d'entrée CfgPtr, qui pointe vers une structure de configuration spécifique à l'implémentation de type Eth_ConfigType [SWS_Eth_00027]. L'appel s'effectue de façon synchrone et est défini comme non réentrant (Non Reentrant) [SWS_Eth_00027].

Dans le déroulement des opérations, Eth_Init constitue la condition préalable fondamentale pour le travail avec le module. Toutes les autres fonctions nécessitent obligatoirement une initialisation préalable du contrôleur par Eth_Init [SWS_Eth_00070], [SWS_Eth_00167], [SWS_Eth_00185]. Cette dépendance est obligatoirement prescrite pour divers services de contrôleur du pilote [SWS_Eth_00189], [SWS_Eth_00194], [SWS_Eth_00199], [SWS_Eth_00232].

Pour le cas d'un accès non initialisé, un traitement d'erreur ciblé est prévu : lorsque la détection des erreurs de développement (Development Error Detection, DET) est activée, les fonctions du pilote vérifient si le service Eth_Init a été préalablement appelé de manière appropriée [SWS_Eth_00066]. Si ce contrôle échoue, elles déclenchent l'erreur de développement ETH_E_UNINIT [SWS_Eth_00164], [SWS_Eth_00182], [SWS_Eth_00187], [SWS_Eth_00196]. Si la DET est en revanche désactivée, les fonctions concernées refusent l'exécution et signalent l'état non autorisé en renvoyant le statut E_NOT_OK [SWS_Eth_00228], [SWS_Eth_00235], [SWS_Eth_00248], [SWS_Eth_00252].

La fonction Eth_SetControllerMode sert à activer (ETH_MODE_ACTIVE) ou désactiver (ETH_MODE_DOWN) le contrôleur Ethernet adressé via le paramètre CtrlIdx [SWS_Eth_00041]. Dans AUTOSAR Classic R20-11, ce service est classé comme obsolète (obsolete) [SWS_Eth_00041].

L'exécution du service est asynchrone et non réentrante (Non Reentrant) [SWS_Eth_00041]. Comme valeur de retour, la fonction fournit E_OK en cas d'initiation réussie ou E_NOT_OK si le mode de fonctionnement n'a pas pu être changé [SWS_Eth_00041]. Interprétation : l'appel étant spécifié comme asynchrone, mais aucun callback n'étant défini dans la charge utile, la prise en compte effective de l'état devrait s'achever au plus près du matériel en arrière-plan du pilote après le retour de la fonction. Question Q-d7ec04578e921eb9 (ouverte)

Si le contrôleur ou sa communication d'émission et de réception est désactivé via Eth_SetControllerMode, des nettoyages obligatoires des tampons s'appliquent :

• L'ensemble des tampons d'émission verrouillés (locked transmit buffers) doivent être libérés [SWS_Eth_00137] [SWS_Eth_00280].
• Tous les tampons d'émission en attente (pending transmit buffers) doivent également être libérés [SWS_Eth_00138] [SWS_Eth_00281].

En raison de la propriété Non Reentrant, la fonction ne doit pas être exécutée de manière concurrente pour la même instance de contrôleur ou d'autres instances [SWS_Eth_00041]. Aucun message d'erreur DET ou DEM spécifique n'est indiqué ; les états d'erreur sont communiqués à l'appelant via la valeur de retour E_NOT_OK [SWS_Eth_00041].

La fonction Eth_SetControllerMode (Service-ID 0x03, mise à disposition via Eth.h) sert à activer et désactiver la communication de réception et d'émission (Rx/Tx) d'un contrôleur Ethernet spécifique [SWS_Eth_91009].

Utilisation et conditions d'appel

L'exécution de la fonction est asynchrone et spécifiée comme non réentrante (Non Reentrant) [SWS_Eth_91009]. Lors de l'appel, deux paramètres sont transmis :

• CtrlIdx : index du contrôleur concerné dans le contexte du pilote Ethernet [SWS_Eth_91009].
• CtrlMode : mode cible pour le contrôleur, soit ETH_MODE_ACTIVE pour l'activation de la communication Rx/Tx, soit ETH_MODE_DOWN pour sa désactivation [SWS_Eth_91009].

Comme valeur de retour, la fonction fournit l'état Std_ReturnType : E_OK signale une exécution réussie, tandis que E_NOT_OK indique que le mode du contrôleur n'a pas pu être changé [SWS_Eth_91009].

Interaction et gestion des tampons

Si la communication Rx/Tx du contrôleur indexé est désactivée via Eth_SetControllerMode (mode ETH_MODE_DOWN), des actions de nettoyage doivent impérativement être effectuées pour les tampons d'émission :

• Tous les tampons d'émission verrouillés (locked transmit buffers) doivent être libérés [SWS_Eth_00280].
• Tous les tampons d'émission en attente (pending transmit buffers) doivent également être libérés [SWS_Eth_00281].

Les dispositions actuelles relatives à la libération des tampons verrouillés et en attente ainsi que la définition de fonction elle-même possèdent l'état « draft » [SWS_Eth_91009], [SWS_Eth_00280], [SWS_Eth_00281]. Elles remplacent les exigences historiquement antérieures [SWS_Eth_00137] et [SWS_Eth_00138], qui sont classées comme obsolètes.

L'interface synchrone Eth_UpdatePhysAddrFilter est mise à disposition via le fichier d'en-tête Eth.h et possède l'ID de service 0x12 [SWS_Eth_00152]. La fonction sert à ajouter une adresse physique au filtre d'un contrôleur Ethernet indexé ou à la supprimer de celui-ci [SWS_Eth_00152].

Les paramètres de la fonction comprennent trois valeurs d'entrée [SWS_Eth_00152] :

• CtrlIdx : définit l'index du contrôleur Ethernet concerné au sein du contexte du pilote [SWS_Eth_00152].
• PhysAddrPtr : pointeur vers la zone mémoire contenant l'adresse physique de destination (adresse MAC) dans l'ordre des octets du réseau ; il s'agit de l'adresse de destination multicast du paquet Ethernet de couche 2 [SWS_Eth_00152].
• Action : prescrit, via le type énuméré Eth_FilterActionType, si l'adresse indiquée est ajoutée au filtre du contrôleur ou supprimée de celui-ci [SWS_Eth_00152].

La fonction renvoie un statut de type Std_ReturnType : E_OK confirme la modification réussie du filtre, tandis que E_NOT_OK signale que le filtre n'a pas pu être modifié [SWS_Eth_00152]. Si le contrôleur Ethernet n'est matériellement pas en mesure d'effectuer le filtrage de manière autonome, la tâche de filtrage doit être réalisée par le logiciel [SWS_Eth_00152].

Une restriction stricte de réentrance s'applique à l'exécution : la fonction est non réentrante pour le même index de contrôleur (CtrlIdx), mais peut être appelée de manière concurrente et réentrante pour des indices de contrôleur différents les uns des autres [SWS_Eth_00152].

La fonction Eth_WriteMii sert à configurer un registre d'un transceiver Ethernet via l'interface MII ou à déclencher une fonction fournie par le transceiver [SWS_Eth_00058]. La déclaration est disponible via l'en-tête Eth.h [SWS_Eth_00058].

Utilisation et paramètres

L'appel s'effectue avec l'ID de service 0x05 et traite quatre paramètres d'entrée [SWS_Eth_00058] :

• CtrlIdx : index du contrôleur Ethernet dans le contexte du pilote Ethernet [SWS_Eth_00058].
• TrcvIdx : index du transceiver sur l'interface MII [SWS_Eth_00058].
• RegIdx : index du registre de transceiver à écrire sur le MII [SWS_Eth_00058].
• RegVal : valeur 16 bits à écrire dans le registre adressé [SWS_Eth_00058].

L'exécution du service est spécifiée comme asynchrone [SWS_Eth_00058]. Cela signifie que l'opération d'écriture proprement dite sur l'interface matérielle devrait typiquement être traitée en arrière-plan, tandis que la fonction retourne immédiatement après l'acceptation de la requête. Question Q-0f9a9e682985d796 (ouverte)

Valeurs de retour et restrictions

Comme valeur de retour, la fonction fournit le type Std_ReturnType [SWS_Eth_00058] :

• E_OK : l'ordre d'écriture a été accepté avec succès [SWS_Eth_00058].
• E_NOT_OK : le service a été rejeté [SWS_Eth_00058].

En ce qui concerne la concurrence, Eth_WriteMii est spécifié comme non réentrant (Non Reentrant) [SWS_Eth_00058]. Les appels ne doivent donc pas être exécutés de façon concurrente sans synchronisation appropriée par l'appelant.

Utilisation et paramètres

La fonction Eth_ReadMii (Service-ID 0x06) sert à lire un registre de transceiver via l'interface MII et est mise à disposition via le fichier d'en-tête Eth.h [SWS_Eth_00064]. Lors de l'appel, CtrlIdx identifie le contrôleur Ethernet respectif dans le contexte du pilote, TrcvIdx le transceiver adressé sur le MII et RegIdx le registre de transceiver concret [SWS_Eth_00064]. La valeur de registre déterminée est écrite dans la zone mémoire pointée par le pointeur RegValPtr [SWS_Eth_00064].

Exécution et concurrence

L'exécution est asynchrone (Asynchronous) [SWS_Eth_00064]. Une valeur de retour de E_OK confirme alors uniquement que le service ou la commande de lecture a été accepté avec succès (Service accepted), tandis que E_NOT_OK signale un rejet de la commande (Service denied) [SWS_Eth_00064]. En raison du caractère asynchrone, la zone mémoire transmise pour RegValPtr devrait devoir rester valide jusqu'à l'achèvement définitif de l'opération de lecture. Question Q-04a94624b96bf51f (ouverte) La fonction étant en outre classée comme non réentrante (Non Reentrant) [SWS_Eth_00064], les appelants ne doivent pas effectuer d'accès simultanés via différentes tâches ou contextes d'interruption sans synchronisation externe.

Gestion des erreurs

Si le pilote ne peut pas accepter la demande de lecture, l'appel est directement acquitté par E_NOT_OK [SWS_Eth_00064]. Aucun code d'erreur spécifique, aucune vérification à l'exécution DET ou aucun événement de diagnostic DEM n'est indiqué pour cette fonction dans les données de spécification relatives à l'élément.

La fonction synchrone Eth_EnableEgressTimeStamp active l'acquisition d'horodatages d'émission (Egress Time Stamping) pour un objet de message dédié du pilote Ethernet [SWS_Eth_00186]. L'appel s'effectue via l'en-tête Eth.h avec l'ID de service 0x17 et ne fournit aucune valeur de retour [SWS_Eth_00186].

Les paramètres d'entrée suivants doivent être transmis lors de l'appel [SWS_Eth_00186] :

• CtrlIdx : index du contrôleur Ethernet adressé [SWS_Eth_00186].
• BufIdx : index du tampon de messages pour lequel l'application de niveau supérieur attend la génération d'un horodatage d'egress [SWS_Eth_00186].

En ce qui concerne la concurrence, la fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_Eth_00186]. Un appel parallèle pour le même tampon ou d'autres tampons doit donc être synchronisé ou évité du côté de l'appelant.

Le comportement du matériel varie selon l'implémentation du contrôleur : certains matériels enregistrent le marquage pour l'horodatage d'émission de manière permanente, tandis que d'autres contrôleurs exigent obligatoirement l'activation avant chaque transmission [SWS_Eth_00186]. Interprétation : pour un pilotage indépendant du matériel, il devrait donc être judicieux d'appeler la fonction avant chaque opération d'émission du tampon souhaité. Question Q-c2b8d2db03e9d13b (ouverte) Il n'existe pas d'interface de désactivation, car le type de message est toujours transmis avec un horodatage conformément à la conception du réseau [SWS_Eth_00186].

Utilisation

La fonction synchrone Eth_ProvideTxBuffer donne accès à un tampon d'émission Ethernet de la FIFO associée à la priorité transmise [SWS_Eth_00077]. Elle est fournie via l'en-tête Eth.h et est spécifiée comme réentrante [SWS_Eth_00077]. L'index du contrôleur CtrlIdx ainsi que la priorité de trame Priority pour la sélection de la FIFO sont transmis via les paramètres d'entrée [SWS_Eth_00077]. Le paramètre d'entrée-sortie LenBytePtr transmet la taille de tampon souhaitée et renvoie après l'appel la taille en octets effectivement allouée [SWS_Eth_00077]. Les paramètres de sortie BufIdxPtr (index de ressource pour des requêtes ultérieures) et BufPtr (pointeur vers le tampon) fournissent les références vers la zone mémoire [SWS_Eth_00077].

Gestion des erreurs et valeurs de retour

La fonction signale le résultat via des valeurs de retour du type BufReq_ReturnType [SWS_Eth_00077] :

• BUFREQ_OK : le tampon d'émission a été mis à disposition avec succès [SWS_Eth_00077].
• BUFREQ_E_BUSY : toutes les ressources de tampon sont actuellement occupées [SWS_Eth_00077].
• BUFREQ_E_OVFL : le tampon demandé est trop grand [SWS_Eth_00077].
• BUFREQ_E_NOT_OK : une erreur de développement a été détectée [SWS_Eth_00077].

Interaction

Si EthCtrlConfigSwBufferHandling est configuré sur TRUE, un n-uplet composé de l'index de tampon du pool de tampons logiciels transmis à BufIdxPtr et de la priorité indiquée Priority est enregistré en interne [SWS_Eth_00267].

Si Eth_Transmit() est ensuite appelé, l'index de tampon donné est affecté à la FIFO logicielle dont la configuration EthCtrlConfigEgressFifoPriorityAssignment concorde avec la priorité précédemment transmise dans Eth_ProvideTxBuffer() [SWS_Eth_00268].

Utilisation et contexte d'appel

L'interface synchrone Eth_Transmit déclenche le processus d'émission pour un tampon d'émission Ethernet préalablement mis à disposition et rempli [SWS_Eth_00087]. Elle accepte les paramètres suivants :

• CtrlIdx : index du contrôleur Ethernet dans le contexte du pilote [SWS_Eth_00087].
• BufIdx : index de la ressource de tampon à transmettre [SWS_Eth_00087].
• FrameType : type de trame Ethernet spécifique [SWS_Eth_00087].
• TxConfirmation : commutateur d'activation de la confirmation d'émission [SWS_Eth_00087].
• LenByte : longueur des données de la charge utile en octets [SWS_Eth_00087].
• PhysAddrPtr : pointeur vers l'adresse physique de destination (adresse MAC) dans l'ordre des octets du réseau [SWS_Eth_00087].

La valeur de retour de type Std_ReturnType signale avec E_OK l'initiation réussie de la transmission et avec E_NOT_OK un échec [SWS_Eth_00087].

Interaction et traitement des tampons

Dans le cadre du déroulement de l'émission, Eth_Transmit affecte le pointeur de tampon BufIdx à la FIFO logicielle dont l'élément de configuration EthCtrlConfigEgressFifoPriorityAssignment concorde avec la priorité préalablement définie lors de Eth_ProvideTxBuffer() [SWS_Eth_00268]. Avec cet appel, les messages correspondants sont transférés des FIFO logicielles vers la FIFO matérielle [SWS_Eth_00269].

concurrence

La fonction est réentrante pour des appels avec des indices de tampon différents (BufIdx) ainsi que des indices de contrôleur différents (CtrlIdx) [SWS_Eth_00087].

La fonction synchrone Eth_Receive sert à la réception d'une trame Ethernet à partir d'un tampon FIFO spécifique d'un contrôleur Ethernet [SWS_Eth_00095]. Elle ne possède aucune valeur de retour, mais renvoie le résultat de l'interrogation à l'appelant via le pointeur RxStatusPtr de type Eth_RxStatusType [SWS_Eth_00095]. Ce paramètre de sortie indique si une trame a été reçue avec succès et si d'autres trames sont encore prêtes à être récupérées pour le tampon FIFO concerné [SWS_Eth_00095].

Paramètres et contexte d'appel

Comme paramètres d'entrée, la fonction exige l'index de contrôleur CtrlIdx au sein du pilote Ethernet ainsi que l'index FifoIdx de la FIFO à lire [SWS_Eth_00095]. La fonction est déclarée dans le fichier d'en-tête Eth.h [SWS_Eth_00095]. L'appel devrait typiquement avoir lieu périodiquement dans le cadre d'un mécanisme d'interrogation (polling) par des couches supérieures de pilote ou d'interface. Question Q-f5ec0693a5887bcf (ouverte)

Concurrence et restrictions

En ce qui concerne la concurrence, Eth_Receive est implémenté comme réentrant pour différentes FIFO, mais non réentrant pour la même FIFO [SWS_Eth_00095]. Des appels simultanés interrogeant la même FIFO du même contrôleur sont non autorisés et doivent être exclus par le logiciel appelant.

Interaction avec l'Ethernet-Interface

En mode de scrutation (polling), le pilote Ethernet a pour obligation, lors d'une opération de réception réussie, d'appeler directement depuis la routine Eth_Receive la fonction EthIf_RxIndication afin de signaler la trame reçue à la couche supérieure en vue de son traitement ultérieur [SWS_Eth_00244].

Utilisation et contexte d'appel

La fonction Eth_TxConfirmation disponible via l'en-tête Eth.h sert à déclencher de manière ciblée la confirmation de transmission pour les trames Ethernet émises [SWS_Eth_00100]. Elle possède la Service-ID 0x0C et est exécutée de manière synchrone [SWS_Eth_00100]. Comme unique paramètre d'entrée, la fonction attend CtrlIdx, qui détermine l'index logique du contrôleur à adresser au sein de l'instance du pilote Ethernet [SWS_Eth_00100]. Il n'existe pas de valeur de retour (void) et aucun paramètre de sortie n'est transmis [SWS_Eth_00100].

Interaction dans le déroulement de l'émission

Dans l'interaction entre les couches, Eth_TxConfirmation prend en charge la transmission de l'état d'émission à l'interface Ethernet supérieure. Si la notification correspondante a été activée, le pilote Ethernet est tenu d'appeler EthIf_TxConfirmation avec la valeur de résultat E_OK pour signaler une transmission réussie [SWS_Eth_00243]. En mode scrutation, cet appel a lieu explicitement depuis le contexte de la routine Eth_TxConfirmation, tandis qu'en mode géré par interruptions, il est alternativement émis directement depuis la routine d'interruption [SWS_Eth_00243].

Concurrence et conditions d'exécution

Pour l'exécution, s'applique la restriction selon laquelle Eth_TxConfirmation est définie comme non réentrante (Non Reentrant) [SWS_Eth_00100]. Les appels simultanés pour le même contrôleur doivent donc être évités par l'appelant. En mode scrutation, l'appel devrait typiquement être effectué de manière cyclique par un ordonnancement supérieur. Question Q-c19295838459b689 (ouverte) Les codes d'erreur spécifiques ainsi que les prescriptions relatives aux messages DET ou DEM ne sont pas indiqués dans la spécification de la fonction, raison pour laquelle un traitement séparé des erreurs ne s'applique pas.

Utilisation et contexte d'appel

La fonction Eth_MainFunction possède la signature void Eth_MainFunction(void) et est mise à disposition via le fichier d'en-tête SchM_Eth.h [SWS_Eth_00171]. On peut en déduire comme interprétation : l'appel devrait avoir lieu de manière cyclique par le Schedule Manager (SchM) dans un contexte basé sur des tâches, aucun paramètre de transmission ou valeur de retour n'étant défini. Question Q-690a2dc372d49c6a (ouverte)

Périmètre fonctionnel et scrutation

La tâche principale de la fonction consiste en la scrutation (polling) des changements d'état ainsi qu'en la vérification des erreurs de contrôleur et des trames Ethernet perdues [SWS_Eth_00171]. Si la fonction constate que le mode du contrôleur Ethernet a changé, elle appelle la fonction EthIf_CtrlModeIndication pour informer la couche supérieure du changement d'état [SWS_Eth_00171].

Ordre de traitement dans le chemin d'émission

Dans le contexte de Eth_MainFunction(), un ordre fixe est prescrit pour le traitement des FIFO logicielles [SWS_Eth_00270] :

• Tout d'abord, toutes les SW-FIFO font l'objet d'une itération et leurs comptes de crédits (Credits Account) sont mis à jour [SWS_Eth_00270].
• Ensuite, toutes les SW-FIFO font à nouveau l'objet d'une itération et sont vérifiées quant à la présence de messages prêts à être émis [SWS_Eth_00270].
• Pour chaque SW-FIFO ayant fait l'objet de l'itération, la transmission est alors entreprise [SWS_Eth_00270].

Le type d'énumération générique Eth_ModeType sert, dans les couches de la pile de communication Ethernet (telles que EthIf, Eth, EthSwt et EthTrcv), à activer ou à désactiver le canal de communication Ethernet ainsi qu'à basculer le matériel associé (tel que contrôleur Ethernet, port de switch Ethernet ou émetteur-récepteur Ethernet) dans un état de veille à faible consommation d'énergie ou dans un mode actif [SWS_Eth_00158].

Le type est disponible via le fichier d'en-tête Eth_GeneralTypes.h et définit les plages de valeurs suivantes [SWS_Eth_00158] :

• ETH_MODE_DOWN (0x00) : Désactive le canal de communication Ethernet et fait passer le matériel associé dans un mode de veille à faible consommation (Low-Power Sleep Mode) [SWS_Eth_00158].
• ETH_MODE_ACTIVE (0x01) : Active le canal de communication Ethernet et fait passer le matériel dans le mode de fonctionnement (Power-On Mode) [SWS_Eth_00158].

Concernant le cycle de vie et l'utilisation, il convient de noter que Eth_ModeType est marqué avec le statut obsolete dans la version R20-11 [SWS_Eth_00158]. Dans les nouveaux développements, l'utilisation de ce type devrait donc être évitée, car les types d'interface obsolètes sont typiquement remplacés par des structures de contrôle plus modernes dans les futures normes.

Le type énumération Eth_ModeType est déclaré via Eth_GeneralTypes.h et sert de type de mode inter-couches dans la pile de communication Ethernet AUTOSAR ([SWS_Eth_91008]). Il est utilisé dans des modules tels que EthIf, Eth, EthSwt et EthTrcv pour activer ou désactiver de manière ciblée des canaux de communication et pour basculer le composant matériel associé (contrôleur Ethernet, ports de switch ou transceiver) entre un mode veille à faible consommation d'énergie et le mode de fonctionnement actif ([SWS_Eth_91008]).

Le type comprend trois états pour la commande de mode ([SWS_Eth_91008]) :

• ETH_MODE_DOWN (0x00) : désactive la communication Rx et Tx et place le matériel associé dans un mode veille à faible consommation (Low-Power-Sleep). Dans la mesure où le matériel le prend en charge, un processus de mise en veille est initié en même temps (par exemple, la demande de veille sur la ligne de données conformément à OPEN Alliance TC10).
• ETH_MODE_ACTIVE (0x01) : active la communication Rx et Tx et commute le matériel associé dans le mode de fonctionnement régulier (Power-on).
• ETH_MODE_ACTIVE_WITH_WAKEUP_REQUEST (0x02) : active la communication Rx et Tx, place le matériel en mode de fonctionnement et déclenche en outre une requête de réveil sur le réseau si le matériel dispose de capacités de réveil (comme le réveil sur la ligne de données selon OPEN Alliance TC10).

Dans l'interaction au sein de la pile, Eth_ModeType prend notamment en charge la transmission des requêtes de réveil depuis la couche de services (ComM), via les couches intermédiaires, jusqu'aux pilotes de communication (EthTrcv), ce qui permet de commander selon les besoins le matériel doté de fonctionnalités de réveil et de veille sur la ligne de données ([SWS_Eth_91008]).

Le type énuméré Eth_StateType est mis à disposition via l'en-tête Eth_GeneralTypes.h et sert, conformément à [SWS_Eth_00159], à la surveillance d'état du pilote Ethernet. Son but réside dans la prise en charge de la détection des erreurs de développement (Development Error Detection), l'état actuel devant, d'après la spécification, être disponible à des fins de débogage ([SWS_Eth_00159]).

Pour la gestion de l'état, Eth_StateType définit deux valeurs d'énumération discrètes ([SWS_Eth_00159]) :

• ETH_STATE_UNINIT (valeur 0x00) : indique que le pilote Ethernet n'est pas encore configuré ([SWS_Eth_00159]).
• ETH_STATE_INIT (valeur 0x01) : indique que le pilote Ethernet est configuré avec succès ([SWS_Eth_00159]).

Concernant le traitement des erreurs et l'interaction, ce type d'état constitue la base de la détection interne des erreurs. On devrait pouvoir supposer que les API du pilote interrogent cet état et rejettent les appels tant que le pilote se trouve dans l'état non initialisé ETH_STATE_UNINIT ([SWS_Eth_00159]). Question Q-35a17e3267274d70 (ouverte) Ce n'est que lorsque le pilote est passé à l'état ETH_STATE_INIT qu'il est considéré comme configuré et opérationnel ([SWS_Eth_00159]). La définition de type se trouvant dans Eth_GeneralTypes.h, elle est disponible pour l'ensemble des pilotes ([SWS_Eth_00159]).

Utilisation et plage de valeurs

Le type énuméré Eth_RxStatusType est défini conformément à [SWS_Eth_00162] dans le fichier d'en-tête Eth_GeneralTypes.h. Il sert de paramètre de sortie (out parameter) dans la fonction Eth_Receive(), par l'intermédiaire duquel le pilote Ethernet indique si une trame Ethernet a été reçue et si d'autres trames sont ensuite présentes dans le tampon ou si des données ont été perdues [SWS_Eth_00162].

La spécification définit trois valeurs d'énumération discrètes pour ce type [SWS_Eth_00162] :

• ETH_RECEIVED (0x00) : une trame Ethernet a été reçue ; plus aucune trame n'est disponible dans le contrôleur.
• ETH_NOT_RECEIVED (0x01) : aucune trame Ethernet n'a été reçue ; aucune autre trame n'est présente.
• ETH_RECEIVED_MORE_DATA_AVAILABLE (0x02) : une trame Ethernet a été reçue, et des trames supplémentaires sont prêtes à être récupérées.

Interaction lors du traitement des trames

Lors de l'appel de Eth_Receive(), la couche appelante transmet un pointeur vers une variable du type Eth_RxStatusType. L'évaluation de ce paramètre de sortie pilote la suite du déroulement du cycle de réception : la valeur de retour ETH_RECEIVED_MORE_DATA_AVAILABLE devrait servir de critère à l'appelant pour rappeler immédiatement Eth_Receive(), afin de traiter rapidement les trames restantes du tampon de réception [SWS_Eth_00162]. Question Q-4ed309522aa004f8 (ouverte) Les états ETH_RECEIVED et ETH_NOT_RECEIVED signalent en revanche que le tampon est épuisé et qu'aucune autre donnée n'est en attente de traitement. La mise à disposition via Eth_GeneralTypes.h garantit ce faisant une utilisation uniforme du type à travers les modules [SWS_Eth_00162].

Utilisation et finalité

Le type de données Eth_TxErrorCounterValuesType est spécifié conformément à [SWS_Eth_91004] sous forme de structure pour des compteurs statistiques à des fins de diagnostic dans le pilote Ethernet. La définition est disponible via le fichier d'en-tête Eth_GeneralTypes.h. La structure regroupe plusieurs compteurs 32 bits (uint32) qui représentent des états de transmission spécifiques et des entraves à l'émission au niveau de l'interface.

Composants de la structure et sémantique

Les différents compteurs s'inspirent, conformément à [SWS_Eth_91004], de définitions MIB de réseau standardisées :

• Tx Dropped No Error Pkts : Nombre de paquets sortants qui ont été rejetés bien qu'exempts d'erreurs, par exemple pour libérer de la mémoire tampon (RFC1213 ifOutDiscards).
• Tx Dropped Error Pkts : Nombre de paquets qui n'ont pas pu être transmis en raison d'erreurs survenues (RFC1213 ifOutErrors).
• Tx Deferred Trans : Nombre de trames dont la première tentative d'émission a été retardée parce que le support de transmission était occupé (RFC1643 dot3StatsDeferredTransmissions).
• Tx Single Collision et Tx Multiple Collision : Trames transmises avec succès dont l'émission a été retardée par exactement une ou par plusieurs collisions (RFC1643).
• Tx Late Collision : Collisions détectées plus de 512 temps-bits après le début de la transmission du paquet (RFC1643 dot3StatsLateCollisions).
• Tx Excessive Collison : Nombre de transmissions qui ont définitivement échoué à la suite d'un trop grand nombre de collisions (RFC1643 dot3StatsExcessiveCollisions).

Contexte d'appel et restrictions

Interprétation : comme l'extrait de spécification ne mentionne aucune fonction d'API associée, ce type de diagnostic devrait probablement être transmis par pointeur comme paramètre de sortie à des fonctions de pilote correspondantes pour l'interrogation des compteurs. Question Q-2bfbe59d1fb81938 (ouverte) Aucune exigence spécifique concernant la gestion des erreurs, les messages DET ou la concurrence n'est définie dans les sources pour cette simple structure de données.