Differences

This shows you the differences between two versions of the page.

Link to this comparison view

--- fr:examples:can:wiper:intro [2010/03/10 15:54] – sdeniaud
+++ fr:examples:can:wiper:intro [2020/07/20 09:00] (current) – external edit 127.0.0.1
@@ Line 4: / Line 4: @@
 Le système comporte les éléments suivants :
-  * un ensemble "unité centrale" programmable en liaison avec un ordinateur de type PC,
+  * un ensemble "unité centrale" programmable en liaison avec un ordinateur de type PC
-  * une source d'énergie (batterie 12V ou alimentation non autonome générant du 12V,
+  * une source d'énergie (batterie 12V ou alimentation non autonome générant du 12V)
   * un certain nombre d'ensembles, chacun pouvant être constitué
-     *  d'un module d'interface CAN configurable,
+     *  d'un module d'interface CAN configurable
-     *  d'un organe de type capteur, pré – actionneur voire actionneur, compatible avec le module associé,
+     *  d'un organe de type capteur, pré–actionneur voire actionneur, compatible avec le module associé
-  * câbles de liaison.
+  * des câbles de liaison.
 [{{:fr:examples:can:wiper:archi_can_wiper_bd.png?600|Architecture}}]
@@ Line 18: / Line 18: @@
   * Trois modules d'interface différents ont été développés: module 4 sorties de puissance TOR, module 8 entrées TOR et module asservissement (commande moteur en PWM, en bipolaire, entrée codeur 1 voie et 2 entrées fins de course).
-Remarque:   Dans l'application "Commande d'essuie-glace, réf : CAN01B, on n'utilise pas de module 4 sorties de puissance TOR.
+Remarque :   Dans l'application "Commande d'essuie-glace", réf : CAN01B, on n'utilise pas de module 4 sorties de puissance TOR.
-  * Dans sa version "VMD" (Véhicule Multiplexé Didactique) les organes reliés aux modules d'interface CAN peuvent être un commodo lumières, un bloc optique avant, un bloc optique arrière, un commodo essuie-glace un moteur d'essuie glace ou de lève vitre, plafonnier, etc.
+  * Dans sa version VMD (Véhicule Multiplexé Didactique), les organes reliés aux modules d'interface CAN peuvent être un commodo lumières, un bloc optique avant, un bloc optique arrière, un commodo essuie-glace un moteur d'essuie-glace ou de lève-vitre, plafonnier, etc.
   * L'unité centrale programmable comprend un certain nombre de cartes électroniques reliées entre elle par BUS parallèles :
     * cartes indispensables
-      * carte processeur EID210 conçue autour du microprocesseur 32 bits  Motorola 68332  (carte spécifique Didalab),
+      * [[fr:hardware:wiper:cpu-eid210|carte processeur EID210]] conçue autour du microprocesseur 32 bits  Motorola 68332  (carte spécifique Didalab)
-      * carte industrielle d'interface parallèle / CAN conçue autour du contrôleur CAN  "SJA1000", au format normalisé "PC104" (carte commercialisée par la société ATON SYSTEMES),
+      * [[fr:hardware:wiper:aton-pc104|carte industrielle d'interface parallèle / CAN]] conçue autour du contrôleur CAN  SJA1000, au format normalisé PC104 (carte commercialisée par la société Aton Systèmes),
-    * cartes optionnelles  (non utilisée dans l'application Essuie-Glace   Réf : CAN01B)
+    * cartes optionnelles  (non utilisée dans l'application Essuie-Glace, Réf : CAN01B
-      * carte clavier 16 touches matricé et afficheur graphique (carte spécifique Didalab),
+      * carte clavier 16 touches matricées et afficheur graphique (carte spécifique Didalab)
-      * carte d'interface réseau "Eternet" (carte spécifique Didalab),
+      * carte d'interface réseau Ethernet (carte spécifique Didalab)
-      * toute carte au format PC1014.
+      * toute carte au format PC1014
 ===== Organisation logicielle =====
-==== Les fichiers de définitions ====
+==== Les fichiers de définition ====
-Les programmes fournis font appel à des fichiers de définitions:
+Les programmes fournis font appel à des fichiers de définition :
-  * ''CPU_Reg.h'' définissant les adresses d'accès aux différents registres internes au microcontrôleur 68332 (processeur autour duquel est conçue la carte processeur EID210),
+  * ''CPU_Reg.h'' définissant les adresses d'accès aux différents registres internes au micro-contrôleur 68332 (processeur autour duquel est conçue la carte processeur EID210)
-  * ''EID210_Reg.h'' définissant les adresses d'accès aux différents éléments matériels implantés sur la carte processeur EID210,
+  * ''EID210_Reg.h'' définissant les adresses d'accès aux différents éléments matériels implantés sur la carte processeur EID210
-  * ''Aton_CAN.h'' définissant les adresses d'accès aux différents registres du contrôleur CAN SJA1000 implanté sur la carte industrielle "CAN-PC104"  fournie par la société  "ATON SYSTEMES",
+  * ''[[fr:examples:can:wiper:annex3|Aton_CAN.h]]'' définissant les adresses d'accès aux différents registres du contrôleur CAN SJA1000 implanté sur la carte industrielle CAN-PC104  fournie par la société  Aton Systèmes
-  * ''Structures_Donnees.h'' définissant l'ensemble des structures de données utiles à une programmation structurée,
+  * ''Structures_Donnees.h'' définissant l'ensemble des structures de données utiles à une programmation structurée
-  * ''CAN_VMD.h'' définissant les éléments de l'application VMD.
+  * ''[[fr:examples:can:wiper:annex2|CAN_VMD.h]]'' définissant les éléments de l'application VMD
+**Attention : Veiller à ce que tous ces fichiers soient présents, soit dans le répertoire de travail, soit dans le  répertoire "include" lui-même situé sous le répertoire contenant l'environnement de développement intégré ("Cross compilateur") EID210100.**
 ==== Les structures de données spécifiques à l'application CAN ====
-Définition des unions et structures particulières (Voir dans fichier CAN_VMD.h)
+**Définition des unions et structures particulières (Voir dans fichier ''[[fr:examples:can:wiper:annex2|CAN_VMD.h]]'')**
-Les structures définies ci-après ont été définies en conformités aux différents registre du SJA1000  (se référer à la notice technique du SJA1000, pages 39 ; 40 et 41)
+Les structures définies ci-après ont été définies en conformités aux différents registres du SJA1000  (se référer à la notice technique du SJA1000, pages 39, 40 et 41).
-L'union //tr_info//  est à associer au registre d'information trame du circuit SJA1000
+L'union ''tr_info'' est à associer au registre d'information trame du circuit SJA1000.
 <code c>
@@ Line 64: / Line 68: @@
 </code>
-L'union ''ident_standard'' permet de définir la partie identification en mode standard
+L'union ''ident_standard'' permet de définir la partie identification en mode standard.
 <code c>
@@ Line 86: / Line 90: @@
 Cette union permet de définir les mêmes informations mais de trois façons différentes.
-L'union //ident_extend// permet de définir la partie identification en mode étendu
+L'union ''ident_extend'' permet de définir la partie identification en mode étendu.
 <code c>
@@ Line 109: / Line 113: @@
 Remarque : Cette union permet de définir les mêmes informations mais de trois façons différentes.
-La structure //Trame// permet de définir une trame complète
+La structure ''Trame'' permet de définir une trame complète.
 <code c>
@@ Line 125: / Line 129: @@
-Exemple : Définir une trame qui permette d'écrire dans un registre  du circuit MCP25050 implanté sur le module 8 entrées  //Commodo Essuie-Glace//.
+**Exemple : Définir une trame qui permette d'écrire dans un registre  du circuit MCP25050 ({{:fr:hardware:didalab:mcp2502x_5x.pdf|doc. technique}}) implanté sur le module 8 entrées  Commodo Essuie-Glace.**
-Dans ce cas, la trame envoyée par le contrôleur CAN (Circuit SJA1000 sur carte CAN_PC104) sera vue par le récepteur (circuit MCP25050 sur module) comme un "Input Message", avec la fonction "Write register" (voir documentation  technique du MPC25025 pages 22).
+Dans ce cas, la trame envoyée par le contrôleur CAN (Circuit SJA1000 sur carte CAN_PC104) sera vue par le récepteur (circuit MCP25050 sur module) comme un ''Input Message'', avec la fonction ''Write register'' (voir {{:fr:hardware:didalab:mcp2502x_5x.pdf|doc. technique}} du MPC25025 pages 22).
-Ce tableau indique que la trame comportera une zone de donnée composée de trois octets (donc DLC =3)
+Ce tableau indique que la trame comportera une zone de donnée composée de trois octets (donc ''DLC =3'')
-  * le premier octet (repéré //addr//) spécifie l'adresse du registre concerné par l'opération d'écriture
+  * le premier octet (repéré ''addr'') spécifie l'adresse du registre concerné par l'opération d'écriture
-  * le deuxième octet (repéré //mask//) spécifie les bits concernés par l'opération d'écriture
+  * le deuxième octet (repéré ''mask'') spécifie les bits concernés par l'opération d'écriture
-  * le troisième octet (repéré //value//) spécifie la valeur des bits.
+  * le troisième octet (repéré ''value'') spécifie la valeur des bits
 Remarques :
-. Rôle de l'octet //mask//
+. Rôle de l'octet ''mask''
-      *  Si on met un  '1'  dans un bit du masque, le bit correspondant du registre sera concerné par l'opération d'écriture. Il prendra la valeur spécifiée dans l'octet "value".
+      *  Si on met un  '1'  dans un bit du masque, le bit correspondant du registre sera concerné par l'opération d'écriture. Il prendra la valeur spécifiée dans l'octet ''value''.
-      *  Si on met un  '0'  dans un bit du masque, le bit correspondant du registre ne sera pas concerné par l'opération d'écriture. Il conservera sa valeur et la valeur spécifiée dans l'octet //value// est sans influence.
+      *  Si on met un  '0'  dans un bit du masque, le bit correspondant du registre ne sera pas concerné par l'opération d'écriture. Il conservera sa valeur et la valeur spécifiée dans l'octet ''value'' est sans influence.
 . Détermination de l'adresse
-Les adresses des différents registres sont définies dans la table 3 du chapitre 3,  aux pages 15 et 16 de la notice technique du circuit MCP25050. Il faut prendre connaissance de la "note 1" qui indique qu'il faut ajouter 1Ch aux adresses indiquées dans le tableau, à l'exception du registre GPDDR (repère 1 en bas de la page 15)
+Les adresses des différents registres sont définies dans la table 3 du chapitre 3,  aux pages 15 et 16 de la {{:fr:hardware:didalab:mcp2502x_5x.pdf|doc. technique}} du circuit MCP25050. Il faut prendre connaissance de la ''note 1'' qui indique qu'il faut ajouter 1Ch aux adresses indiquées dans le tableau, à l'exception du registre GPDDR (repère 1 en bas de la page 15)
-Ex: pour écritre dans le registre de sortie //GPLAT//, l'adresse sera 02h+1Ch = 1Eh
+Ex : pour écrire dans le registre de sortie ''GPLAT'', l'adresse sera 02h+1Ch = 1Eh
 . Détermination de l'identificateur
-Dans l'[[annex1|annexe 1]], il est décrit les principes d'identification des différents modules. Des labels sont également définis dans le registre CAN_VMD.h
+Dans l'[[annex1|annexe 1]], il est décrit les principes d'identification des différents modules. Des labels sont également définis dans le registre ''[[annex2|CAN_VMD.h]]''
-      *  Définition d'une variable structurée sous le modèle //Trame//:
+      *  Définition d'une variable structurée sous le modèle ''Trame'' :
-  Trame T_IM_Commodo_EG; 	//  IM -> Input Message
+<code c>
-       // Trame destinée au module 8 entrées sur lequel est connecté le commodo Essuie-Glace
+Trame T_IM_Commodo_EG; 	//IM -> Input Message
+//Trame destinée au module 8 entrées sur lequel est connecté le commodo Essuie-Glace
+</code>
-Remarque:  La variable structurée  T_IM_ Commodo_EG comportera 8 octets (1 pour trame_info, 4 pour l’identificateur, 1 pour l’adresse registre, 1 pour le masque et 1 pour la valeur).
+Remarque :  La variable structurée  ''T_IM_ Commodo_EG'' comportera 8 octets (1 pour ''trame_info'', 4 pour l’identificateur, 1 pour l’adresse registre, 1 pour le masque et 1 pour la valeur).
-      *  Accès et définition des différents éléments de la variable structurée //T_IM_Commodo_EG//
+      *  Accès et définition des différents éléments de la variable structurée ''T_IM_Commodo_EG''
 <code c>
   T_IM_Commodo_EG.trame_info.registre=0x00;//On initialise tous les bits du registre à 0
@@ Line 167: / Line 173: @@
-==== Les fonctions spécifiques ====
+===== Les fonctions spécifiques =====
-Des fonctions spécifiques à l'accès au réseau CAN via la carte CAN-PC104 de chez "ATON SYSTEMES".
+Des fonctions spécifiques à l'accès au réseau CAN via la carte CAN-PC104 de chez Aton Systèmes.
-Les prototypes de ces fonctions sont définis dans le fichier Aton_CAN.h et leurs définitions elle-mêmes dans le fichier //Aton_CAN.C//
+Les prototypes de ces fonctions sont définis dans le fichier ''[[annex3|Aton_CAN.h]]'' et leurs définitions elle-mêmes dans le fichier ''Aton_CAN.C''
-S'il ne l'est déjà, ce fichier doit être compilé et son résultat de compilation //Aton_CAN.o// doit être inclus en tant que fichier à //Linker// avec le fichier application.
+S'il ne l'est déjà, ce fichier doit être compilé et son résultat de compilation ''Aton_CAN.o'' doit être inclus en tant que fichier à Linker avec le fichier application.
-  * Fonction   **Init_Aton_CAN()**
+**Attention :
-Cette fonction permet d'initialiser le circuit intégré SJA1000, cœur de la carte CAN-PC104 de chez ATON-SYSTEMES. Aucun paramètre n'est passé ni retourné.
+Veiller à ce que le fichier ''Aton_CAN.o'' soit présent dans le  répertoire "lib" lui-même situé sous le répertoire contenant l'éditeur-assembleur EID210100.
+Veiller également à ce que ce fichier ''Aton_CAN.o'' soit inclus au "linker".
+Pour ce faire :
+Dans logiciel EID210, sélectionner "Configuration" puis "GNU C/C++" puis "Linker" puis   "Ajouter" puis retrouver et sélectionner le fichier ''Aton_CAN.o'' qui viendra s'ajouter aux fichiers déjà présents c'est à dire ''CTR0.o'' et ''EID210.o''**
+  * Fonction   **''Init_Aton_CAN()''**
+Cette fonction permet d'initialiser le circuit intégré SJA1000, cœur de la carte CAN-PC104 de chez Aton Systèmes. Aucun paramètre n'est passé ni retourné.
 Cette fonction est à appeler dans la partie "Initialisation" du programme application
-  * Fonction   **Ecrire_Trame(Nom_Trame)**
+  * Fonction   **''Ecrire_Trame(Nom_Trame)''**
 Cette fonction permet d'envoyer une trame sur le réseau CAN.
-La variable passée est une variable structurée sous le modèle "Trame" (modèle défini dans le chapitre précédent).
+La variable passée est une variable structurée sous le modèle ''Trame'' (modèle défini dans le chapitre précédent).
-Cette fonction ne renvoi pas de paramètre.
+Cette fonction ne renvoie pas de paramètre.
-  * Fonction   **Lire_Trame(&Nom_Trame_recue) **
+  * Fonction   **''Lire_Trame(&Nom_Trame_recue)'' **
-Cette fonction permet de savoir si une trame a été reçue du réseau CAN et si oui d'accéder à celle-ci. La variable passée est un pointeur sur variable structurée sous le modèle "Trame"  (modèle défini dans le chapitre précédent).
+Cette fonction permet de savoir si une trame a été reçue du réseau CAN et si oui d'accéder à celle-ci. La variable passée est un pointeur sur variable structurée sous le modèle ''Trame''  (modèle défini dans le chapitre précédent).
 Le paramètre renvoyer vaut 1 si un message a été reçu et 0 si aucun message n'a été reçu.
-  * Fonction   **Affiche_Trame(Nom_Trame)**
+  * Fonction   **''Affiche_Trame(Nom_Trame)''**
 Cette fonction permet d'afficher une trame sur l'écran de l'ordinateur connecté à l'unité centrale programmable.
-La variable passée est une variable structurée sous le modèle "Trame" (modèle défini dans le chapitre précédent).
+La variable passée est une variable structurée sous le modèle ''Trame'' (modèle défini dans le chapitre précédent).
 Cette fonction ne renvoi pas de paramètre.
-==== Principe des échanges sur le bus ====
+===== Principe des échanges sur le bus =====
-L'utilisation du //CAN Expander// MCP25050 impose différents types de trames (d'après la page 2 dans la notice technique du "CAN Expander"  MCP25050)
+L'utilisation du CAN Expander MCP25050 impose différents types de trames (d'après la page 2 dans la {{:fr:hardware:didalab:mcp2502x_5x.pdf|doc. technique}} du CAN Expander  MCP25050)
-  * **Trame //IM// (Input Message)**
+  * **Trame ''IM'' (Input Message)**
-C'est en fait une trame de commande (ou missive) envoyée par le contrôleur à un nœud destinataire (ex: écriture d'une valeur dans un registre du //CAN Expander// MCP25050 destinataire)
+C'est en fait une trame de commande (ou missive) envoyée par le contrôleur à un nœud destinataire (ex: écriture d'une valeur dans un registre du CAN Expander MCP25050 destinataire)
-  * **Trame //Ack// (Acknowledge Message)**
+{{  :fr:examples:can:wiper:trame_im.png  |''Trame IM''}}
+  * **Trame ''Ack'' (Acknowledge Message)**
 C'est une trame de réponse à une IM informant que le nœud destinataire s'est reconnu et a bien pris en compte la missive IM qui vient de circuler sur le bus.
-  * **Trame //IRM// (Information Request Message)**
+{{  :fr:examples:can:wiper:trame_ack.png  |''Trame ACK''}}
-C'est en fait une trame de type requête (interrogation) envoyée par le contrôleur à un nœud destinataire lui demandant des informations (ex: Lecture d'un ou de plusieurs registre(s) du "CAN Expander" MCP25050 destinataire)
-  * **Trame //OM// (Output Message)**
+  * **Trame ''IRM'' (Information Request Message)**
-C'est une trame de réponse à une IRM, envoyée par le nœud destinataire de l'IRM précédemment envoyée et contenant dans sa zone "Data" les informations demandées.
+C'est en fait une trame de type requête (interrogation) envoyée par le contrôleur à un nœud destinataire lui demandant des informations (ex: Lecture d'un ou de plusieurs registre(s) du CAN Expander MCP25050 destinataire)
-**Conséquences :**
+{{  :fr:examples:can:wiper:trame_irm.png  |''Trame IRM''}}
-  * Dans un programme, suite à l'envoi d'une IM ou d'une IRM  (utilisation de la fonction Ecrire_Trame( )) , il est impératif d'attendre la réponse (utilisation de la fonction Lire_Trame( )), avant d'envoyer une nouvelle trame:
-     * cette réponse sera une //Ack// suite à une //IM//
-     * cette réponse sera une //OM//  suite à une //IRM//
-Lors du premier échange, il conseillé de prévoir un "Time out" et l'affichage d'un message d'alerte dans le cas où il n'y a pas de réponse, afin d'éviter une situation bloquante.
-**Remarques :**
+  * **Trame ''OM'' (Output Message)**
-  * L'identificateur d'une //OM// est le même que celui de l'IRM qui est à l'origine.
+C'est une trame de réponse à une IRM, envoyée par le nœud destinataire de l'IRM précédemment envoyée et contenant dans sa zone Data les informations demandées.
-  * L'identificateur d'une //Ack// est différent que celui de l'IM qui est à l'origine.
-**Trames particulières :**
+{{  :fr:examples:can:wiper:trame_om.png  |''Trame OM''}}
-  * A la mise sous tension un //CAN Expander MCP25050// signale sa présence par l'envoi automatique (sans interrogation) d'une trame de type //OB// (On Bus Massage).
-  * Il est possible de configurer un "CAN Expander MCP25050" pour qu'il envoi automatiquement une trame
-        * lorsqu'une de ses entrées subi un changement d'état prédéfini (Pages 23 et 26  doc MCP25050)
-        * lorsqu'une entrée alalogique prédéfinie croise un seuil de tension //Threshold detection//
-   	      (Pages 23 et 35 doc MCP25050)
-        * à intervalle de temps régulier //Scheduled transmissions// (Pages 24 doc MCP25050)
+**Conséquences :**
+  * Dans un programme, suite à l'envoi d'une ''IM'' ou d'une ''IRM''  (utilisation de la fonction ''Ecrire_Trame( )''), il est impératif d'attendre la réponse (utilisation de la fonction ''Lire_Trame( )''), avant d'envoyer une nouvelle trame :
+     * cette réponse sera une ''Ack'' suite à une ''IM''
+     * cette réponse sera une ''OM''  suite à une ''IRM''
+Lors du premier échange, il conseillé de prévoir un Time out et l'affichage d'un message d'alerte dans le cas où il n'y a pas de réponse, afin d'éviter une situation bloquante.
+**Remarques :**
+  * L'identificateur d'une ''OM'' est le même que celui de l'''IRM'' qui est à l'origine.
+  * L'identificateur d'une ''Ack'' est différent que celui de l'''IM'' qui est à l'origine.
+**Trames particulières :**
+  * A la mise sous tension un CAN Expander MCP25050 signale sa présence par l'envoi automatique (sans interrogation) d'une trame de type ''OB'' (On Bus Massage).
+  * Il est possible de configurer un CAN Expander MCP25050 pour qu'il envoie automatiquement une trame
+        * lorsqu'une de ses entrées subi un changement d'état prédéfini (pages 23 et 26  {{:fr:hardware:didalab:mcp2502x_5x.pdf|doc. technique}} MCP25050)
+        * lorsqu'une entrée analogique prédéfinie croise un seuil de tension ''Threshold detection'' (pages 23 et 35 {{:fr:hardware:didalab:mcp2502x_5x.pdf|doc. technique}} MCP25050)
+        * à intervalle de temps régulier ''Scheduled transmissions'' (page 24 {{:fr:hardware:didalab:mcp2502x_5x.pdf|doc. technique}} MCP25050)

fr/examples/can/wiper/intro.1268236440.txt.gz · Last modified: 2020/07/20 09:00 (external edit)