Differences

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

--- fr:examples:can:wiper:tp3 [2010/03/05 10:47] – sdeniaud
+++ fr:examples:can:wiper:tp3 [2020/07/20 09:00] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== TP3 - TP N°4:  FAIRE BATTRE LE BALAI D'ESSUIE GLACE ======
+====== TP3 - Exemple 3 ======
 ===== Sujet: =====
+**Faire battre le balai de l'essuie-glace**
 ==== Objectifs : ====
-- Définir les différentes trames interrogatives ou de commande à faire transiter par le réseau CAN en fonction d'une action souhaitée.
+  * Définir les différentes trames interrogatives ou de commande à faire transiter par le réseau CAN en fonction d'une action souhaitée.
-- Commander un actionneur électrique (moteur à courant continu), dans les deux sens de rotation par l'intermédaire d'un pré-actionneur commandable par réseau CAN.
+  * Commander un actionneur électrique (moteur à courant continu), dans les deux sens de rotation par l'intermédaire d'un pré-actionneur commandable par réseau CAN.
-- Acquérir l'état de capteurs TOR (fins de course) acessibles par réseau CAN et en déduire les actions à mener pour satisfaire un cahier des charges imposé.
+  * Acquérir l'état de capteurs TOR (fins de course) acessibles par réseau CAN et en déduire les actions à mener pour satisfaire un cahier des charges imposé.
 ==== Cahier des charges : ====
@@ Line 24: / Line 25: @@
 **Principe:**
 Le module d'interface CAN mis en œuvre dans ce TP est le module repéré "Asservissement".
-Ce module permet la commande d'un moteur à courant continu 24V/ 1A, dans les deux sens de rotation, en mode "PWM" (modulation de largeur d'impulsion).
+Ce module permet la commande d'un moteur à courant continu 24V/ 1A, dans les deux sens de rotation, en mode "PWM" (modulation de largeur d'impulsion). Cette possibilité a été expérimentée dans le TP5.
-Cette possibilité a été expérimentée dans le TP Exemple n°3 mais dans un seul sens de rotation.
+Il permet d'acquérir 3 entrées TOR sur lesquelles on pourra connecter les capteurs de fin de courses:
+	→ fcd  (fin de course droit) relié à l'entrée GP5 du contrôleur CAN
+	→ fcg  (fin de course gauche) relié à l'entrée GP6 du contrôleur CAN
+	→ fs  (fin de surcource) relié à l'entrée GP7 du contrôleur CAN
+Le cycle demandé conduit au diagramme des états suivant:
-Ce module « asservissement » disposeégalemnt de 3 entrées TOR sur lesquelles on pourra connecter les capteurs de fin de courses:
+{{  :fr:examples:can:wiper:diag_etats.png  |}}
-	→ fcd  (fin de course droit) relié à l'entrée GP5 du contrôleur « CAN Expander »
-	→ fcg  (fin de course gauche) relié à l'entrée GP6 du contrôleur « CAN Expander »
-	→ fs  (fin de surcource) relié à l'entrée GP7 du contrôleur « CAN Expander »
-Le cycle demandé conduit au diagramme des états suivant:
-**Configurations du module "Asservissemnt" pour l'utilisation envisagée:**
+**Configurations du module "Asservissement" pour l'utilisation envisagée:**
 Comme dans l'exemple n°2, il faut envoyer un certain nombre de "Trames" afin de configurer le module "Asservissement"
-Trame n°1   →  pour définir les entrées et sorties du module "Asservissement"
-Il faut initialiser le registre GPDDR ("Data Direction Register")     ->    Idem TP Exemple n°2
+**Trame n°1**   →  pour définir les entrées et sorties du module "Asservissement"
+Il faut initialiser le registre GPDDR ("Data Direction Register") -> Idem TP Exemple n°2
-Trame n°2   → pour initialiser la sortie GP2 en sortie PWM1 (commande  du moteur dans le sens positif)
+**Trame n°2**   → pour initialiser la sortie GP2 en sortie PWM1 (commande  du moteur dans le sens positif) → Idem TP Exemple n°2
-  ->    Idem TP Exemple n°2
-Trame n°3   →  pour définir la fréquence de la  sortie PWM1:        ->    Idem TP Exemple n°2
+**Trame n°3**   →  pour définir la fréquence de la  sortie PWM1: → Idem TP Exemple n°2
-Trame n°4   →  pour définir le rapport cyclique de la sortie PWM1 (module de la commande donc de la vitesse du moteur)       ->    Idem TP Exemple n°2
-Trame n°5   → pour initialiser la sortie GP3 en sortie PWM2 (commande  du moteur dans le sens négatif)
+**Trame n°4**   →  pour définir le rapport cyclique de la sortie PWM1 (module de la commande donc de la vitesse du moteur) → Idem TP Exemple n°2
+**Trame n°5**   → pour initialiser la sortie GP3 en sortie PWM2 (commande  du moteur dans le sens négatif)
 D'après la notice technique du circuit MCP25050 (pages 30 à 32), la génération du signal PWM2 se fait à partie du "Timer2" et la fréquence de ce signal est choisie grâce au registre "T2CON" d'adresse 06H  (page 15 Doc MCP25050).
-	bit 7 =1  	TMR2ON	Validation du "Timer 2"
+<code c>
-	bits 5:4	seront mis à 0 pour avoir un coefficient de division de fréquence égal à 1 ("TMR2 prescaler value" = 1)
+bit 7 =1  	TMR2ON	Validation du "Timer 2"
-  T_IM_Asservissement.data[0]=0x22; // Adresse du registre T1CON en écriture
+bits 5:4	seront mis à 0 pour avoir un coefficient de division de fréquence égal à 1 ("TMR2 prescaler value" = 1)
-   (doc MCP25050 p15) 06H + décalage = 06H + 1CH = 22H
+T_IM_Asservissement.data[0]=0x22; // Adresse du registre T1CON en écriture (doc MCP25050 p15) 06H + décalage = 06H + 1CH = 22H
-  T_IM_Asservissement.data[1]=0xB3; // Masque sur le registre (doc MCP25050 p32)
+T_IM_Asservissement.data[1]=0xB3; // Masque sur le registre (doc MCP25050 p32)
-  T_IM_Asservissement.data[2]=0x80; // Valeur à charger dans le registre adressé
+T_IM_Asservissement.data[2]=0x80; // Valeur à charger dans le registre adressé
+</code>
 Suite à ces définitions, il faudra envoyer la trame puis attendre la réponse de type "Ack".
-Trame n°6   →  pour définir la fréquence de la  sortie PWM2:
+**Trame n°6**   →  pour définir la fréquence de la  sortie PWM2:
 Cette fréquence dépend de la valeur chargée dans le registre "PR2"
-  T_IM_Asservissement.data[0]=0x24; // adresse du registre PR2 en écriture
+<code c>
-   (doc MCP25050 p15) 08H + décalage = 08H + 1CH = 24H
+T_IM_Asservissement.data[0]=0x24; // adresse du registre PR2 en écriture (doc MCP25050 p15) 08H + décalage = 08H + 1CH = 24H
-  T_IM_Asservissement.data[1]=0xFF; // Masque sur le registre (doc MCP25050 p32)
+T_IM_Asservissement.data[1]=0xFF; // Masque sur le registre (doc MCP25050 p32)
-  T_IM_Asservissement.data[2]=0xFF; // On chargera 255 dans le registre
+T_IM_Asservissement.data[2]=0xFF; // On chargera 255 dans le registre
+</code>
 La fréquence du quartz implanté sur la carte "asservissement" étant égale à 16Mhz, la fréquence du signal PWM2 sera donc égale à :     FPWM = 16.106/(4.256) = 15,6 KHz
 Ce qui est une fréquence correcte pour piloter un moteur en PWM (fréquence sensiblement inaudible).
 Suite à ces définitions, il faudra envoyer la trame puis attendre la réponse de type "Ack".
-Trame n°7   →  pour définir le rapport cyclique de la sortie PWM2 (module de la commande donc de la vitesse du moteur)
+**Trame n°7**   →  pour définir le rapport cyclique de la sortie PWM2 (module de la commande donc de la vitesse du moteur)
-  T_IM_Asservissement.data[0]=0x25; //adresse du registre PWM2DCH en écriture
+<code c>
-   (doc MCP25050 p15) 0AH + décalage = 0AH + 1CH = 26H
+T_IM_Asservissement.data[0]=0x25; //adresse du registre PWM2DCH en écriture (doc MCP25050 p15) 0AH + décalage = 0AH + 1CH = 26H
-  T_IM_Asservissement.data[1]=0xFF; //masque sur le registre (doc MCP25050 p33)
+T_IM_Asservissement.data[1]=0xFF; //masque sur le registre (doc MCP25050 p33)
-  T_IM_Asservissement.data[2]=0x00; // Commande = 0 (0xFF=255 pour la commande Maxi)
+T_IM_Asservissement.data[2]=0x00; // Commande = 0 (0xFF=255 pour la commande Maxi)
+</code>
 Suite à ces définitions, il faudra envoyer la trame puis attendre la réponse de type "Ack".
@@ Line 76: / Line 79: @@
 Définition de la trame interrogative permettant de connaître l'état des fins de course:
-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 une IRM  "Information Request Message", avec la fonction "Read 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 une IRM ''Information Request Message'', avec la fonction ''Read register'' (voir documentation  technique du MPC25025 pages 22).
-D’après le tableau donné page 22 de la notice du MCP25050, l’identificateur lui-même contiendra l’adresse du registre lu. Cette adresse est placée sur les bits  ID15 à ID8 de l’identificateur en mode étendu (bits qui seront réceptionnés et placés dans le registre RXBEID8). Le registre concerné est GPPIN d’adresse 1Eh " (voir documentation  technique du MPC25025 pages 37).
+D’après le tableau donné page 22 de la notice du MCP25050, l’identificateur lui-même contiendra l’adresse du registre lu. Cette adresse est placée sur les bits  ID15 à ID8 de l’identificateur en mode étendu (bits qui seront réceptionnés et placés dans le registre RXBEID8). Le registre concerné est GPPIN d’adresse ''1Eh'' (voir documentation  technique du MPC25025 pages 37).
 D’autre part, les trois bits de poids faibles de l’identificateur en mode étendu devront être positionnés à 1.
 L’identificateur défini dans le chapitre 1 devra donc être complété comme suit:
+{{  :fr:examples:can:wiper:acquisition.png?600  |}}
 → Définition de variables structurées sous le modèle  "Trame":
-  Trame T_IRM_Acquisition_FC; 	 // Trame destinée à l’interrogation du module asservissement pour acquérir Fins de Courses.
+<code c>
-Remarque:  La variable structurée  T_IRM_Acquisition_FC comportera 5 octets utiles seulement, 1octet pour trame_info et  4 octets pour l'identificateur en mode étendu (qui comprendra l'adresse du registre concerné par la lecture.
+Trame T_IRM_Acquisition_FC; 	 // Trame destinée à l’interrogation du module asservissement pour acquérir Fins de Courses.
+</code>
+Remarque:  La variable structurée ''T_IRM_Acquisition_FC'' comportera 5 octets utiles seulement, 1octet pour trame_info et  4 octets pour l'identificateur en mode étendu (qui comprendra l'adresse du registre concerné par la lecture.
-→ Accès et définition des différents éléments de la variable structurée "Lecture_FC"
+→ Accès et définition des différents éléments de la variable structurée ''Lecture_FC''
+<code c>
   T_IRM_Acquisition_FC.trame_info.registre=0x00;  //On initialise tous les bits à 0
   T_IRM_Acquisition_FC.trame_info.champ.extend=1; //On travaille en mode étendu
   T_IRM_Acquisition_FC.trame_info.champ.dlc=0x01; //Il y aura 1 octet de données demandé
   T_IRM_Acquisition _FC.ident.extend.identificateur.ident=0x00841E07;
+</code>
 Suite à ces définitions, il faudra
-	- envoyer la trame par la fonction Ecire_Trame(Acquisition _FC)
+  * envoyer la trame par la fonction ''Ecrire_Trame(Acquisition _FC)''
-	-  puis attendre la réponse de type "OM"  en utilisant la fonction  Lire_Trame(&T_Recue)
+  * puis attendre la réponse de type "OM"  en utilisant la fonction  ''Lire_Trame(&T_Recue)''
 D'après la définition des identificateurs donnée en Annexe, une trame de réponse à une IRM a le même identificateur que la trame interrogative qui en a été à l'origine.
 Vu du module (du MCP25050), la réponse à un "IRM" (Information Request Message) est un "OM" (Output Message).
-La différence avec la trame interrogative origine est que cette trame réponse comporte le paramètre "value" (au rang 0 de la partie "data" de la trame de réponse). Ce paramètre est l'image des entrées. On récupère donc l'état des différents capteurs.
+La différence avec la trame interrogative origine est que cette trame réponse comporte le paramètre ''value'' (au rang 0 de la partie "data" de la trame de réponse). Ce paramètre est l'image des entrées. On récupère donc l'état des différents capteurs.
 **Définition de variables structurées images de l'état des fins de course**
@@ Line 103: / Line 111: @@
 La trame reçue en réponse à cette trame interrogative comportera en data[0], l'état des fins de course. On recopie cette donnée reçue dans une variable image.
 union byte_bits FC;
+<code c>
 #define Etats_FC FC.valeur // Pour l'ensemble des états fins de courses
 #define fs FC.bit.b7  // Pour fin de surcourse
 #define fcg FC.bit.b6 // Pour fin de course gauche
 #define fcd FC.bit.b5 // Pour fin de course droit
+</code>
 Afin de pouvoir détecter les changements d'état des capteurs, on mémorise l'état dans une deuxième variable structurée -> Etat_mémorisé
+<code c>
 union byte_bits FC_Mem; // Pour fins de courses mémorisés
 #define Etats_FC_Mem FC_Mem.valeur  // Pour l'ensemble des états mémorisés
+</code>
 Si l'état d'une variable acquise est différente de sa valeur mémorisée, c'est qu'il y a eu un changement d'état. On en déduit alors les actions à mener.
@@ Line 116: / Line 128: @@
 ==== Organigramme: ====
+{{  :fr:examples:can:wiper:orga_3.png  |}}
 ==== Programme en "C" ====

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