CAN Driver (Can)

Modul	Can (CAN Driver)
BSW-Modul-ID	`80`
Standard-Header	`#include "Can.h"`
SWS-Spezifikation	AUTOSAR_SWS_CANDriver.pdf
Cluster	CAN

Guide du moduleGÉNÉRÉ PAR IA

Pilote le matériel du contrôleur CAN et assure la transmission, la réception et les changements d'état vers le CAN Interface.

GÉNÉRÉ PAR IA non vérifié Modèle : claude-opus-5-5 · Effort : high · Température : non réglable · Prompt : b6833c934a77 Provenance Questions ouvertes (2)

traduit du guide allemandGénéré par l'IAgemini-3.8-flash-low · 2026-10-13 · Original allemand

Pilote le matériel du contrôleur CAN et assure la transmission, la réception et les changements d'état vers le CAN Interface.

Le pilote CAN commande les contrôleurs CAN d'une unité matérielle et constitue la couche matérielle sous le CAN Interface. Il lui signale la réception, la confirmation d'émission, le Bus-off et les changements de mode par rappel [SWS_Can_00234]. Selon Can_Init, tous les contrôleurs sont à l'état STOPPED. Chaque contrôleur est démarré individuellement et de manière asynchrone avec Can_SetControllerMode ; le succès n'est notifié qu'ultérieurement [SWS_Can_00230]. L'émission s'effectue avec Can_Write via des handles d'émission matériels. Si aucun objet d'émission n'est disponible, le pilote renvoie CAN_BUSY, et CanIf met la requête en mémoire tampon.

Le pilote CAN encapsule chaque accès aux contrôleurs CAN d'une unité matérielle. Il sert uniquement le CAN Interface en tant qu'utilisateur unique et signale la réception, la confirmation d'émission, le Bus-off et les changements de mode via des rappels CanIf prédéfinis [SWS_Can_00234]. L'ECU State Manager l'initialise avec Can_Init et un Can_ConfigType spécifique au matériel [SWS_Can_00223]. Ensuite, le pilote est dans l'état CAN_READY et tous les contrôleurs sont dans l'état STOPPED SWS CANDriver p. 29.

Diagramme de contexte : intégration de Can entre EcuM, BSW Scheduler, CanIf, DET, Os et le matériel du contrôleur. Sources : [SWS_Can_00234], SWS CANDriver p. 78

Chaque contrôleur passe par les états UNINIT, STOPPED, STARTED et SLEEP [SWS_Can_91013]. Il est démarré individuellement et de manière asynchrone avec Can_SetControllerMode : E_OK signifie uniquement « accepté » [SWS_Can_00230]. Le pilote signale ultérieurement l'état atteint via CanIf_ControllerModeIndication SWS CANDriver p. 33. Le Bus-off fait passer le contrôleur à STOPPED sans reprise matérielle ; un réveil du bus le fait passer de SLEEP à STOPPED SWS CANDriver p. 35.

Diagramme d'état : transitions d'un contrôleur par appels logiciels ainsi que par événements de Bus-off et de réveil. Sources : [SWS_Can_91010], SWS CANDriver p. 38

L'émission s'effectue avec Can_Write(Hth, PduInfo). Les deux bits de poids fort de Can_IdType distinguent CAN 2.0 et CAN FD ainsi que l'ID standard et étendue [SWS_Can_00233] [SWS_Can_00416]. Si aucun objet d'émission n'est libre, le pilote renvoie CAN_BUSY, et CanIf met la requête en mémoire tampon [SWS_Can_00039] SWS CANDriver p. 47. Les événements sont détectés par interruption ou par polling. Pour le polling, il existe des fonctions principales cycliques SWS CANDriver p. 41 :

Write et Read : confirmations d'émission et réception
BusOff et Wakeup : événements de Bus-off et de réveil
Mode : transitions de mode

Les fonctions principales sont définies dans [SWS_Can_00225] à [SWS_Can_00228] et [SWS_Can_00368].

En cas d'erreur, le pilote signale des erreurs de développement telles que CAN_E_UNINIT ou CAN_E_TRANSITION au DET [SWS_Can_91019]. Les fonctions avec valeur de retour renvoient alors E_NOT_OK SWS CANDriver p. 48. La reprise après Bus-off est prise en charge par le CanSM via CanIf. Le redémarrage devrait à nouveau s'effectuer via Can_SetControllerMode(CAN_CS_STARTED) SWS CANInterface p. 138. L'état d'erreur et les compteurs d'erreurs peuvent être interrogés ; les valeurs des compteurs ne sont toutefois pas considérées comme un état de bus fiable [SWS_Can_91004] [SWS_Can_00516]. Question (ouverte)

Rôle : pilote proche du matériel entre CanIf et contrôleurs CAN

Le pilote CAN encapsule tout accès au matériel CAN d'une unité matérielle. Les changements d'état des contrôleurs s'effectuent uniquement via Can_Init, Can_SetBaudrate et Can_SetControllerMode. Le pilote ne mémorise pas lui-même les changements d'état SWS CANDriver p. 30. Son partenaire vers le haut est le CAN Interface. Tous les rappels que le pilote appelle sont implémentés dans CanIf et ne sont pas configurables : CanIf_RxIndication, CanIf_TxConfirmation, CanIf_ControllerBusOff et CanIf_ControllerModeIndication. De plus, il nécessite Det_ReportRuntimeError et le service Os GetCounterValue [SWS_Can_00234] SWS CANDriver p. 73. Les types importés proviennent notamment de ComStack_Types, EcuM et Os [SWS_Can_00222].

L'ECU State Manager initialise le pilote via Can_Init. Selon la note d'implémentation, il n'appelle la fonction qu'au plus une fois à l'exécution [SWS_Can_00223] SWS CANDriver p. 29. Le BSW Scheduler appelle directement les fonctions principales cycliques. Elles n'ont ni paramètres ni valeur de retour et ne sont pas réentrantes ; aucun ordre d'exécution n'est prescrit SWS CANDriver p. 78. Vers le bas, le pilote ne propose aucun rappel. Les contrôleurs CAN externes ne doivent être adressés que via des API MCAL synchrones telles que SPI SWS CANDriver p. 76.

Diagramme de contexte : Can est initialisé par EcuM, appelé cycliquement par le BSW Scheduler et utilisé par CanIf. Il notifie CanIf, EcuM et DET et utilise Os pour les temporisations. Sources : [SWS_Can_00234], SWS CANDriver p. 45, SWS CANDriver p. 78

De la mise sous tension à STARTED : états du pilote et du contrôleur

Le pilote dans son ensemble ne connaît que les états CAN_UNINIT et CAN_READY. Après la réinitialisation, il se trouve à l'état CAN_UNINIT. Can_Init initialise tous les contrôleurs conformément à la configuration, puis passe à CAN_READY. Can_DeInit positionne l'état du module sur CAN_UNINIT avant de désinitialiser les contrôleurs [SWS_Can_00223] [SWS_Can_91002] SWS CANDriver p. 29.

Distincts de cela, chaque contrôleur possède quatre états parmi Can_ControllerStateType : CAN_CS_UNINIT, CAN_CS_STOPPED, CAN_CS_STARTED et CAN_CS_SLEEP [SWS_Can_91013].

À l'état STOPPED, le contrôleur est initialisé, mais ne participe pas au bus et n'émet ni trames d'erreur ni acquittements.
STARTED correspond au fonctionnement normal.
SLEEP ne diffère de STOPPED que sur le matériel disposant d'un mode veille SWS CANDriver p. 31.

Can_Init fait passer tous les contrôleurs à STOPPED SWS CANDriver p. 32. Can_DeInit les fait passer de STOPPED ou SLEEP à UNINIT [SWS_Can_91010] SWS CANDriver p. 38. Depuis STARTED, il n'y a pas de passage direct vers UNINIT SWS CANDriver p. 38.

Diagramme d'état : cycle de vie d'un contrôleur CAN. Le logiciel et les événements du bus déclenchent des transitions ; seul Can_DeInit ramène à UNINIT depuis STOPPED ou SLEEP. Sources : [SWS_Can_91013], [SWS_Can_91010], SWS CANDriver p. 38, SWS CANDriver p. 34, SWS CANDriver p. 35.

Chaque contrôleur est démarré individuellement avec Can_SetControllerMode(CAN_CS_STARTED) SWS CANDriver p. 29. Le service fonctionne de manière asynchrone : E_OK signifie uniquement que la requête a été acceptée [SWS_Can_00230]. À chaque transition vers STARTED, le contrôleur est réinitialisé, et ce avec la configuration utilisée en dernier par Can_Init ou Can_SetBaudrate SWS CANDriver p. 59. Le matériel peut appliquer le changement avec retard. C'est pourquoi le pilote ne signale l'état atteint qu'ultérieurement via CanIf_ControllerModeIndication ; la surveillance de l'atteinte de la cible est assurée par une couche supérieure SWS CANDriver p. 33. Les transitions de mode interrogées par polling sont détectées par Can_MainFunction_Mode [SWS_Can_00368]. Can_GetControllerMode interroge le mode actuel de manière synchrone [SWS_Can_91014].

Diagramme de séquence : initialisation par EcuM et démarrage asynchrone d'un contrôleur. La notification de succès n'intervient qu'après le polling dans Can_MainFunction_Mode. Sources : [SWS_Can_00230], [SWS_Can_00368], SWS CANInterface p. 156, SWS CANDriver p. 29

Émission via les handles d'émission matériels

CanIf transmet les demandes d'émission avec Can_Write(Hth, PduInfo). Le Hth identifie l'objet d'émission matériel et ainsi également le contrôleur, car les numéros HTH sont uniques au sein d'une unité matérielle [SWS_Can_00233]. Can_HwHandleType couvre par défaut 0..0x0FF et, pour plus de 255 objets matériels, la plage étendue jusqu'à 0xFFFF [SWS_Can_00429]. Can_PduType regroupe les champs swPduHandle, length, id et sdu [SWS_Can_00415].

Dans Can_IdType, les deux bits de poids fort codent le type de trame [SWS_Can_00416] :

00 : CAN avec ID standard
01 : CAN FD avec ID standard
10 : CAN avec ID étendue
11 : CAN FD avec ID étendue

Il est ainsi possible de mélanger des trames CAN 2.0 et CAN FD au niveau des trames, à condition qu'une configuration de débit binaire FD soit active pour le contrôleur SWS CANDriver p. 49 SWS CANInterface p. 71.

Can_Write doit être thread-safe car CanIf_Transmit est réentrant. Le pilote renvoie CAN_BUSY si aucun objet d'émission n'est disponible ou si un appel préemptif ne peut pas être exécuté de manière réentrante [SWS_Can_00039] SWS CANDriver p. 47. CanIf met alors la requête en mémoire tampon. Lorsqu'un objet devient disponible, CanIf appelle à nouveau Can_Write par ordre de priorité SWS CANInterface p. 48. Le pilote conserve le swPduHandle jusqu'au CanIf_TxConfirmation correspondant SWS CANDriver p. 35. Pour parer à l'inversion de priorité, il est possible de configurer statiquement la transmission multiplexée ; plusieurs objets matériels constituent alors un HTH SWS CANDriver p. 40.

Diagramme de séquence : demande d'émission avec les voies E_OK et CAN_BUSY, suivie de la confirmation par interruption ou polling. CanIf peut ensuite injecter une L-PDU mise en mémoire tampon. Sources : [SWS_Can_00233], [SWS_Can_00039], SWS CANInterface p. 142, SWS CANInterface p. 48

Réception et fonctions principales cycliques

Lors de la réception, le pilote appelle CanIf_RxIndication. Il transmet l'ID, l'objet matériel et la ControllerId abstraite de CanIf ainsi que la longueur et le pointeur vers la L-SDU. Pour les trames étendues, il positionne le MSB de l'ID afin que CanIf reconnaisse le type de trame SWS CANDriver p. 43. En amont, un callout de L-PDU configurable <LPDU_CalloutName> est facultativement intercalé [SWS_Can_00443]. S'il renvoie false, la L-PDU n'est pas traitée davantage selon le passage du document (R25-11) SWS CANDriver p. 77.

Les événements sont détectés par interruption ou par polling des drapeaux d'état. Un fonctionnement en polling pur, totalement sans interruption, doit pouvoir être configuré. Lors du polling, les fonctions principales appellent les mêmes rappels, simplement depuis le contexte de la tâche au lieu du contexte d'ISR SWS CANDriver p. 41. Chaque fonction principale scrute un type d'événement :

Can_MainFunction_Write : confirmations TX [SWS_Can_00225]
Can_MainFunction_Read : indications RX [SWS_Can_00226]
Can_MainFunction_BusOff : événements de Bus-off [SWS_Can_00227]
Can_MainFunction_Wakeup : événements de réveil [SWS_Can_00228]
Can_MainFunction_Mode : transitions de mode [SWS_Can_00368]

Les descriptions de Read et Write de R20-11 ne mentionnent que le cas POLLING [SWS_Can_00225] [SWS_Can_00226]. Les passages des documents des versions ultérieures ajoutent MIXED ; seuls les objets avec CanHardwareObjectUsesPolling = TRUE sont alors interrogés par polling SWS CANDriver p. 81 SWS CANDriver p. 79. Les exigences de R20-11 ne corroborent pas cette extension. Si plusieurs périodes sont configurées via CanMainFunctionRWPeriods, les noms de fonction reçoivent le suffixe _<ShortName> [SWS_Can_00441] SWS CANDriver p. 122. En l'absence de tout polling, une fonction principale peut être implémentée sous la forme d'un define vide SWS CANDriver p. 81.

Diagramme de séquence : réception en mode polling avec normalisation de l'ID, callout de L-PDU optionnel et transmission à CanIf. Sources : [SWS_Can_00226], [SWS_Can_00443], SWS CANInterface p. 153, SWS CANDriver p. 43

Veille, réveil et commande des interruptions

Le pilote ne traite que les réveils que le contrôleur détecte lui-même, et non ceux via le transceiver SWS CANDriver p. 45. Lors d'un réveil matériel, le contrôleur passe de SLEEP à STOPPED. La L-PDU déclencheuse n'est pas traitée davantage. EcuM_CheckWakeup est appelée dans l'interruption ou dans Can_MainFunction_Wakeup, avec la source configurée via CanWakeupSourceRef SWS CANDriver p. 35. L'EcuM appelle ensuite Can_CheckWakeup via CanIf. Cette fonction signale un réveil détecté via EcuM_SetWakeupEvent [SWS_Can_00360] SWS CANDriver p. 63. Pour se prémunir contre les réveils intempestifs, EcuM et CanIf procèdent à la validation sans intervention du pilote SWS CANDriver p. 45.

Can_DisableControllerInterrupts et Can_EnableControllerInterrupts sont réentrants et ont un effet imbriqué. Après n appels de désactivation, n appels d'activation sont nécessaires. Une activation sans désactivation préalable reste sans effet [SWS_Can_00231] [SWS_Can_00232] SWS CANDriver p. 61 SWS CANDriver p. 62.

Diagramme de séquence : réveil du bus depuis SLEEP, notification à EcuM et interrogation en retour via CanIf avec Can_CheckWakeup. Sources : [SWS_Can_00360], [SWS_Can_00228], SWS CANDriver p. 45, SWS CANDriver p. 35

Jeux de configuration, partitions et référence d'instance

Can_Init reçoit un pointeur vers Can_ConfigType. Cette structure spécifique au matériel contient des paramètres pour tous les contrôleurs ainsi que des références vers les configurations individuelles des contrôleurs [SWS_Can_00223] [SWS_Can_00413]. Le module prend en charge VARIANT-PRE-COMPILE et VARIANT-POST-BUILD SWS CANDriver p. 96. Dans l'exemple post-build, l'un des multiples jeux de configuration est sélectionné lors de l'appel de Can_Init EXP LayeredSoftwareArchitecture p. 120. Pour chaque contrôleur, CanController définit entre autres CanRxProcessing, CanTxProcessing, CanBusoffProcessing, CanWakeupProcessing et au moins une CanControllerBaudrateConfig SWS CANDriver p. 101.

Dans les systèmes multi-partitions, le module fonctionne dans chaque partition comme une instance indépendante. Un appel d'API n'a d'effet que dans sa propre partition [SWS_Can_CONSTR_00508]. Trois règles s'appliquent à l'affectation des partitions :

Les partitions dans CanControllerEcucPartitionRef doivent constituer un sous-ensemble des partitions dans CanEcucPartitionRef [SWS_Can_CONSTR_00509].
Le contrôleur et le canal d'émetteur-récepteur d'un canal de communication référencent la même partition [SWS_Can_CONSTR_00510].
Le pilote rejette les affectations non prises en charge [SWS_Can_00507].

Plusieurs modules Can dans un même calculateur (ECU) se distinguent par un préfixe de fonction modifié SWS CANDriver p. 51.

Comportement en cas d'erreur

Lorsque la détection des erreurs de développement (Development Error Detection) est activée, le pilote signale les erreurs de développement au DET. Les codes s'étendent de CAN_E_PARAM_POINTER (0x01) à CAN_E_INIT_FAILED (0x09) en passant par CAN_E_UNINIT (0x05) et CAN_E_TRANSITION (0x06) [SWS_Can_91019]. Après le retour du DET, la fonction retourne immédiatement ; les fonctions avec valeur de retour renvoient alors E_NOT_OK SWS CANDriver p. 48. Quelques exemples :

Can_DeInit signale CAN_E_TRANSITION tant qu'un contrôleur est dans l'état STARTED [SWS_Can_91012] SWS CANDriver p. 59.
CAN_E_TRANSITION est prévu pour les transitions non autorisées dans Can_SetControllerMode. Dans le code de production, leur comportement est indéfini SWS CANDriver p. 30 SWS CANDriver p. 32.

En tant qu'erreur d'exécution, CAN_E_DATALOST est défini pour les messages de réception perdus [SWS_Can_91020]. Il devrait être signalé via le Det_ReportRuntimeError requis [SWS_Can_00234]. Question Q-50225b25430c9660 (ouverte)

Si un contrôleur passe en Bus-off, il bascule de STARTED vers STOPPED. Le pilote n'effectue aucune reprise matérielle (hardware recovery). Il signale l'événement par interruption ou dans Can_MainFunction_BusOff via CanIf_ControllerBusOff [SWS_Can_00227] SWS CANDriver p. 35. La reprise est prise en charge par le CanSM, que CanIf informe avec CanSM_ControllerBusOff SWS CANInterface p. 138. Interprétation : le redémarrage devrait à nouveau s'effectuer via Can_SetControllerMode(CAN_CS_STARTED), qui recharge alors la configuration SWS CANDriver p. 59. Question Q-83e484ab9f8b1aac (ouverte)

Diagramme de séquence : détection et notification d'un Bus-off jusqu'au CanSM. Le redémarrage indiqué comme interprétation n'est pas explicitement documenté. Sources : [SWS_Can_00227], [SWS_Can_00234], SWS CANDriver p. 35, SWS CANInterface p. 138

Pour le diagnostic, Can_GetControllerErrorState fournit l'état d'erreur : ACTIVE, PASSIVE ou BUSOFF [SWS_Can_91004] [SWS_Can_91003]. Les compteurs d'erreurs Rx et Tx peuvent également être interrogés. Si le contrôleur ne les met pas à disposition, les fonctions renvoient E_NOT_OK. Comme le matériel gère les compteurs de manière asynchrone, les valeurs ne permettent pas de formuler des hypothèses fiables sur l'état du bus [SWS_Can_00511] [SWS_Can_00516] SWS CANDriver p. 67. Can_ErrorType décrit un sur-ensemble de types d'erreurs matérielles typiques, des erreurs de bits au verrouillage du bus (bus-lock) [SWS_Can_91021].

Pour faire face à un matériel qui ne répond pas, le pilote utilise un OsCounter pour les délais d'attente (timeouts) SWS CANDriver p. 23. Si un changement de mode ne prend pas effet dans CanTimeoutDuration, Can_SetControllerMode quitte la fonction au lieu de bloquer SWS CANDriver p. 33. Si un réveil du bus (bus-wakeup) survient pendant la transition vers le mode sommeil, Can_SetControllerMode(CAN_CS_STOPPED) renvoie E_NOT_OK SWS CANDriver p. 35.

Preuves détaillées supplémentaires

Cycle de vie du pilote : [SWS_Can_00223], [SWS_Can_91002], SWS CANDriver p. 29
États du contrôleur et schéma issu de R20-11 : [SWS_Can_91013], [SWS_Can_91010], SWS CANDriver p. 38
Changement de mode asynchrone et séquence de démarrage : [SWS_Can_00230], SWS CANInterface p. 156
Émission, types de trames et CAN_BUSY : [SWS_Can_00233], [SWS_Can_00416], [SWS_Can_00039]
Fonctions principales et scrutation (polling) : [SWS_Can_00225]–[SWS_Can_00228], [SWS_Can_00368], SWS CANDriver p. 41
Codes d'erreur : [SWS_Can_91019], [SWS_Can_91020] ; partitions : [SWS_Can_00507]

De nombreux passages du document proviennent de R23-11 à R25-11. Les exigences citées sont normatives pour R20-11. Le diagramme d'état SWS CANDriver p. 38 provient directement de R20-11.

Guide généré par IA sur la base des exigences et des passages documentaires fournis dans la charge utile pour R20-11. Les hypothèses sont identifiées comme des interprétations ; la spécification reste la référence faisant foi.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : e265f28291f9 Provenance Questions ouvertes (2)

traduit du guide allemandGénéré par l'IAgemini-3.8-flash-medium · 2026-10-14

Pilote matériel MCAL assurant l'abstraction, le contrôle d'état et le transfert de trames pour les contrôleurs CAN et CAN FD.

Le module pilote matériel Can fournit une abstraction standardisée des contrôleurs CAN et CAN FD pour l'architecture AUTOSAR Classic ([SWS_Can_00234], SWS CANDriver p. 73). Il prend en charge l'émission de L-PDU via [SWS_Can_00233] (Can_Write), la réception filtrée vers CanIf, ainsi que la gestion rigoureuse des états opérationnels des contrôleurs et du réveil matériel ([SWS_Can_00230], [SWS_Can_00360], SWS CANDriver p. 59). Son fonctionnement peut être configuré au choix par interruptions directes ou par scrutation cyclique via des fonctions périodiques dédiées ([SWS_Can_00099], SWS CANDriver p. 41).

Le module Can constitue le pilote de bas niveau de la couche MCAL dans AUTOSAR Classic, assurant l'accès direct aux registres matériels des contrôleurs CAN et CAN FD ([SWS_Can_00234], SWS CANDriver p. 73). Il encapsule la complexité physique des contrôleurs et expose une interface standardisée vers le module CanIf, tout en s'appuyant sur le système d'exploitation Os pour la prévention des blocages de requêtes matérielles ([SWS_Can_00281], SWS CANDriver p. 23).

Le cycle de vie du pilote est scindé entre l'état global du module (CAN_UNINIT et CAN_READY) contrôlé par les services [SWS_Can_00223] (Can_Init) et [SWS_Can_91002] (Can_DeInit), et les états individuels des contrôleurs gérés via [SWS_Can_00230] (Can_SetControllerMode) selon le type [SWS_Can_91013] (Can_ControllerStateType) ([SWS_Can_00103], [SWS_Can_00246], [SWS_Can_91009], SWS CANDriver p. 29, AUTOSAR CP SWS CANDriver p. 32). Chaque contrôleur passe à CAN_CS_STOPPED lors de l'initialisation et doit être démarré distinctement avant d'émettre ou de recevoir des trames sur le réseau ([SWS_Can_00259], [SWS_Can_00384], SWS CANDriver p. 32).

Machine d'états : Transitions opérationnelles d'un contrôleur CAN individuel. Sources : [SWS_Can_91013], [SWS_Can_00230], [SWS_Can_00259], [SWS_Can_00270], [SWS_Can_00020], [SWS_Can_91010], AUTOSAR CP SWS CANDriver p. 32.

L'émission s'effectue via [SWS_Can_00233] (Can_Write) en transmettant la structure [SWS_Can_00415] (Can_PduType) et renvoie CAN_BUSY si aucune boîte aux lettres matérielle n'est disponible ([SWS_Can_00039], SWS CANDriver p. 54). La réception achemine les trames vers CanIf_RxIndication après validation par un callout optionnel [SWS_Can_00443] ([SWS_Can_00444], SWS CANDriver p. 77). Les événements de communication peuvent être gérés sous interruption ou par les fonctions périodiques de scrutation Can_MainFunction_Write et Can_MainFunction_Read ([SWS_Can_00099], [SWS_Can_00225], [SWS_Can_00226], SWS CANDriver p. 41).

Diagramme de séquence : Déroulement complet d'une émission de L-PDU et confirmation asynchrone. Sources : [SWS_Can_00233], [SWS_Can_00039], [SWS_Can_00276], [SWS_Can_00016], SWS CANDriver p. 35.

Le module prend en charge la détection du réveil matériel via [SWS_Can_00360] (Can_CheckWakeup) notifiée à l'EcuM ([SWS_Can_00361], SWS CANDriver p. 63) et signale les pertes de trames sous le code d'exécution CAN_E_DATALOST ([SWS_Can_91020], SWS CANDriver p. 48). En cas de passage en bus-off, le contrôleur bascule immédiatement à l'état CAN_CS_STOPPED et informe l'interface via CanIf_ControllerBusOff ([SWS_Can_00020], SWS CANDriver p. 35).

Rôle architectural et frontières système du pilote CAN

Le module Can fait partie intégrante de la couche d'abstraction des microcontrôleurs (MCAL) de l'architecture AUTOSAR Classic. Situé au niveau matériel le plus bas de la pile de communication, il encapsule les registres spécifiques des contrôleurs CAN présents sur le silicium ou interfacés via des bus périphériques synchrones SWS CANDriver p. 76. Son objectif principal est de masquer les disparités physiques des contrôleurs réseau et de fournir une interface de programmation uniforme et indépendante du matériel à destination directe de l'interface CAN supérieure ([SWS_Can_00234], SWS CANDriver p. 73).

Le pilote ne communique vers les couches supérieures que par l'intermédiaire de fonctions de rappel strictement définies et implémentées par le module CanIf, à l'exception des signalements d'erreurs d'exécution routés vers le module Det ([SWS_Can_00234], SWS CANDriver p. 48). Il utilise également le service GetCounterValue du système d'exploitation Os afin de prévenir tout blocage infini lors de l'attente de réponses matérielles ([SWS_Can_00281], SWS CANDriver p. 23). Pour les contrôleurs externes raccordés via SPI, seuls des appels MCAL synchrones sont autorisés, sans recours à des fonctions de rappel descendantes SWS CANDriver p. 76.

Diagramme de contexte : Frontières architecturales et interactions du module Can avec les couches BSW et le matériel. Sources : [SWS_Can_00234], [SWS_Can_00281], [SWS_Can_00360], SWS CANDriver p. 73.

Cycle de vie et machines d'états du pilote et des contrôleurs

Le cycle de vie du pilote CAN s'articule autour de deux machines d'états orthogonales : l'état global du pilote et les états opérationnels de chaque contrôleur géré. Au niveau global, le pilote ne possède que deux états : CAN_UNINIT et CAN_READY ([SWS_Can_00103], SWS CANDriver p. 29). Après un reset, le pilote se trouve obligatoirement dans l'état CAN_UNINIT. L'appel unique à la fonction synchrone [SWS_Can_00223] (Can_Init) initialise l'ensemble des contrôleurs de l'unité matérielle conformément à leur configuration statique et fait basculer le pilote vers CAN_READY ([SWS_Can_00245], [SWS_Can_00246], AUTOSAR CP SWS CANDriver p. 29). Inversement, la fonction synchrone non réentrante [SWS_Can_91002] (Can_DeInit) replace le module à l'état CAN_UNINIT avant de dé-initialiser les contrôleurs ([SWS_Can_91009], SWS CANDriver p. 59).

Machine d'états : États globaux du pilote CAN (Driver State). Sources : [SWS_Can_00103], [SWS_Can_00246], [SWS_Can_91009], SWS CANDriver p. 29.

Au niveau de chaque contrôleur matériel individuel, les modes opérationnels sont régis par le type énuméré [SWS_Can_91013] (Can_ControllerStateType), comprenant les états CAN_CS_UNINIT, CAN_CS_STOPPED, CAN_CS_STARTED et CAN_CS_SLEEP (AUTOSAR CP SWS CANDriver p. 32). Dès l'achèvement de [SWS_Can_00223], tous les contrôleurs passent obligatoirement de CAN_CS_UNINIT à CAN_CS_STOPPED ([SWS_Can_00259], SWS CANDriver p. 32). Pour participer activement à la communication sur le bus, chaque contrôleur doit être démarré individuellement par la fonction asynchrone [SWS_Can_00230] (Can_SetControllerMode(Controller, CAN_CS_STARTED)), ce qui réinitialise le contrôleur avec sa configuration de débit ([SWS_Can_00384], SWS CANDriver p. 59). La notification de changement d'état effectif vers la couche supérieure est délivrée via le callback obligatoire CanIf_ControllerModeIndication ([SWS_Can_00234], [SWS_Can_00370], SWS CANDriver p. 33). La consultation synchrone de l'état d'un contrôleur est possible à tout moment par l'API [SWS_Can_91014] (Can_GetControllerMode) ([SWS_Can_91015], SWS CANDriver p. 65).

Émission de L-PDU et mécanisme anti-inversion de priorité

L'émission d'une unité de données de protocole de liaison (L-PDU) est déclenchée par la couche supérieure par l'appel de l'API [SWS_Can_00233] (Can_Write). Cette fonction prend en paramètre un identifiant de boîte aux lettres matérielle d'émission [SWS_Can_00429] (Can_HwHandleType Hth) et un pointeur vers une structure [SWS_Can_00415] (Can_PduType) regroupant le handle logiciel swPduHandle, la longueur de charge utile length, l'identifiant [SWS_Can_00416] (Can_IdType id) et le pointeur vers les données sdu (SWS CANDriver p. 53). L'ordre d'émission sur le bus place le premier octet de données à l'indice 0 du tableau et le dernier à l'indice 7 (ou 63 en cas de trame CAN FD) ([SWS_Can_00059], SWS CANDriver p. 35). Les deux bits de poids fort de [SWS_Can_00416] servent à distinguer les identifiants standards, étendus et les trames CAN FD avec ou sans commutation de débit (BRS) SWS CANDriver p. 49.

Si aucune boîte aux lettres matérielle n'est disponible lors de l'appel de Can_Write, la fonction retourne immédiatement le code étendu CAN_BUSY ([SWS_Can_00039], SWS CANDriver p. 54). Dans le cas contraire, Can_Write mémorise en interne l'attribut swPduHandle afin de le restituer lors de la confirmation ultérieure ([SWS_Can_00276], SWS CANDriver p. 35). Lorsque la trame est transmise avec succès sur le bus physique, le pilote notifie l'interface via CanIf_TxConfirmation(swPduHandle) ([SWS_Can_00016], [SWS_Can_00234], SWS CANDriver p. 73).

Afin de prévenir les phénomènes néfastes d'inversion de priorité matérielle interne ou externe, le pilote CAN supporte la transmission multiplexée configurable de manière statique au pre-compile time ([SWS_Can_00277], SWS CANDriver p. 40). Ce mécanisme permet d'associer plusieurs objets matériels d'émission à un unique HTH représentant une entité logique globale ([SWS_Can_00401], SWS CANDriver p. 40). Le pilote exploite alors les fonctionnalités des contrôleurs capables de remplir des tampons libres ou de sélectionner les objets matériels selon l'ordre strict de priorité des identifiants CAN ([SWS_Can_00402], [SWS_Can_00403], SWS CANDriver p. 40).

Diagramme de séquence : Déroulement complet d'une émission de L-PDU et confirmation asynchrone. Sources : [SWS_Can_00233], [SWS_Can_00039], [SWS_Can_00276], [SWS_Can_00016], SWS CANDriver p. 35.

Réception de données, filtrage matériel et fonctions de callout

Lorsqu'une trame est reçue par un objet matériel de réception désigné par un handle HRH ([SWS_Can_00429], SWS CANDriver p. 54), le pilote CAN la prend en charge soit immédiatement dans le contexte d'une routine d'interruption (ISR), soit lors de l'exécution cyclique de sa tâche planifiée [SWS_Can_00226] (Can_MainFunction_Read) ([SWS_Can_00108], SWS CANDriver p. 79). Si la représentation des données dans le tampon matériel diffère du format standardisé d'AUTOSAR, le pilote met à disposition un tampon intermédiaire normalisé pour les couches supérieures ([SWS_Can_00427], SWS CANDriver p. 35).

Le module supporte optionnellement un appel externe configurable pour chaque L-PDU entrante via l'interface [SWS_Can_00443] (<LPDU_CalloutName>) (SWS CANDriver p. 77). Cette fonction reçoit les attributs de la trame reçue (HRH, identifiant CAN, longueur et pointeur de données). Si ce callout retourne la valeur false, le traitement de la trame est immédiatement interrompu et celle-ci est rejetée sans transmission à la couche supérieure ([SWS_Can_00444], SWS CANDriver p. 77). Si la trame est validée, le pilote la délivre à l'interface CAN via l'API obligatoire CanIf_RxIndication ([SWS_Can_00234], SWS CANDriver p. 73). Vraisemblablement, l'invalidation temporaire de l'objet matériel de réception observée lors du traitement en scrutation vise à protéger l'intégrité mémoire face à une réécriture concurrente par le contrôleur SWS CANInterface p. 153.

Diagramme de séquence : Traitement de réception d'une trame L-PDU avec filtrage et callout optionnel. Sources : [SWS_Can_00226], [SWS_Can_00443], [SWS_Can_00444], [SWS_Can_00234], SWS CANInterface p. 153.

Modes d'exécution : gestion des interruptions et ordonnancement périodique

AUTOSAR prévoit une flexibilité totale quant au mode de notification des événements matériels. Le pilote CAN peut fonctionner soit intégralement par interruptions, soit intégralement par scrutation (polling), soit selon un mode mixte où certains objets matériels sont configurés en scrutation ([SWS_Can_00099], [SWS_Can_00007], SWS CANDriver p. 41). Lorsque la scrutation est configurée, les événements matériels sont vérifiés et notifiés dans le contexte d'exécution des fonctions périodiques appelées par le planificateur de tâches BSW (Basic Software Scheduler) (SWS CANDriver p. 41).

Ces fonctions périodiques comprennent [SWS_Can_00225] (Can_MainFunction_Write) pour la confirmation d'émission ([SWS_Can_00031], SWS CANDriver p. 81), [SWS_Can_00226] (Can_MainFunction_Read) pour les indications de réception ([SWS_Can_00108], SWS CANDriver p. 79), [SWS_Can_00227] (Can_MainFunction_BusOff) pour les événements de bus-off ([SWS_Can_00109], SWS CANDriver p. 83), [SWS_Can_00228] (Can_MainFunction_Wakeup) pour le réveil ([SWS_Can_00112], SWS CANDriver p. 80) et [SWS_Can_00368] (Can_MainFunction_Mode) pour les transitions d'états des contrôleurs ([SWS_Can_00369], SWS CANDriver p. 84). Si aucun événement de ce type n'est configuré en mode scrutation, ces fonctions peuvent être générées sous la forme de macros vides ([SWS_Can_00178], [SWS_Can_00180], [SWS_Can_00183], [SWS_Can_00185]). De plus, aucun ordre d'exécution particulier n'est imposé entre ces différentes fonctions périodiques ([SWS_Can_00110], SWS CANDriver p. 78).

Pour la protection des sections critiques matérielles au niveau contrôleur, le pilote met à disposition les fonctions réentrantes [SWS_Can_00231] (Can_DisableControllerInterrupts) et [SWS_Can_00232] (Can_EnableControllerInterrupts) (SWS CANDriver p. 61). Elles implémentent un mécanisme d'imbrication incrémentale : chaque désactivation incrémente un compteur interne et les interruptions ne sont effectivement réactivées au niveau matériel que lorsque le nombre correspondant d'appels à Can_EnableControllerInterrupts a été atteint ([SWS_Can_00049], [SWS_Can_00202], [SWS_Can_00208], SWS CANDriver p. 62).

Surveillance du réveil matériel et synchronisation d'horloge

Le module gère exclusivement les événements de réveil détectables directement par le contrôleur CAN lui-même, et non ceux issus des émetteurs-récepteurs physiques (transceivers) SWS CANDriver p. 45. En cas de réveil détecté par une interruption matérielle, la routine de service appelle EcuM_CheckWakeup avec l'identifiant de la source configurée ([SWS_Can_00364], SWS CANDriver p. 45). En mode scrutation, le gestionnaire d'état de l'ECU sollicite cycliquement l'API synchrone [SWS_Can_00360] (Can_CheckWakeup) qui vérifie l'état matériel et notifie le réveil confirmé via EcuM_SetWakeupEvent ([SWS_Can_00361], SWS CANDriver p. 63). Dès la détection d'un réveil matériel sur le bus, le contrôleur concerné bascule automatiquement de CAN_CS_SLEEP vers CAN_CS_STOPPED ([SWS_Can_00270], [SWS_Can_00271], SWS CANDriver p. 35), tandis que la L-PDU ayant provoqué le réveil n'est pas traitée plus avant ([SWS_Can_00269], SWS CANDriver p. 35).

Pour répondre aux besoins de synchronisation temporelle globale, le pilote CAN supporte l'horodatage des messages (Time Stamping). Il expose des interfaces dédiées pour activer l'horodatage d'émission sur un HTH via Can_EnableEgressTimeStamp (SWS CANDriver p. 69), lire l'horloge locale courante via Can_GetCurrentTime (SWS CANDriver p. 71), et acquérir l'horodatage précis d'émission ou de réception au format Can_TimeStampType respectivement par Can_GetEgressTimeStamp (appelé dans le contexte de confirmation) et Can_GetIngressTimeStamp (appelé dans le contexte d'indication de réception) (SWS CANDriver p. 71, SWS CANDriver p. 75).

Comportement en cas d'erreur et diagnostic matériel

Le module Can applique une gestion stricte des erreurs de développement (DET), des erreurs d'exécution (Runtime Errors) et des défaillances matérielles. En cas d'appel d'API non conforme ou de non-respect de l'ordre d'initialisation, le pilote lève une erreur de développement vers le Det ([SWS_Can_00026], SWS CANDriver p. 48). Lorsque le DET est activé, toute fonction fournissant une valeur de retour renvoie immédiatement E_NOT_OK dès le signalement de l'anomalie ([SWS_Can_00089], [SWS_Can_00091], SWS CANDriver p. 48). Par exemple, appeler [SWS_Can_91002] alors qu'un contrôleur est toujours à l'état CAN_CS_STARTED ou que le pilote n'est pas CAN_READY génère l'erreur CAN_E_TRANSITION ([SWS_Can_91011], [SWS_Can_91012], SWS CANDriver p. 59). De même, un pointeur nul passé à [SWS_Can_00224] (Can_GetVersionInfo) lève CAN_E_PARAM_POINTER ([SWS_Can_00177], SWS CANDriver p. 57).

Sur le plan des erreurs d'exécution, la perte d'une trame reçue suite à un débordement de tampon matériel est notifiée sous le code standardisé CAN_E_DATALOST (0x01) par le service Det_ReportRuntimeError ([SWS_Can_91020], [SWS_Can_00234], SWS CANDriver p. 48). Face aux dysfonctionnements physiques du contrôleur ou à un verrouillage du bus, le pilote utilise le compteur OsCounter via GetCounterValue afin de limiter la durée d'attente à une valeur strictement inférieure à la période de déclenchement des fonctions périodiques ([SWS_Can_00280], [SWS_Can_00281], [SWS_Can_00398], SWS CANDriver p. 23, SWS CANDriver p. 33).

Pour le diagnostic réseau et la surveillance d'intégrité, le pilote fournit des interfaces dédiées pour obtenir l'état d'erreur du contrôleur [SWS_Can_91004] (Can_GetControllerErrorState) qui renvoie l'état [SWS_Can_91003] (CAN_ERRORSTATE_ACTIVE, CAN_ERRORSTATE_PASSIVE ou CAN_ERRORSTATE_BUSOFF) (SWS CANDriver p. 49, SWS CANDriver p. 64). Le type [SWS_Can_91021] (Can_ErrorType) répertorie le sur-ensemble des typologies d'erreurs détectables par le matériel (erreur de bit, d'arbitrage, d'acquittement, de format, de CRC ou bus bloqué) (SWS CANDriver p. 55). Enfin, les compteurs matériels d'erreurs de réception et d'émission peuvent être lus via [SWS_Can_00511] (Can_GetControllerRxErrorCounter) et [SWS_Can_00516] (Can_GetControllerTxErrorCounter) (SWS CANDriver p. 66, SWS CANDriver p. 67). Dès qu'un état de bus-off est atteint, le contrôleur passe à CAN_CS_STOPPED et notifie immédiatement la couche supérieure par CanIf_ControllerBusOff ([SWS_Can_00020], [SWS_Can_00234], SWS CANDriver p. 35).

Références détaillées et traçabilité normative

La configuration du pilote CAN s'effectue via le conteneur principal Can (SWS CANDriver p. 96), qui supporte les variantes post-build et pre-compile sous le type [SWS_Can_00413] (Can_ConfigType). Lorsque des périodes multiples sont définies via CanMainFunctionRWPeriods, le générateur de code décline les fonctions périodiques sous les dénominations individualisées Can_MainFunction_Write_<Period>() et Can_MainFunction_Read_<Period>() pour chaque objet matériel référencé ([SWS_Can_00441], [SWS_Can_00442], SWS CANDriver p. 81, SWS CANDriver p. 122).

Le tableau ci-dessous récapitule les exigences normatives fondamentales régissant les transitions d'états, le traitement des messages et les interfaces indispensables du module Can :

Identifiant Exigence	Élément d'API associé	Rôle fonctionnel et portée normative
[SWS_Can_00223]	`Can_Init`	Initialise tous les contrôleurs de l'unité matérielle et passe le pilote à `CAN_READY` ([SWS_Can_00246]).
[SWS_Can_91002]	`Can_DeInit`	Dé-initialise le pilote et replace l'ensemble des contrôleurs à l'état `CAN_CS_UNINIT` ([SWS_Can_91010]).
[SWS_Can_00230]	`Can_SetControllerMode`	Déclenche les transitions logicielles asynchrones de la machine d'états des contrôleurs ([SWS_Can_00017]).
[SWS_Can_00233]	`Can_Write`	Transmet une trame L-PDU via un HTH ou signale `CAN_BUSY` en cas d'indisponibilité ([SWS_Can_00039]).
[SWS_Can_00234]	Interfaces obligatoires	Définit les rappels vers `CanIf`, le signalement `Det` et la détection de timeout `Os`.

Ce guide de module a été généré de manière automatisée pour AUTOSAR Classic R20-11 et documente les spécifications et interfaces normatives du pilote CAN.

CAN Driver (Can)

The CAN driver provides hardware-dependent access to the internal and external CAN controllers (CAN 2.0B, CAN FD, CAN XL).

Funktionen — Übersicht

void Can_Init (const Can_ConfigType* Config); This function initializes the module.
void Can_GetVersionInfo (Std_VersionInfoType* versioninfo); This function returns the version information of this module.
void Can_DeInit (void); This function de - initializes the module.
Std_ReturnType Can_SetBaudrate (uint8 Controller, uint16 BaudRateConfig ID); ⚠️ This service shall set the baud rate configuration of the CAN controller.
Std_ReturnType Can_SetControllerMode (uint8 Controller, Can_ControllerStateType Transition); This function performs software triggered state transitions of the CAN controller State machine.
void Can_DisableControllerInterrupts (uint8 Controller); This function disables all interrupts for this CAN controller.
void Can_EnableControllerInterrupts (uint8 Controller); This function enables all allowed interrupts.
Std_ReturnType Can_CheckWakeup (uint8 Controller); This function checks if a wakeup has occurred for the given controller.
Std_ReturnType Can_GetControllerErrorState (uint8 ControllerId, Can_ErrorStateType* ErrorStatePtr); This service obtains the error state of the CAN controller.
Std_ReturnType Can_GetControllerMode (uint8 Controller, Can_ControllerStateType* ControllerModePtr); This service reports about the current status of the requested CAN controller.
Std_ReturnType Can_GetControllerRxErrorCounter (uint8 ControllerId, uint8* RxErrorCounterPtr); Returns the Rx error counter for a CAN controller.
Std_ReturnType Can_GetControllerTxErrorCounter (uint8 ControllerId, uint8* TxErrorCounterPtr); Returns the Tx error counter for a CAN controller.
Std_ReturnType Can_Write (Can_HwHandleType Hth, const Can_PduType* PduInfo); This function is called by Can If to pass a CAN message to Can Drv for transmission.
boolean <LPDU_CalloutName> (uint8 Hrh, Can_IdType CanId, uint8 CanDataLegth, const uint8* CanSduPtr); -
void Can_MainFunction_Write (void); This function performs the polling of TX confirmation when CAN_ TX_ PROCESSING is set to POLLING.
void Can_MainFunction_Read (void); This function performs the polling of RX indications when CAN_ RX_ PROCESSING is set to POLLING.
void Can_MainFunction_BusOff (void); This function performs the polling of bus - off events that are configured statically as 'to be polled'.
void Can_MainFunction_Wakeup (void); This function performs the polling of wake - up events that are configured statically as 'to be polled'.
void Can_MainFunction_Mode (void); This function performs the polling of CAN controller mode transitions.

Typen — Übersicht

struct Can_ConfigType This is the type of the external data structure containing the overall initialization data for the CAN driver and SFR settings...
Can_PduType This type unites Pdu Id (sw Pdu Handle), Sdu Length (length), Sdu Data (sdu), and Can Id (id) for any CAN L - SDU.
Can_IdType Represents the Identifier of an L - PDU.
Can_HwHandleType Represents the hardware object handles of a CAN hardware unit.
struct Can_HwType This type defines a data structure which clearly provides an Hardware Object Handle including its corresponding CAN Controller...
enum Can_ErrorStateType Error states of a CAN controller.
enum Can_ControllerStateType States that are used by the several Controller Mode functions.
enum Can_ErrorType The enumeration represents a superset of CAN Error Types which typical CAN HW is able to report.

Funktionen & Typen — Detailansicht

fonction Can_Init [SWS_Can_00223] 📄 PDF

void Can_Init (const Can_ConfigType* Config);

This function initializes the module.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 8afbe47dbadd Provenance

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction synchrone et non réentrante Can_Init initialise l'ensemble du module pilote CAN ainsi que les unités matérielles associées conformément à la configuration transmise [SWS_Can_00223].

Utilisation et contexte d'appel

L'appel de Can_Init est obligatoirement effectué pendant la phase de démarrage du calculateur par l'ECU State Manager, avant même que toute autre fonction du pilote CAN ne puisse être appelée [SWS_Can_91012]. En tant que paramètre, la fonction prend via Config un pointeur vers la configuration du pilote (const Can_ConfigType*) et ne renvoie aucune valeur de retour [SWS_Can_00223].

Périmètre d'initialisation et transitions d'état

Dans le cadre de l'initialisation, la fonction configure tous les registres matériels requis et initialise tous les contrôleurs CAN AUTOSAR_SWS_CANDriver p. 33 :

initialisation des variables statiques et des drapeaux internes [SWS_Can_91012],
configuration des paramètres communs pour l'unité matérielle CAN complète [SWS_Can_91012],
paramètres spécifiques aux contrôleurs pour chaque contrôleur CAN individuel [SWS_Can_91012].

Par l'appel de la fonction, des transitions d'état du matériel CAN sont déclenchées AUTOSAR_SWS_CANDriver p. 10, où Can_Init effectue la configuration des registres afin de faire passer les contrôleurs dans l'état de base prévu [SWS_Can_91010] AUTOSAR_SWS_CANDriver p. 36.

Concurrence et restrictions

Comme Can_Init est spécifiée comme non réentrante, aucun appel parallèle ou répété ne doit avoir lieu pendant une initialisation en cours [SWS_Can_00223]. En outre, certains réglages globaux de l'unité matérielle ne peuvent être définis qu'au sein de Can_Init AUTOSAR_SWS_CANDriver p. 33.

Cette note d'utilisation a été générée de manière automatisée à partir des données de spécification d'AUTOSAR Classic R20-11.

Guide de l'implémenteur à venir (complexité I1)

fonction Can_GetVersionInfo [SWS_Can_00224] 📄 PDF

void Can_GetVersionInfo (Std_VersionInfoType* versioninfo);

This function returns the version information of this module.

fonction Can_DeInit [SWS_Can_91002] 📄 PDF

void Can_DeInit (void);

This function de - initializes the module.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 982976925c7a Provenance Questions ouvertes (2)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction Can_DeInit sert à la désinitialisation du module pilote CAN ([SWS_Can_91002]). Elle possède la signature void Can_DeInit(void), ne prend aucun paramètre, ne renvoie aucune valeur et est exécutée de manière synchrone et non réentrante ([SWS_Can_91002]). L'interface est disponible via l'en-tête Can.h ([SWS_Can_91002]).

L'appel amorce une transition d'état contrôlée par logiciel (AUTOSAR_SWS_CANDriver p. 10 ; AUTOSAR_SWS_CANDriver p. 41). Lors de cette opération, Can_DeInit modifie l'état du module (AUTOSAR_SWS_CANDriver p. 33) et réinitialise tous les contrôleurs CAN (AUTOSAR_SWS_CANDriver p. 41).

Concurrence et restrictions

Pour l'exécution, des préconditions et des exigences de séquencement strictes s'appliquent concernant les états du matériel et du module :

L'appelant doit s'assurer qu'aucun contrôleur CAN ne se trouve dans un état non autorisé (AUTOSAR_SWS_CANDriver p. 61) ; les opérations de communication actives doivent probablement être terminées au préalable. Question Q-311343fa42add3a3 (ouverte)
Si le module CAN ne se trouve pas dans l'état initial requis lors de l'appel (AUTOSAR_SWS_CANDriver p. 41), la fonction signale l'erreur CAN_E_TRANSITION (AUTOSAR_SWS_CANDriver p. 61).
De même, l'erreur CAN_E_TRANSITION est déclenchée si un contrôleur CAN demeure dans un état empêchant la désinitialisation (AUTOSAR_SWS_CANDriver p. 61). Interprétation : le pilote devrait présupposer un état arrêté de tous les contrôleurs avant la transition. Question Q-435095949dafba5c (ouverte)

Interaction

Le comportement en matière d'erreur et de transition reflète les flux assainis du pilote, selon lesquels les transitions d'état non valides sont interceptées de manière uniforme ([SWS_Can_00441]).

Ce texte a été généré par une IA sur la base de la spécification AUTOSAR CP R20-11.

fonction Can_SetBaudrate [SWS_CAN_00491] 📄 PDF

Std_ReturnType Can_SetBaudrate (uint8 Controller, uint16 BaudRateConfig ID); ⚠️

This service shall set the baud rate configuration of the CAN controller. Depending on necessary baud rate modifications the controller might have to reset.

fonction Can_SetControllerMode [SWS_Can_00230] 📄 PDF

Std_ReturnType Can_SetControllerMode (uint8 Controller, Can_ControllerStateType Transition);

This function performs software triggered state transitions of the CAN controller State machine.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : a4b356b48b8a Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction Can_SetControllerMode (mise à disposition via Can.h avec le Service-ID 0x03) effectue des transitions d'état déclenchées par logiciel de la machine à états du contrôleur CAN ([SWS_Can_00230], AUTOSAR_SWS_CANDriver p. 35). Elle procède aux réglages de registres liés au matériel afin d'amener les transitions entre les états de base du contrôleur UNINIT, STOPPED, STARTED et SLEEP ([SWS_Can_91010], AUTOSAR_SWS_CANDriver §7.3 « CAN Controller State Machine »).

Utilisation et sémantique

L'appel s'effectue avec le paramètre Controller pour identifier le contrôleur CAN ainsi que Transition de type Can_ControllerStateType pour spécifier la transition d'état souhaitée ([SWS_Can_00230]). Le service est défini comme asynchrone et non réentrant (Non Reentrant) ([SWS_Can_00230]). Une valeur de retour de E_OK confirme que la demande a été acceptée ; E_NOT_OK indique que la demande a été rejetée et qu'une erreur de développement est présente ([SWS_Can_00230], [SWS_Can_00441]).

Déroulement et interaction

Après avoir appliqué la configuration des registres, Can_SetControllerMode se termine (AUTOSAR_SWS_CANDriver p. 38). Comme le module Can ne mémorise pas lui-même les changements d'état du matériel ([SWS_Can_91010]), la fonction cyclique Can_Mainfunction_Mode prend probablement en charge l'achèvement asynchrone ou la vérification de la transition amorcée par Can_SetControllerMode (AUTOSAR_SWS_CANDriver p. 38). Question Q-03edb1b665a1624b (ouverte)

Ce texte a été généré par une IA sur la base des données de spécification d'AUTOSAR R20-11.

Guide de l'implémenteur à venir (complexité I1)

fonction Can_DisableControllerInterrupts [SWS_Can_00231] 📄 PDF

void Can_DisableControllerInterrupts (uint8 Controller);

This function disables all interrupts for this CAN controller.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 9d72b1d46d5d Provenance Questions ouvertes (2)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction synchrone et réentrante Can_DisableControllerInterrupts désactive toutes les interruptions pour un contrôleur CAN spécifié ([SWS_Can_00231]). La transmission s'effectue via le paramètre Controller sans valeur de retour ([SWS_Can_00231]).

En ce qui concerne le contexte d'appel et la concurrence, la fonction est conçue pour être réentrante et prend en charge des appels multiples (AUTOSAR_SWS_CANDriver §8.3 « Can_DisableControllerInterrupts »). Interprétation : un appel multiple devrait incrémenter un compteur d'imbrication interne, de sorte que les interruptions ne soient réactivées qu'après un nombre correspondant d'appels d'activation (AUTOSAR_SWS_CANDriver §8.3 « Can_DisableControllerInterrupts », AUTOSAR_SWS_CANDriver §8.3 « Can_DisableControllerInterrupts »). Question Q-61be56207aa92ee0 (ouverte)

Dans le domaine du traitement des erreurs, la spécification exige le déclenchement de l'erreur CAN_E_UNINIT si le module pilote n'est pas encore initialisé lors de l'appel (AUTOSAR_SWS_CANDriver §8.3 « Can_DisableControllerInterrupts »). De plus, la spécification exige le déclenchement d'une autre erreur (AUTOSAR_SWS_CANDriver §8.3 « Can_DisableControllerInterrupts ») ; ceci sert probablement à la vérification d'un identifiant de contrôleur non valide. Question (ouverte)

Dans l'interaction au sein du pilote CAN, l'appel sert à sécuriser les sections critiques associées au contrôleur pendant que celui-ci reste actif (AUTOSAR_SWS_CANDriver §7.5 « Interrupt handling »). Les assainissements formels et les modifications historiques de l'interface du pilote sont documentés dans les notes de version ([SWS_Can_00441]).

Ce texte a été créé par une IA et sert de note d'utilisation complémentaire à la spécification.

fonction Can_EnableControllerInterrupts [SWS_Can_00232] 📄 PDF

void Can_EnableControllerInterrupts (uint8 Controller);

This function enables all allowed interrupts.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 374e141963cb Provenance Questions ouvertes (2)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction synchrone et réentrante Can_EnableControllerInterrupts réactive toutes les interruptions autorisées pour le contrôleur CAN indiqué via le paramètre Controller ([SWS_Can_00232]). Elle ne possède pas de valeur de retour et est mise à disposition via le fichier d'en-tête Can.h ([SWS_Can_00232]).

Concernant le déroulement, la fonction lit des drapeaux de contrôle logiciels (AUTOSAR_SWS_CANDriver p. 65). Si les interruptions du contrôleur ont été désactivées plusieurs fois auparavant, Can_EnableControllerInterrupts doit être appelée tout autant de fois avant l'activation effective (AUTOSAR_SWS_CANDriver p. 65). Interprétation : le pilote gère probablement les sections de verrouillage imbriquées au moyen de compteurs ou de drapeaux internes, de sorte que les interruptions matérielles ne soient réactivées qu'après compensation complète de tous les appels de désactivation. Question Q-6781f0fc9ad7d221 (ouverte)

Si la fonction est appelée avant que le pilote CAN n'ait été correctement initialisé, elle signale l'erreur CAN_E_UNINIT (AUTOSAR_SWS_CANDriver p. 66). Cela devrait être traité comme une Development Error dans le contexte du pilote ([SWS_Can_00441]). Question Q-efbbcf03a2589e4e (ouverte) À l'état non initialisé, la fonction n'effectue aucune action supplémentaire sur le contrôleur (AUTOSAR_SWS_CANDriver p. 66).

Cette note d'utilisation a été générée automatiquement sur la base de la spécification.

fonction Can_CheckWakeup [SWS_Can_00360] 📄 PDF

Std_ReturnType Can_CheckWakeup (uint8 Controller);

This function checks if a wakeup has occurred for the given controller.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 720a4fc64f2a Provenance

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Utilisation et comportement

La fonction synchrone Can_CheckWakeup vérifie pour un contrôleur CAN donné si un événement de réveil a été détecté ([SWS_Can_00360], AUTOSAR_SWS_CANDriver p. 48, AUTOSAR_SWS_CANDriver p. 67). Elle est disponible via le fichier d'en-tête Can.h et possède le Service-ID 0x0b ([SWS_Can_00360]).

Paramètre : Controller (in) désigne l'identifiant du contrôleur CAN dont l'état doit être vérifié quant à un réveil ([SWS_Can_00360]).
Valeur de retour : renvoie Std_ReturnType. La valeur de retour E_OK signale que l'appel d'API a été accepté, tandis que E_NOT_OK indique le rejet ([SWS_Can_00360]).
Concurrence : la fonction est définie comme non réentrante (Non Reentrant) ([SWS_Can_00360]).

Configuration et traitement des erreurs

La disponibilité de la fonction est configurable au moment de la précompilation ; le service Can_CheckWakeup peut ainsi être intégré dans le code ou en être retiré (AUTOSAR_SWS_CANDriver p. 67, AUTOSAR_SWS_CANDriver p. 97). Si la fonction est appelée avant que le pilote CAN n'ait été initialisé, elle signale l'erreur CAN_E_UNINIT (AUTOSAR_SWS_CANDriver p. 67).

Interaction

L'appel de Can_CheckWakeup est généralement déclenché par l'interface CAN (AUTOSAR_SWS_CANDriver p. 48). En cas d'événement de réveil sur le bus, CanIf_CheckWakeup peut être appelée pendant l'exécution de EcuM_CheckWakeup (AUTOSAR_SWS_CANInterface §7.18.4.1 « Wake-up detection »). Conformément à [SWS_CANIF_00395], CanIf demande ici via Can_CheckWakeup() ou CanTrcv_CheckWakeup() quel composant matériel concret a déclenché le réveil du bus (AUTOSAR_SWS_CANInterface p. 55).

Cette note d'utilisation a été créée de manière automatisée et se base exclusivement sur les spécifications de la version AUTOSAR R20-11.

fonction Can_GetControllerErrorState [SWS_Can_91004] 📄 PDF

Std_ReturnType Can_GetControllerErrorState (uint8 ControllerId, Can_ErrorStateType* ErrorStatePtr);

This service obtains the error state of the CAN controller.

fonction Can_GetControllerMode [SWS_Can_91014] 📄 PDF

Std_ReturnType Can_GetControllerMode (uint8 Controller, Can_ControllerStateType* ControllerModePtr);

This service reports about the current status of the requested CAN controller.

fonction Can_GetControllerRxErrorCounter [SWS_Can_00511] 📄 PDF

Std_ReturnType Can_GetControllerRxErrorCounter (uint8 ControllerId, uint8* RxErrorCounterPtr);

Returns the Rx error counter for a CAN controller. This value might not be available for all CAN controllers, in which cas e E_ NOT_ OK would be returned. Please note that the value of the counter might not be correct at the moment the API returns it, because the Rx counter is handled asynchronously in hardware. Applications should not trust this value for any assumption about the current bus state.

fonction Can_GetControllerTxErrorCounter [SWS_Can_00516] 📄 PDF

Std_ReturnType Can_GetControllerTxErrorCounter (uint8 ControllerId, uint8* TxErrorCounterPtr);

Returns the Tx error counter for a CAN controller. This value might not be available for all CAN controllers, in which case E_ NOT_ OK would be returned. Please note that the value of the counter might not be correct at the moment the API returns it, because the Tx counter is handled asynchronously in hardware. Applications should not trust this value for any assumption about the current bus state.

fonction Can_Write [SWS_Can_00233] 📄 PDF

Std_ReturnType Can_Write (Can_HwHandleType Hth, const Can_PduType* PduInfo);

This function is called by Can If to pass a CAN message to Can Drv for transmission.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : f2d4ad3f2f32 Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Utilisation et sémantique

La fonction Can_Write est appelée de manière synchrone par le module CanIf pour transmettre un message CAN au pilote CAN (CanDrv) en vue de son émission ([SWS_Can_00233]). L'appelant transmet alors deux paramètres :

Hth : handle d'émission matériel, qui définit l'objet d'émission à utiliser et détermine implicitement le contrôleur, car les numéros de handle sont uniques au sein d'une unité matérielle ([SWS_Can_00233]).
PduInfo : pointeur vers une structure contenant les données utiles SDU, la longueur des données et l'identifiant CAN ([SWS_Can_00233]).

Avant l'envoi, la fonction vérifie l'objet d'émission matériel adressé (SWS_CANDriver p. 73) et sécurise le swPduHandle transmis (SWS_CANDriver p. 43). Via la valeur de retour de type Std_ReturnType (SRS_BSWGeneral §5.2.3.6 « Types and keywords »), E_OK signale l'acceptation de l'ordre, tandis que CAN_BUSY indique qu'aucun tampon d'émission matériel n'est disponible ([SWS_Can_00233], SWS_CANDriver p. 51).

Gestion des erreurs

Si une erreur de développement survient pendant l'exécution, la fonction renvoie E_NOT_OK ([SWS_Can_00233], [SWS_Can_00441]). Interprétation : les codes d'erreur DET spécifiques ne sont pas explicitement nommés dans l'extrait disponible ; des handles erronés ou des pointeurs non valides devraient toutefois conduire au renvoi de E_NOT_OK. Question Q-ca947a7e0e4fd7d6 (ouverte)

Concurrence et restrictions

Can_Write est spécifiée comme réentrante ou thread-safe ([SWS_Can_00233], SWS_CANDriver p. 49). Si un appel préemptif ne peut pas être exécuté de manière réentrante côté pilote, cela est également signalé à CanIf via la valeur de retour CAN_BUSY ([SWS_Can_00233]). L'appelant doit garantir que la mémoire de la PDU reste valide et inchangée jusqu'au retour de l'appel de fonction (SWS_CANDriver p. 45).

Interaction

Le type de PDU dont il s'agit est transmis lors de l'appel via [SWS_Can_00416] (SWS_CANDriver p. 51), le pilote prenant en charge la transmission jusqu'à la longueur maximale de PDU (SWS_CANDriver p. 52).

Cette note d'utilisation a été générée de manière automatisée sur la base des documents de spécification d'AUTOSAR R20-11.

fonction <LPDU_CalloutName> [SWS_Can_00443] 📄 PDF

boolean <LPDU_CalloutName> (uint8 Hrh, Can_IdType CanId, uint8 CanDataLegth, const uint8* CanSduPtr);

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 3538baa0cf7b Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Utilisation et contexte d'appel

L'interface de call-out configurable <LPDU_CalloutName> est appelée facultativement par le module CAN AUTOSAR à chaque réception d'une L-PDU (SWS_CANDriver §8.4.1 « Call-out function »). La déclaration de la fonction est fournie via le fichier d'en-tête Can_Externals.h ([SWS_Can_00443]). Le nom effectif de la fonction est configuré de manière spécifique au projet ([SWS_Can_00443]).

Le descripteur de réception matérielle (hardware receive handle) Hrh, l'identifiant CanId, la longueur des données CanDataLegth ainsi qu'un pointeur vers les données utiles CanSduPtr sont transmis comme paramètres d'entrée ([SWS_Can_00443]).

Filtrage et valeur de retour

La fonction renvoie une valeur boolean. Si le call-out renvoie false, la L-PDU reçue ne doit pas être traitée plus avant ([SWS_Can_00444]). Interprétation : si l'appel renvoie true, le transfert régulier de la L-PDU vers les couches supérieures devrait avoir lieu. Question Q-e96e75e93881c3af (ouverte)

Concurrence et restrictions

La fonction est pourvue de l'identifiant de service 0x20 et est spécifiée comme asynchrone (Asynchronous) et non réentrante (Non Reentrant) ([SWS_Can_00443]). N'étant pas réentrante, les appels parallèles dans le même contexte ne sont pas autorisés.

Ce texte a été généré par une IA et sert de guide d'orientation. Les exigences de la spécification AUTOSAR font foi.

fonction Can_MainFunction_Write [SWS_Can_00225] 📄 PDF

void Can_MainFunction_Write (void);

This function performs the polling of TX confirmation when CAN_ TX_ PROCESSING is set to POLLING.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : a6cd22a9e2b1 Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction Can_MainFunction_Write effectue l'interrogation cyclique (polling) des confirmations d'émission (TX-Confirmation) pour autant que le paramètre CAN_TX_PROCESSING soit configuré sur POLLING [SWS_Can_00225], AUTOSAR SWS CAN Driver §7 « Scheduled functions ». Elle est sans paramètre (void Can_MainFunction_Write(void)), possède le Service-ID 0x01 et est mise à disposition pour le planificateur via le fichier d'en-tête SchM_Can.h [SWS_Can_00225]. Des commutateurs de configuration permettent d'activer ou de désactiver la fonction pour le traitement de la transmission de PDU AUTOSAR SWS CAN Driver §10 « CanMainFunctionWrite ».

Si aucune interrogation (polling) n'est utilisée dans le système pour les opérations d'émission, Can_MainFunction_Write doit être implémentée sous forme de define vide selon la spécification AUTOSAR SWS CAN Driver §7 « Scheduled functions ». Cela devrait éviter une surcharge inutile du planificateur dans les systèmes purement pilotés par interruptions. Question Q-2152a35397130945 (ouverte)

En interaction avec Can_MainFunction_Read et Can_MainFunction_BusOff, la routine constitue l'interface cyclique du pilote avec la SchM AUTOSAR SWS CAN Driver §7 « Scheduled functions ». Le traitement des confirmations se déroule, selon le mode, directement au niveau de la ressource matérielle ou dans le contexte de Can_MainFunction_Write AUTOSAR SWS CAN Driver §7 « Hardware Resources ». L'appel concret et l'affectation dépendent des éléments respectivement référencés AUTOSAR SWS CAN Driver §10 « CanMainFunctionWrite », AUTOSAR SWS CAN Driver §10 « Call Context », assistés par un traitement Tx associé au contrôleur [SWS_Can_00441].

Cette note d'utilisation a été générée de manière automatisée sur la base de la spécification AUTOSAR R20-11.

fonction Can_MainFunction_Read [SWS_Can_00226] 📄 PDF

void Can_MainFunction_Read (void);

This function performs the polling of RX indications when CAN_ RX_ PROCESSING is set to POLLING.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 2c7a6a6247b4 Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction Can_MainFunction_Read sert à l'interrogation cyclique (polling) des messages de réception CAN ([SWS_Can_00226]). Elle possède la signature void Can_MainFunction_Read (void) avec le Service-ID 0x08 et est mise à disposition pour le contrôle d'exécution via le fichier d'en-tête SchM_Can.h ([SWS_Can_00226]).

Utilisation et configuration

La fonction effectue l'interrogation (polling) des indications RX lorsque le paramètre de configuration CAN_RX_PROCESSING est réglé sur POLLING ([SWS_Can_00226]). Dans le système, ce traitement peut être configuré par contrôleur ([SWS_Can_00441]). Si aucun polling n'est utilisé dans le pilote CAN, Can_MainFunction_Read peut être définie comme une macro vide (AUTOSAR_SWS_CANDriver p. 77).

Concurrence et restrictions

L'appel est effectué périodiquement dans le contexte du planificateur conformément à la période de déclenchement paramétrée (AUTOSAR_SWS_CANDriver p. 22). Des conditions strictes s'appliquent à l'exécution :

La fonction ne doit pas être interrompue par elle-même (AUTOSAR_SWS_CANDriver p. 47).
De manière générale, les fonctions principales CAN telles que Can_MainFunction_Read ne doivent pas être interrompues (AUTOSAR_SWS_CANDriver p. 49) afin de garantir un accès cohérent aux ressources du pilote et du matériel en mode polling (AUTOSAR_SWS_CANDriver p. 46).

Interprétation : l'intervalle d'appel configuré de la tâche devrait devoir être dimensionné de sorte qu'une phase de traitement soit toujours terminée avant le début du cycle suivant, car la réentrance n'est pas autorisée (AUTOSAR_SWS_CANDriver p. 47). Question Q-1f2fa9db14970b12 (ouverte)

Ce texte a été généré par une IA sur la base de la spécification AUTOSAR R20-11.

fonction Can_MainFunction_BusOff [SWS_Can_00227] 📄 PDF

void Can_MainFunction_BusOff (void);

This function performs the polling of bus - off events that are configured statically as 'to be polled'.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : d6a62aee0c17 Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction principale planifiée Can_MainFunction_BusOff sert à l'interrogation cyclique (polling) des événements de Bus-Off des contrôleurs CAN, pour autant que ceux-ci soient statiquement configurés comme devant être scrutés [SWS_Can_00227], [SWS_Can_00109]. Elle possède la signature void Can_MainFunction_BusOff(void), ne prend aucun paramètre, ne renvoie aucune valeur et est mise à disposition pour le contrôle d'exécution via l'en-tête SchM_Can.h [SWS_Can_00227].

Utilisation et interaction

Les événements matériels peuvent être captés dans le pilote CAN soit par interruption, soit par scrutation (polling) des drapeaux d'état correspondants, la configuration de l'interrogation étant dépendante du matériel [SWS_Can_00099]. Le pilote peut également être configuré de manière à renoncer complètement aux interruptions [SWS_Can_00007]. Si aucune scrutation n'est utilisée à l'échelle du système, le module Can est autorisé à implémenter la fonction sous forme de macro vide [SWS_Can_00183].

Si un événement de Bus-Off est détecté via des bits d'état dans Can_MainFunction_BusOff, le module procède aux réglages de registres nécessaires – par exemple pour éviter une reprise matérielle automatique SWS_CANDriver §7.3 « CAN Controller State Machine », [SWS_Can_91010]. Ensuite, le module notifie la couche supérieure CanIf via le rappel correspondant, au sein duquel s'effectue le changement d'état logiciel du contrôleur SWS_CANDriver §7.3 « CAN Controller State Machine ».

Contexte d'appel et restrictions

En mode scruté (polling), le contexte d'appel de la notification par callback n'est pas l'ISR, mais la tâche exécutante de Can_MainFunction_BusOff ; néanmoins, toutes les fonctions de rappel doivent être implémentées comme si elles étaient appelées depuis le contexte ISR SWS_CANDriver §7.9 « Notification concept ». Concernant la réentrance, le payload ne contient aucune indication explicite ; la fonction est probablement non réentrante car elle accède à des registres et états globaux du contrôleur. Question Q-38fcd72c40ce3e66 (ouverte)

Cette note d'utilisation a été générée par une IA et se base exclusivement sur les extraits de spécification de la version AUTOSAR R20-11.

fonction Can_MainFunction_Wakeup [SWS_Can_00228] 📄 PDF

void Can_MainFunction_Wakeup (void);

This function performs the polling of wake - up events that are configured statically as 'to be polled'.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : ce643213c50c Provenance

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

La fonction principale Can_MainFunction_Wakeup effectue l'interrogation cyclique (polling) des événements de réveil statiquement configurés comme devant être scrutés ([SWS_Can_00228]). La fonction possède la signature void Can_MainFunction_Wakeup(void), ne prend aucun paramètre, ne renvoie aucune valeur et est mise à disposition pour le Schedule Manager via l'en-tête SchM_Can.h (AUTOSAR_SWS_CANDriver p. 79). La période d'exécution de la fonction est configurée en secondes (AUTOSAR_SWS_CANDriver p. 92).

Dans le cadre de la machine à états du contrôleur CAN (SWS_CANDriver §7.3 « CAN Controller State Machine »), des événements de réveil matériel externes peuvent être signalés, au lieu d'interruptions, par un bit d'état interrogé dans Can_MainFunction_Wakeup ([SWS_Can_91010]). De plus, lors des transitions d'état, la fonction scrute un drapeau correspondant du registre d'état CAN jusqu'à ce que celui-ci signale l'effectivité du changement ([SWS_Can_00370]). Une fois le changement d'état réussi, le pilote CAN signale le nouvel état à l'interface CAN à l'aide de la fonction de rappel CanIf_ControllerModeIndication, en référence à l'abstrait CanIf ControllerId ([SWS_Can_00370]).

Concernant la configuration et l'utilisation des ressources, l'API Can_MainFunction_Wakeup() peut être activée ou désactivée pour la gestion des événements de réveil (AUTOSAR_SWS_CANDriver p. 97). Si aucun polling n'est utilisé dans le calculateur pour les événements de réveil, Can_MainFunction_Wakeup peut être définie sous la forme d'une macro vide (AUTOSAR_SWS_CANDriver p. 79).

Cette note d'utilisation a été générée de manière automatisée sur la base de la spécification AUTOSAR CP R20-11.

fonction Can_MainFunction_Mode [SWS_Can_00368] 📄 PDF

void Can_MainFunction_Mode (void);

This function performs the polling of CAN controller mode transitions.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : feee99301166 Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Utilisation et fonctionnement

La fonction principale planifiée Can_MainFunction_Mode ([SWS_Can_00368]) effectue la scrutation (polling) des transitions d'état des contrôleurs CAN. Elle ne possède ni paramètres de transmission ni valeur de retour (void Can_MainFunction_Mode(void), Service-ID 0x0c) et est déclarée via l'en-tête SchM_Can.h SWS_CANDriver §8.5.1.5 « Can_MainFunction_Mode ».

La fonction est appelée cycliquement en continu (AUTOSAR_SWS_CANInterface p. 143). Elle vérifie sur le matériel si le mode d'un contrôleur CAN a changé. En cas de changement détecté, l'interface CAN est notifiée via l'appel de CanIf_ControllerModeIndication(Controller, ControllerMode).

Surveillance de mode asynchrone

Si une modification de mode a été préalablement demandée via Can_SetControllerMode() et que cet appel revient avec succès à CanIf, Can_MainFunction_Mode détecte la transition d'état accomplie du matériel du contrôleur. Elle informe ensuite CanIf de manière asynchrone au moyen de CanIf_ControllerModeIndication du nouvel état, tel que CAN_CS_STARTED AUTOSAR_SWS_CANInterface p. 144.

Contexte d'appel et conditions limites

En raison de sa mise à disposition via SchM_Can.h et de sa définition en tant que Scheduled Function, l'appel périodique devrait être effectué par le planificateur BSW. Question Q-42edbc2aa591e8d7 (ouverte) Aucun code d'erreur spécifique ni étape de développement n'est défini dans le payload pour cette fonction.

Ce texte a été créé par une IA sur la base des spécifications AUTOSAR.

Guide de l'implémenteur à venir (complexité I1)

type Can_ConfigType [SWS_Can_00413] 📄 PDF

This is the type of the external data structure containing the overall initialization data for the CAN driver and SFR settings affecting all controllers. Furthermore it contains pointers to controller configuration structures. The contents of the initializ ation data structure are CAN hardware specific.

type Can_PduType [SWS_Can_00415] 📄 PDF

This type unites Pdu Id (sw Pdu Handle), Sdu Length (length), Sdu Data (sdu), and Can Id (id) for any CAN L - SDU.

type Can_IdType [SWS_Can_00416] 📄 PDF

Represents the Identifier of an L - PDU. The two most significant bits specify the frame type: 00 CAN message with Standard CAN ID 01 CAN FD frame with Standard CAN ID 10 CAN message with Extended CAN ID 11 CAN FD frame with Extended CAN ID

type Can_HwHandleType [SWS_Can_00429] 📄 PDF

Represents the hardware object handles of a CAN hardware unit. For CAN hardware units with more than 255 HW objects use extended range.

type Can_HwType [SWS_CAN_00496] 📄 PDF

This type defines a data structure which clearly provides an Hardware Object Handle including its corresponding CAN Controller and therefore Can Drv as well as the specific Can Id.

type Can_ErrorStateType [SWS_Can_91003] 📄 PDF

Error states of a CAN controller.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 0cb922d28e06 Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Le type énuméré Can_ErrorStateType issu de Can_GeneralTypes.h décrit les états d’erreur et de fonctionnement d’un contrôleur CAN [SWS_Can_91003]. Il modélise le comportement du contrôleur sur le bus CAN à travers trois états SWS_CANDriver §8.2.7 « Can_ErrorStateType » :

CAN_ERRORSTATE_ACTIVE : le contrôleur CAN participe pleinement à la communication sur le bus [SWS_Can_91003].
CAN_ERRORSTATE_PASSIVE : le contrôleur CAN participe à la communication, mais n’émet plus de trames d’erreur actives (Error Frames) [SWS_Can_91003].
CAN_ERRORSTATE_BUSOFF : le contrôleur CAN est isolé du bus à la suite d’erreurs de transmission critiques et ne participe plus à la communication [SWS_Can_91003].

À l’exécution, l’état est interrogé via le service de pilote synchrone Can_GetControllerErrorState [SWS_Can_91004]. Son paramètre de sortie ErrorStatePtr reçoit la valeur déterminée. La même signature est également utilisée par la fonction de niveau supérieur CanIf_GetControllerErrorState dans l’interface CAN AUTOSAR_SWS_CANInterface p. 78 « CanIf_GetControllerErrorState ». En ce qui concerne la concurrence, Can_GetControllerErrorState est spécifié comme non réentrant pour un même ControllerId [SWS_Can_91004].

En cas d’erreur, Can_GetControllerErrorState fournit la valeur de retour E_NOT_OK, et E_OK en cas d’interrogation réussie [SWS_Can_91004]. Si la détection des erreurs de développement (DET) est activée, un appel avant l’initialisation du pilote entraîne l’erreur CAN_E_UNINIT [SWS_Can_91005]. Un ControllerId non valide déclenche l’erreur de développement CAN_E_PARAM_CONTROLLER [SWS_Can_91006], et le passage d’un pointeur nul pour ErrorStatePtr est rejeté avec une erreur de développement [SWS_Can_91007].

Interprétation : l’appelant devrait devoir allouer la zone mémoire pour ErrorStatePtr sous sa propre responsabilité, car l’interface traite le pointeur comme un pur paramètre de sortie et exclut les pointeurs nuls par le biais d’une erreur de développement. Question Q-5c907c21bcb50893 (ouverte)

Ce texte a été généré par une IA sur la base de la spécification AUTOSAR R20-11.

Guide de l'implémenteur à venir (complexité I1)

type Can_ControllerStateType [SWS_Can_91013] 📄 PDF

States that are used by the several Controller Mode functions.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : 5eb69ce0444e Provenance

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Le type énuméré Can_ControllerStateType définit les états de fonctionnement fondamentaux d’un contrôleur CAN : CAN_CS_UNINIT, CAN_CS_STARTED, CAN_CS_STOPPED et CAN_CS_SLEEP [SWS_Can_91013]. Ce type est utilisé de manière intermodulaire pour la gestion logicielle des états de la machine à états du contrôleur CAN [SWS_Can_00017].

Les valeurs sont utilisées dans les contextes suivants :

Demande d’état : dans Can_SetControllerMode, le type sert de valeur de transition (paramètre Transition) pour la demande asynchrone d’un nouvel état de fonctionnement [SWS_Can_00230] ; CanIf_SetControllerMode existe en correspondance AUTOSAR_SWS_CANInterface §- « CanIf_SetControllerMode ». Le pilote transmet la demande au matériel du contrôleur, le changement d’état effectif prenant effet immédiatement ou après quelques millisecondes AUTOSAR_SWS_CANInterface §- « Can_SetControllerMode ». Une transition vers CAN_CS_STARTED déclenche en outre une réinitialisation du contrôleur [SWS_Can_00384].
Interrogation d’état : via Can_GetControllerMode, l’état actuel peut être interrogé de manière synchrone par l’intermédiaire du pointeur de sortie ControllerModePtr [SWS_Can_91014], [SWS_Can_91015] (de manière analogue dans CanIf_GetControllerMode AUTOSAR_SWS_CANInterface §- « CanIf_GetControllerMode »).
Indication d’état : une fois le changement effectué, des rappels tels que CanSM_ControllerModeIndication [SWS_CanSM_00396], CanIf_ControllerModeIndication AUTOSAR_SWS_CANInterface §- « CanIf_ControllerModeIndication » ainsi que des rappels utilisateur AUTOSAR_SWS_CANInterface §- « User_ControllerModeIndication » notifient de manière synchrone les couches supérieures du nouveau mode du contrôleur.

Concernant la concurrence et le traitement des erreurs : les fonctions de pilote Can_SetControllerMode et Can_GetControllerMode sont non réentrantes [SWS_Can_00230], [SWS_Can_91014]. En cas d’appel de Can_GetControllerMode avant l’initialisation du pilote, l’erreur de développement CAN_E_UNINIT est signalée et E_NOT_OK est renvoyé [SWS_Can_91016]. La fonction de rappel CanSM_ControllerModeIndication est réentrante pour différents contrôleurs et signale un identifiant de contrôleur non configuré avec CANSM_E_PARAM_CONTROLLER au DET [SWS_CanSM_00396], [SWS_CanSM_00397].

Cette note d’utilisation est basée sur les dispositions des spécifications du pilote CAN, de l’interface CAN et du gestionnaire d’état CAN dans AUTOSAR Classic R20-11.

Guide de l'implémenteur à venir (complexité I1)

type Can_ErrorType [SWS_Can_91021] 📄 PDF

The enumeration represents a superset of CAN Error Types which typical CAN HW is able to report. That means not all CAN HW will be able to support the complete set.

GÉNÉRÉ PAR IA non vérifié Modèle : gemini-3.8-flash-medium · Effort : medium · Température : non réglable · Prompt : e538be0a65be Provenance Questions ouvertes (1)

traduit du guide allemandgemini-3.8-flash-low · 2026-10-13 · Original allemand

Le type d'énumération Can_ErrorType définit un sur-ensemble standardisé de causes d'erreurs CAN qu'un matériel CAN typique peut détecter et signaler aux couches supérieures [SWS_Can_91021]. Il est mis à disposition via le fichier d'en-tête Can_GeneralTypes.h SWS_CANDriver §8.2.9 « Can_ErrorType ».

L'énumération étant conçue comme un sur-ensemble (superset), chaque contrôleur CAN ne prend pas nécessairement en charge l'ensemble des valeurs spécifiées [SWS_Can_91021]. Les états d'erreur définis comprennent notamment :

erreurs de bit lors de la surveillance du bus (CAN_ERROR_BIT_MONITORING1, CAN_ERROR_BIT_MONITORING0 ou synthétiquement CAN_ERROR_BIT),
erreurs d'acquittement (CAN_ERROR_CHECK_ACK_FAILED, CAN_ERROR_ACK_DELIMITER),
perte d'arbitrage de l'émetteur (CAN_ERROR_ARBITRATION_LOST),
états de surcharge dus à des mémoires tampons de réception pleines (CAN_ERROR_OVERLOAD),
violations de format et de bourrage de bits (bit stuffing) (CAN_ERROR_CHECK_FORM_FAILED, CAN_ERROR_CHECK_STUFFING_FAILED),
erreurs CRC (CAN_ERROR_CHECK_CRC_FAILED) ainsi que
un blocage permanent du bus à un niveau dominant (CAN_ERROR_BUS_LOCK) SWS_CANDriver §8.2.9 « Can_ErrorType ».

Dans l'interaction des modules BSW, le type sert de paramètre à la fonction de rappel CanIf_ErrorNotification pour la transmission des erreurs de contrôleur à l'interface CAN AUTOSAR_SWS_CANInterface §8.x « CanIf_ErrorNotification ». La valeur transmise devrait correspondre à l'état d'erreur constaté par le matériel sous-jacent AUTOSAR_SWS_CANDriver §7.x « Error Notification ». Question Q-d23c45dd3b23ec71 (ouverte)

Ce texte a été généré par une IA et sert à l'orientation technique.

Request a governed re-review of this record. The record is not changed immediately.

Record: AUTOSAR/AP/record/CP_MOD_Can
Status: unspecified
Version: AUTOSAR/AP/record/CP_MOD_Can@rel:R20-11#a71c1ff9
Content hash: a71c1ff9
Source: https://www.autosar.org/fileadmin/standards/R20-11/CP/AUTOSAR_SWS_CANDriver.pdf#nameddest=SWS_Can_00223

Carte des thèmes

Vue détaillée

Sélectionnez une entrée dans le plan.

Aucune donnée d'élément pour cette version

Initialisation et état

Can_DeInit fonction

This function de - initializes the module.

void Can_DeInit (void);

Can_GetVersionInfo fonction

This function returns the version information of this module.

void Can_GetVersionInfo (Std_VersionInfoType* versioninfo);

Can_Init fonction

This function initializes the module.

void Can_Init (const Can_ConfigType* Config);

Services

Can_CheckWakeup fonction

This function checks if a wakeup has occurred for the given controller.

Std_ReturnType Can_CheckWakeup (uint8 Controller);

Can_DisableControllerInterrupts fonction

This function disables all interrupts for this CAN controller.

void Can_DisableControllerInterrupts (uint8 Controller);

Can_EnableControllerInterrupts fonction

This function enables all allowed interrupts.

void Can_EnableControllerInterrupts (uint8 Controller);

Can_GetControllerErrorState fonction

This service obtains the error state of the CAN controller.

Std_ReturnType Can_GetControllerErrorState (uint8 ControllerId, Can_ErrorStateType* ErrorStatePtr);

Can_GetControllerMode fonction

This service reports about the current status of the requested CAN controller.

Std_ReturnType Can_GetControllerMode (uint8 Controller, Can_ControllerStateType* ControllerModePtr);

Can_GetControllerRxErrorCounter fonction

Std_ReturnType Can_GetControllerRxErrorCounter (uint8 ControllerId, uint8* RxErrorCounterPtr);

Can_GetControllerTxErrorCounter fonction

Std_ReturnType Can_GetControllerTxErrorCounter (uint8 ControllerId, uint8* TxErrorCounterPtr);

Can_SetBaudrate fonction

This service shall set the baud rate configuration of the CAN controller. Depending on necessary baud rate modifications the controller might have to reset.

Std_ReturnType Can_SetBaudrate (uint8 Controller, uint16 BaudRateConfig ID); ⚠️

Can_SetControllerMode fonction

This function performs software triggered state transitions of the CAN controller State machine.

Std_ReturnType Can_SetControllerMode (uint8 Controller, Can_ControllerStateType Transition);

Can_Write fonction

This function is called by Can If to pass a CAN message to Can Drv for transmission.

Std_ReturnType Can_Write (Can_HwHandleType Hth, const Can_PduType* PduInfo);

Callouts et interfaces attendues

<LPDU_CalloutName> fonction

boolean <LPDU_CalloutName> (uint8 Hrh, Can_IdType CanId, uint8 CanDataLegth, const uint8* CanSduPtr);

Cyclique

Can_MainFunction_BusOff fonction

This function performs the polling of bus - off events that are configured statically as 'to be polled'.

void Can_MainFunction_BusOff (void);

Can_MainFunction_Mode fonction

This function performs the polling of CAN controller mode transitions.

void Can_MainFunction_Mode (void);

Can_MainFunction_Read fonction

This function performs the polling of RX indications when CAN_ RX_ PROCESSING is set to POLLING.

void Can_MainFunction_Read (void);

Can_MainFunction_Wakeup fonction

This function performs the polling of wake - up events that are configured statically as 'to be polled'.

void Can_MainFunction_Wakeup (void);

Can_MainFunction_Write fonction

This function performs the polling of TX confirmation when CAN_ TX_ PROCESSING is set to POLLING.

void Can_MainFunction_Write (void);

Types

Can_ConfigType type

Can_ControllerStateType type

States that are used by the several Controller Mode functions.

Can_ErrorStateType type

Error states of a CAN controller.

Can_ErrorType type

The enumeration represents a superset of CAN Error Types which typical CAN HW is able to report. That means not all CAN HW will be able to support the complete set.

Can_HwHandleType type

Represents the hardware object handles of a CAN hardware unit. For CAN hardware units with more than 255 HW objects use extended range.

Can_HwType type

This type defines a data structure which clearly provides an Hardware Object Handle including its corresponding CAN Controller and therefore Can Drv as well as the specific Can Id.

Can_IdType type

Can_PduType type

This type unites Pdu Id (sw Pdu Handle), Sdu Length (length), Sdu Data (sdu), and Can Id (id) for any CAN L - SDU.

Cliquez sur une entrée pour voir ses relations.