LIN Driver (Lin)

Le pilote LIN encapsule le matériel LIN du microcontrôleur et met à la disposition du LIN Interface des services par canal pour les trames, l’état de veille et le réveil. Les canaux maîtres déclenchent les trames de manière asynchrone avec Lin_SendFrame et les évaluent via Lin_GetStatus. Les canaux esclaves réagissent à chaque en-tête reçu par une indication destinée au LIN Interface, puis transmettent, reçoivent ou ignorent la réponse ([SWS_Lin_00280]). Les services disponibles dépendent du type de nœud configuré ; les services maîtres ne sont présents que s’il existe au moins un canal maître ([SWS_Lin_00287]).

plus ›

Le pilote LIN Lin est le pilote matériel de la pile LIN. Il encapsule des contrôleurs LIN ou des SCI/UART (SWS LIN Driver p. 9) et propose au LIN Interface des services par canal pour les trames, l’état de veille et le réveil. Il requiert obligatoirement Dem_SetEventStatus, EcuM_SetWakeupEvent et LinIf_WakeupConfirmation ([SWS_Lin_00234]). En option, il utilise DET, Icu et les callbacks esclaves du LinIf ([SWS_Lin_00235]).

Diagramme de contexte : Lin s’intercale entre LinIf et le matériel LIN et signale les réveils et les erreurs à EcuM, LinIf, DEM et DET. Sources : [SWS_Lin_00234], [SWS_Lin_00235]

Lin_Init fait passer le module de LIN_UNINIT à LIN_INIT ([SWS_Lin_00006], SWS LIN Driver p. 24). Ensuite, chaque canal bascule entre LIN_CH_OPERATIONAL, LIN_CH_SLEEP_PENDING (maître uniquement) et LIN_CH_SLEEP. Pour cela, Lin_GoToSleep, Lin_GoToSleepInternal, Lin_Wakeup et Lin_WakeupInternal sont disponibles ([SWS_Lin_00166], [SWS_Lin_00167], [SWS_Lin_00169], [SWS_Lin_00256]).

Diagramme d’états : états du module et états de canal avec leurs transitions. Le fait que Lin_GetStatus termine l’étape vers LIN_CH_SLEEP constitue une interprétation du schéma. Sources : SWS LIN Driver p. 24, [SWS_Lin_00166]

Les canaux maîtres et esclaves fonctionnent de manière fondamentalement différente. Un maître déclenche des trames de manière asynchrone avec Lin_SendFrame et interroge ultérieurement le résultat avec Lin_GetStatus ([SWS_Lin_00191], [SWS_Lin_00168]). Ces services n’existent que si au moins un canal est configuré en tant que maître ([SWS_Lin_00287]). Un esclave signale chaque en-tête par LinIf_HeaderIndication ([SWS_Lin_00280]). Selon Drc, il transmet, reçoit ou ignore ensuite la réponse et la termine par LinIf_TxConfirmation ou LinIf_RxIndication ([SWS_Lin_00282], [SWS_Lin_00274], [SWS_Lin_00275]).

Lin_CheckWakeup vérifie les réveils provenant du bus et les signale à EcuM et LinIf ([SWS_Lin_00160]). En cas d’erreur, les utilisations incorrectes sont transmises à la DET, par exemple LIN_E_UNINIT ([SWS_Lin_00258]). Un timeout matériel est signalé au DEM sous forme de LIN_E_TIMEOUT ([SWS_Lin_00290]). Un canal maître renvoie les erreurs de bus en tant qu’état, tandis qu’un canal esclave les signale via LinIf_LinErrorIndication ([SWS_Lin_00233], [SWS_Lin_00277]).

plus ›

Rôle, limites du système et liaison aux instances du pilote LIN

Le pilote LIN Lin encapsule le matériel LIN du microcontrôleur. Il fournit au LIN Interface (LinIf) des services par canal : émettre et recevoir des trames, mettre les canaux en veille et les réveiller, ainsi que vérifier les réveils. Tous les services sont disponibles via Lin.h ([SWS_Lin_00191], [SWS_Lin_00160]). En tant que matériel, la spécification mentionne trois types d’unités matérielles LIN : les contrôleurs LIN complets, les SCI/UART simples et les SCI/UART évolués. Ils sont chacun raccordés à un cluster LIN via des CI émetteurs-récepteurs (SWS LIN Driver p. 9). Le pilote ne fournit lui-même aucune fonction de rappel (SWS LIN Driver p. 49). Il appelle à la place des fonctions de son environnement.

Les interfaces obligatoires vers l’extérieur sont Dem_SetEventStatus, EcuM_SetWakeupEvent et LinIf_WakeupConfirmation ([SWS_Lin_00234]). En option, le pilote utilise notamment :

• Det_ReportError et EcuM_CheckWakeup,
• Icu_EnableNotification et Icu_DisableNotification,
• pour les canaux esclaves, les callbacks LinIf_HeaderIndication, LinIf_RxIndication et LinIf_LinErrorIndication ([SWS_Lin_00235]).

[SWS_Lin_00226] répertorie les types importés tels que NetworkHandleType, EcuM_WakeupSourceType ou Std_ReturnType.

Diagramme de contexte : Lin se situe entre LinIf et l’unité matérielle LIN. Le pilote signale les réveils à EcuM et LinIf, et les erreurs à DEM et DET. Sources : [SWS_Lin_00234], [SWS_Lin_00235], SWS LIN Driver p. 9

Le pilote peut être partitionné. Il fonctionne dans chaque partition comme une instance indépendante, et un appel d’API n’agit que sur la partition dans laquelle il a lieu ([SWS_Lin_CONSTR_00270]). Si LinEcucPartitionRef référence des partitions, LinChannelEcucPartitionRef doit faire référence à exactement l’une d’entre elles ([SWS_Lin_CONSTR_00291]). LinChannel et LinTrcvChannel d’un canal de communication doivent référencer la même partition ([SWS_Lin_CONSTR_00279]). Le module rejette les affectations de partitions que l’implémentation ne prend pas en charge ([SWS_Lin_00269]). Par canal, on configure entre autres le débit binaire, l’ID de canal, LinChannelWakeupSupport et le type de nœud LinNodeType. Cette description de conteneur est issue d’une release ultérieure (SWS LIN Driver p. 60).

États du module et des canaux, de Lin_Init jusqu’à l’état de veille

Après le reset, le module est dans l’état LIN_UNINIT et n’est pas utilisable. Lin_Init le fait passer à LIN_INIT ; chaque canal disponible y est prêt pour le service (SWS LIN Driver p. 24). Lin_Init reçoit un pointeur vers une structure Lin_ConfigType. Son contenu est spécifique au matériel ; elle contient les données d’initialisation pour le pilote, l’unité matérielle et les canaux ([SWS_Lin_00006], [SWS_Lin_00227]). L’environnement ne doit appeler Lin_Init qu’une seule fois au cours de l’exécution (SWS LIN Driver p. 24).

À l’intérieur de LIN_INIT, chaque canal possède son propre état :

• LIN_CH_OPERATIONAL : le canal participe au cluster.
• LIN_CH_SLEEP : la détection de réveil est active, le matériel est le cas échéant en mode basse consommation.
• LIN_CH_SLEEP_PENDING : uniquement pour les canaux maîtres, après Lin_GoToSleep.

Justificatifs : SWS LIN Driver p. 24, [SWS_Lin_00166]. Lin_GoToSleepInternal place directement le canal sur LIN_CH_SLEEP ([SWS_Lin_00167]). Lin_Wakeup ramène à LIN_CH_OPERATIONAL avec une impulsion de réveil, Lin_WakeupInternal sans impulsion ([SWS_Lin_00169], [SWS_Lin_00256]).

Interprétation : Lin_GetStatus devrait conclure la transition de LIN_CH_SLEEP_PENDING à LIN_CH_SLEEP. Question Q-bb592e1d2ab668f0 (ouverte) Le schéma présente Lin_GetStatus comme une transition dans la partie maître, et le LIN Interface attend la valeur de retour LIN_CH_SLEEP lors de la vérification de la commande Go-to-sleep (SWS LIN Interface p. 56).

Diagramme d’états : Lin_Init fait passer le module de LIN_UNINIT à LIN_INIT. Au sein de celui-ci, chaque canal bascule entre fonctionnement et veille par le biais de services de veille et de réveil ; la transition via Lin_GetStatus est une interprétation. Sources : SWS LIN Driver p. 24, [SWS_Lin_00166], [SWS_Lin_00167], [SWS_Lin_00169], [SWS_Lin_00256]

Description de trame via Lin_PduType et mappage des données

Entre LinIf et le pilote, Lin_PduType décrit une trame. La structure contient Pid, le modèle de somme de contrôle Cs, le sens de réponse Drc, la longueur des données Dl et le pointeur de données SduPtr ([SWS_Lin_00232]). Les types des éléments :

• Lin_FramePidType : identifiant 0…0x3F avec deux bits de parité, plage de valeurs 0…0xFE ([SWS_Lin_00228]).
• Lin_FrameDlType : 1…8 octets de données ([SWS_Lin_00231]).
• Lin_FrameCsModelType : LIN_ENHANCED_CS ou LIN_CLASSIC_CS ([SWS_Lin_00229]). Le pilote doit pouvoir calculer les deux sommes de contrôle ([SWS_Lin_00019]).

Lin_FrameResponseType définit la manière dont le nœud traite la réponse ([SWS_Lin_00230]) : il l’émet lui-même (LIN_FRAMERESPONSE_TX), reçoit une réponse externe pertinente (LIN_FRAMERESPONSE_RX) ou l’ignore (LIN_FRAMERESPONSE_IGNORE). En mémoire, le premier octet transmis se trouve dans l’élément 0, le dernier octet transmis dans l’élément n-1 (SWS LIN Driver p. 30). Si le matériel ne peut pas mettre en mémoire tampon les octets, comme dans le cas d’un simple UART, le pilote met à disposition un tampon temporaire. L’émission avec contrôle par relecture et la réception s’exécutent sans blocage (SWS LIN Driver p. 28).

Canaux maîtres : Lin_SendFrame et interrogation de statut

Sur les canaux maîtres, LinIf déclenche chaque trame avec le service asynchrone Lin_SendFrame. Le service émet l’en-tête LIN et, le cas échéant, la réponse ([SWS_Lin_00191]). Cela s’applique aux entrées de réception, d’émission et Slave-to-Slave de la table d’ordonnancement (SWS LIN Interface p. 34, SWS LIN Interface p. 37, SWS LIN Interface p. 40).

LinIf interroge le résultat avec le service synchrone Lin_GetStatus : au plus tôt après la longueur maximale de trame, au plus tard lors de la prochaine entrée échue de la table d’ordonnancement (SWS LIN Interface p. 35, [SWS_Lin_00168]). Le service retourne un Lin_StatusType, tel que LIN_TX_OK, LIN_TX_BUSY, LIN_RX_OK, LIN_RX_BUSY ou LIN_RX_NO_RESPONSE. Via Lin_SduPtr, il renvoie en outre un pointeur vers le tampon de réception miroir ou matériel ([SWS_Lin_00233]).

Les données reçues restent cohérentes jusqu’à ce que la trame suivante ait été reçue avec succès ou que l’état du canal change. L’intégralité du traitement de la réception peut se situer dans Lin_GetStatus (SWS LIN Driver p. 30). Pour les trames déclenchées par événement, les règles suivantes s’appliquent (SWS LIN Interface p. 127, SWS LIN Interface p. 129) :

• LIN_RX_NO_RESPONSE n’interprète pas LinIf comme une erreur.
• LIN_RX_ERROR est considéré comme une collision et entraîne le basculement vers la table d’ordonnancement de résolution des collisions.

Lin_SendFrame, Lin_GoToSleep et Lin_GetStatus n’existent que si au moins un canal est configuré en tant que maître par LinNodeType ([SWS_Lin_00287], [SWS_Lin_00288], [SWS_Lin_00289]). Dans R20-11, ces services sont spécifiés comme non réentrants ([SWS_Lin_00168]). Des versions ultérieures autorisent la réentrance pour différents canaux (SWS LIN Driver p. 48) ; pour R20-11, l’exigence s’applique.

Diagramme de séquence : le maître déclenche une trame de manière asynchrone avec Lin_SendFrame et évalue le résultat lors d’appels ultérieurs de MainFunction via Lin_GetStatus. Sources : [SWS_Lin_00191], [SWS_Lin_00168], SWS LIN Interface p. 128, SWS LIN Interface p. 129, SWS LIN Interface p. 40

Canaux esclaves : traitement de la réponse piloté par l’en-tête

Un canal esclave doit pouvoir recevoir un en-tête à tout moment dans LIN_CH_OPERATIONAL ([SWS_Lin_00272]). Pour chaque en-tête, le pilote appelle LinIf_HeaderIndication. À cette occasion, PduPtr->Pid contient le PID reçu, et PduPtr->SduPtr pointe vers son tampon matériel ou miroir ([SWS_Lin_00280]). Si le matériel ne détecte pas les PID non valides, le pilote transmet le PID sans vérification ([SWS_Lin_00271]). Après le retour E_OK, il évalue PduPtr->Drc ([SWS_Lin_00282]) :

• En présence de LIN_FRAMERESPONSE_TX, il utilise Cs, Dl et SduPtr pour émettre la réponse ([SWS_Lin_00283]).
• En présence de LIN_FRAMERESPONSE_RX, il configure la réception avec Cs et Dl ([SWS_Lin_00284]).

Si LinIf_HeaderIndication retourne E_NOT_OK ou si Drc est égal à LIN_FRAMERESPONSE_IGNORE, le pilote ignore la réponse ([SWS_Lin_00286]). Il ne signale alors rien jusqu’à l’en-tête suivant ([SWS_Lin_00276]). Il transmet directement une réponse reçue avec succès par LinIf_RxIndication et confirme une réponse émise par LinIf_TxConfirmation ([SWS_Lin_00274], [SWS_Lin_00275]). Chaque réponse pertinente doit être terminée par l’un de ces callbacks ou par LinIf_LinErrorIndication avant que l’en-tête suivant ne soit signalé ([SWS_Lin_00285]). Le schéma de réception distingue deux variantes matérielles : le contrôleur LIN matériel et le simple UART pour lequel le pilote copie chaque octet dans un tampon par interruption (SWS LIN Driver p. 57).

Diagramme de séquence : sur un canal esclave, chaque en-tête déclenche une indication vers LinIf. Selon Drc, le pilote transmet, reçoit ou ignore la réponse. Sources : [SWS_Lin_00280], [SWS_Lin_00282], [SWS_Lin_00283], [SWS_Lin_00284], [SWS_Lin_00286], [SWS_Lin_00274], [SWS_Lin_00275], SWS LIN Interface p. 121, SWS LIN Interface p. 132

Veille, réveil et détection de réveil

Seul un maître peut émettre la commande Go-to-sleep. Lin_GoToSleep l’envoie de manière asynchrone selon LIN 2.1 et positionne le canal sur LIN_CH_SLEEP_PENDING, même en cas d’échec de transmission. Si LinChannelWakeupSupport est configuré, le service active en outre la surveillance du bus ([SWS_Lin_00166], SWS LIN Driver p. 43). Pour les esclaves, Lin_GoToSleep n’est pas applicable ; ils utilisent Lin_GoToSleepInternal (SWS LIN Driver p. 31). Ce service définit LIN_CH_SLEEP de manière synchrone, active la détection de réveil et bascule facultativement le matériel dans un mode d’économie d’énergie ([SWS_Lin_00167], SWS LIN Driver p. 44). Chaque canal accepte les demandes de mise en veille indépendamment des autres (SWS LIN Driver p. 31).

Deux services sont disponibles pour le réveil. Lin_Wakeup envoie une impulsion de réveil sur le bus, Lin_WakeupInternal met le canal en service sans impulsion ([SWS_Lin_00169], [SWS_Lin_00262]). Lin_CheckWakeup vérifie un réveil provenant du bus. Si le service détecte un événement, par exemple un niveau RxD bas de manière permanente, il le signale immédiatement à l’EcuM par EcuM_SetWakeupEvent et à LinIf par LinIf_WakeupConfirmation ([SWS_Lin_00160], SWS LIN Driver p. 42). LinIf_CheckWakeup décide en fonction de la source de réveil si Lin_CheckWakeup ou LinTrcv_CheckWakeup est appelé (SWS LIN Interface p. 112). LIN ne requiert aucune validation de réveil (SWS EcuM p. 173).

Diagramme de séquence : un réveil en provenance du bus est transmis à Lin_CheckWakeup via EcuM et LinIf_CheckWakeup. Le pilote signale un événement détecté à EcuM et LinIf. Sources : [SWS_Lin_00160], [SWS_Lin_00234], SWS LIN Driver p. 42, SWS LIN Interface p. 112, SWS EcuM p. 147

Comportement en cas d'erreur

Lorsque la détection des erreurs de développement est activée, les services signalent les utilisations incorrectes à la DET ([SWS_Lin_00258], [SWS_Lin_00259], [SWS_Lin_00260] ; de manière analogue pour Lin_Wakeup : SWS LIN Driver p. 45) :

• LIN_E_UNINIT en cas d’appel avant l’initialisation,
• LIN_E_INVALID_CHANNEL en cas de canal non valide ou inactif,
• LIN_E_STATE_TRANSITION en cas de réveil en dehors de LIN_CH_SLEEP.

Lin_GetVersionInfo signale un pointeur NULL avec LIN_E_PARAM_POINTER ([SWS_Lin_00161], SWS LIN Driver p. 41). Lorsque la DET est désactivée, Lin_CheckWakeup retourne E_NOT_OK pour un canal non valide (SWS LIN Driver p. 42). De manière générale, E_NOT_OK et LIN_NOT_OK indiquent qu’une erreur de développement ou de production est survenue ([SWS_Lin_00191], [SWS_Lin_00233]).

LIN_E_TIMEOUT est spécifié comme erreur de production. Si, après une modification apportée aux registres de commande matériels, il est nécessaire d'attendre un changement d'état, un délai d'attente configurable sécurise cette attente. S'il expire, l'erreur est signalée ([SWS_Lin_00290]). La notification est transmise via Dem_SetEventStatus ([SWS_Lin_00234]) à l'événement référencé dans LinDemEventParameterRefs (SWS LIN Driver p. 65).

Le pilote signale les erreurs de communication différemment selon le type de nœud. Les canaux maîtres les fournissent sous la forme de l'état de Lin_GetStatus ([SWS_Lin_00233]) :

• LIN_TX_HEADER_ERROR en cas d'erreurs de relecture, de parité ou de bus dans le header,
• LIN_TX_ERROR en cas de transmission de réponse erronée,
• LIN_RX_ERROR en cas d'erreurs de trame (framing), de dépassement de capacité (overrun) ou de somme de contrôle, ainsi que de réponse trop courte.

Les canaux esclaves interrompent le traitement de la trame et appellent LinIf_LinErrorIndication avec un Lin_SlaveErrorType ([SWS_Lin_00277], [SWS_Lin_91140]). Ils signalent les événements de bus non valides pendant l'attente d'un header en tant que LIN_ERR_HEADER ([SWS_Lin_00281]).

Diagramme d'activité : les erreurs de développement sont transmises à la DET, le dépassement de délai matériel au DEM. Un canal maître signale les erreurs de communication de bus sous forme d'état, un canal esclave sous forme d'indication d'erreur. Sources : [SWS_Lin_00258], [SWS_Lin_00290], [SWS_Lin_00233], [SWS_Lin_00277], [SWS_Lin_00281], [SWS_Lin_00235]

Preuves détaillées supplémentaires

• Services maîtres : émission avec [SWS_Lin_00191], état avec [SWS_Lin_00168], valeurs d'état dans [SWS_Lin_00233].
• Déroulement esclave de l'indication de header jusqu'à l'achèvement : de [SWS_Lin_00280] à [SWS_Lin_00286], complété par [SWS_Lin_00272] à [SWS_Lin_00277].
• Veille et réveil : [SWS_Lin_00166], [SWS_Lin_00167], [SWS_Lin_00169], [SWS_Lin_00256], [SWS_Lin_00262]. La détection du réveil est décrite par [SWS_Lin_00160].
• Description de trame : [SWS_Lin_00232] avec les types d'éléments [SWS_Lin_00228] à [SWS_Lin_00231].
• Dépendance vis-à-vis du type de nœud : de [SWS_Lin_00287] à [SWS_Lin_00289]. Partitionnement : [SWS_Lin_CONSTR_00270], [SWS_Lin_CONSTR_00279], [SWS_Lin_CONSTR_00291].
• Automate d'états et états de canal : SWS LIN Driver p. 24.
• Historique des modifications : Lin_SendFrame est issu de Lin_SendHeader et Lin_SendResponse, LIN_E_TIMEOUT a été défini comme erreur de production (SWS LIN Driver p. 4).