Discussion :

[jerepout]

Bonjour à tous,

j'ai vraiment besoin d'aide, je ne m'en sors pas. Mon problème repose sur une difficulté d'interruption.

Que je vous présente mon projet: J'ai pour objectif de créer un petit appareil permettant d'infuser le thé à l'aide d'une pompe en fonction de chaque type ( le temps d'infusion changera entre du thé noir et du thé vert). Pour ce faire, j'allume mon proto avec un bouton, puis je souhaite choisir mon type de thé, ceci étant indiqué par la couleur de ma LED multicolore ( Vert pour thé vert, rouge thé" rouge etc..) Je vous ai mit en PJ un morceau de synoptique.

Seulement, je n'arrive pas à gérer mes interruptions. Je n'arrive jamais à passer mon premier mode/type de thé. J'aimerai qu'au fur et à mesure des clics( je passe de programme en programme (1 clic -> programme thé vert et donc LED verte, 2ème clic programme thé rouge ...). Il y a une deuxième LED qui est censé indiquer si la température est trop chaude (vous le verrez dans la synoptique)

Merci beaucoup à ceux qui prendront le temps de m'aider. Bonne journée.

Voici le code (GPIOB1-2-3->LED, GPIOC->POMPE, GIPOD7->Bouton)

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
 
void detection2(void){
 
    In1=GPIO_ReadInputPin(GPIOD,GPIO_PIN_7);
    /*if (In1==0)
    {     
    //Si l'entrée est à 0
        In1_0++;
        In1_1=0;
        if(In1_0> Debounce)
        { In1_0=Debounce+1;
            StatoIn1=0;
         
      }
    }
    else {//si l'entrée est à 1     In1_1++;
        In1_0=0;
        In1_1++;
        if(In1_1> Debounce)
        {
            In1_1=Debounce+1;
            StatoIn1=1;
            }
        }*/
 
old_state = In1;
while (1) {
  new_state = In1;
  /* Détection d'un changement d'état */
  if (old_state != new_state) {
    if (new_state == 1) {
      /* Traitement du front montant */
    }
    else {
     choix++; /* Traitement du front descendant */
    }
    old_state = new_state;
          }
}
 
  }
 
 
void main(void)
  {
    int d=0;
 
    bool i = FALSE;
 
  CLK_Config();
    GPIO_Config();
    TIM1_Config();
    TIM4_Config(); 
    enableInterrupts();
 
 
    while(1){
//  wfi();
  detection2();
 
 
    if(choix>2)choix=0;
        switch (choix){
        case 0: 
        for (d=0;d<20000;d++){
              GPIO_WriteHigh(GPIOB,GPIO_PIN_1);
                    GPIO_WriteHigh(GPIOC,GPIO_PIN_1);
                    GPIO_WriteLow(GPIOB,GPIO_PIN_2);
                    GPIO_WriteLow(GPIOB,GPIO_PIN_3);
                        break;
                    }
 
        case 1:
        for (d=0;d<20000;d++){
              GPIO_WriteHigh(GPIOC,GPIO_PIN_1);
          GPIO_WriteHigh(GPIOB,GPIO_PIN_2);
          GPIO_WriteLow(GPIOB,GPIO_PIN_1);
          GPIO_WriteLow(GPIOB,GPIO_PIN_3);
          break;
          }
 
        case 2:
        for (d=0;d<20000;d++){
                GPIO_WriteHigh(GPIOC,GPIO_PIN_1);
            //  GPIO_WriteHigh(GPIOB,GPIO_PIN_3);
              GPIO_WriteLow(GPIOB,GPIO_PIN_2);
              GPIO_WriteLow(GPIOB,GPIO_PIN_1);
            break;
            }
 
 
    }
 
 
}

Je pense que le soucis vient de la détection de l'interruption

[sambia39]

Bonjour,

Je pense que le soucis vient de la détection de l'interruption

Je pars du principe que votre prototype utilise la raspberry pi (vu les GPIO, mais j’ai tout de même un doute pourriez-vous au passage sur quel support vous travailler ?).
Pour répondre directement à votre question sur le changement des étapes/états, il vous faut un debouncing (anti-rebond) pour mieux gérer vos clics.

à bientôt

[Matt_Houston]

Procède toujours par étapes.

Je pense que tu cibles mal le problème rencontré, qu'en conséquence, tu le présentes mal et obtiens peu de réponses. Pourtant tu décris bien ton problème de départ et tu donnes beaucoup d'informations. Beaucoup trop.

Considère-moi par exemple : j'ai auparavant lu ton sujet avec seulement quelques minutes devant moi. Je suis passé par les phases suivantes en quelques secondes : « oh.. un énorme diagramme en Grafcet », puis « bof.. je n'ai pas fait de Grafcet depuis l'IUT » et enfin « allez.. je vais laisser celui-là aux pros de l'embarqué ».

Alors qu'au final, après sélection des informations pertinentes, ta question se borne à l'implémentation d'une machine à états en langage C.

Ma méthode :

1. abstraire les détails d'implémentation : retire tous ces GPIO_*, mets-les ailleurs, je veux pas les voir au milieu de la logique ;
2. implémenter la logique pure, séparément : écris la machine à états et son algorithme indépendemment de l'implémentation sous-jacente des opérations qu'elle devra réaliser, proprement avec des enum clairs pour les états et transitions ;
3. simuler le fonctionnement de l'automate : exécute le programme à blanc, en remplaçant les vraies actions par des timers et des printf par exemple ;
4. connecter l'implémentation : remplace l'implémentation bidon utilisée lors du test précédent par ce que je t'ai dit de dégager à l'étape 1 ;
5. réaliser des tests unitaires : assure-toi du bon fonctionnement de chaque module en testant toutes les fonctions une à une, en écrivant un petit programme pour chacune si nécessaire.

[jerepout]

Merci pour vos réponses. J'ai suivi vos conseils, je pense que le problème vient de la détection du front descendant.

[sambia39]

Bonsoir,
Quand bien même on pourrait utiliser une machine à état qui modélise bien un comportement séquentiel. On oublie très souvent que les boutons-poussoir qui sont des commutateurs simples peuvent être sujets à de nombreuses oscillations parasites dus au rebondissement d’où ma réponse précédente et je m’explique. Lorsque l’actionneur qui compose le bouton-poussoir est actionné, l’action déclenchée ne se fait pas de manière immédiate; tout simplement parce qu'il y a au moment du relâchement de l’actionneur, une multitude d’oscillations qui s’effectue en une toute petite " fraction/milliseconde" et donc au moment où se produit cet événement d’oscillation (parasite), vous avez un signal réel d’entrée qui n’est pas tout a fait (si je peux le dire) Tout Ou Rien; mettant dans un état quelconque, votre variable et c’est peut-être le résultat de cet état quelconque que vous obtenez. Pour éviter les rebondissements, s’offrent à vous deux solutions. La première qui est d’ordre de la programmation et la plus simple car, elle ne nécessite pas d’intervention sur votre prototype. Cela consiste tout simplement à effectué/séparer deux lectures successives de l’action. En plus simple, la lecture de la même action à des intervalles différents ainsi vous pourrez alors vous affranchir du phénomène jusque là; exemple d’implémentation qui est un exemple et qui peut comporter des erreurs.

Code Algo :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
EtatCommutateur EST_DU_TYPE ENTIER
EtatCommutateur_Passer EST_DU_TYPE ENTIER
Etat_Action EST_DU_TYPE NOMBRE

DEBUT_ALGORITHME_DU_SPEUDO_ALGORITHME:
  TANT_QUE (1) FAIRE:
    DEBUT_TANT_QUE
    		EtatCommutateur PREND_LA_VALEUR (de grandeur physique d'entrée)
    		SI ((1 == EtatCommutateur) && (0 == EtatCommutateur_Passer))) ALORS
      		DEBUT_SI:
      			Etat_Action PREND_LA_VALEUR  1 - Etat_Action 
      	        FIN_SI
      	
    		EtatCommutateur_Passer = EtatCommutateur
   
    		SI (1 == Etat_Action) ALORS
    			DEBUT_SI:
    				ACTION_X
    			FIN_SI
    		SINON
    			NO_ACTION_X
    FIN_TANT_QUE
    
FIN_ALGORITHME

L’autre solution consiste soit à utiliser des RS/des RC avec des triggers par exemple, mais cela sous-entend qu’il faut peut-être revoir la réalisation du montage ou l'adapté.
À bientôt.

[Vincent PETIT]

Salut,
Je ne vois aucune interruption dans le programme initial. Il s'agit d'une gestion par polling (detection2 est appelé en boucle dans le main) et c'est très différent d'une gestion par interruption. Autre point, comment sorts tu de detection2 avec un while(1) à l'intérieur ?

Comme dit avant moi, il faut revoir entièrement la conception du programme qui, en l'état actuel, semble être partie dans une impasse.

[jerepout]

Bonjour,
déjà merci pour ces réponses. Ensuite, j'ai revu mon programme et maintenant j'arrive à passer de "mode en mode". (Un mode constituant une couleur de LED , un moteur allumé pendant un temps propre au mode choisit).
Maintenant,je souhaite intégré un second bouton qui "force l'arrêt" de ces programme. Seulement, je n'arrive pas à établir de priorité. Voici le code que j'ai écris:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
 
void main (void) {	
	int d=0;
	bool i = FALSE;
	int mode;
	static int StatoIn;
  int choix=0;
 
  CLK_Config();   
	GPIO_Config();
	TIM1_Config(); 
	TIM4_Config();  
	enableInterrupts();
 
  //detection_front_montant();
  //detection();
 
while(1){
	//wfi();
int w;	
 
if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE){
	 choix++;                        
 
 
  if(choix>4)choix=0;
		switch(choix)
		{
		case 1:	 
		for (d=0;d<20000;d++){
			    GPIO_WriteHigh(GPIOB,GPIO_PIN_1);
			  	GPIO_WriteHigh(GPIOC,GPIO_PIN_1);
					GPIO_WriteLow(GPIOB,GPIO_PIN_2);
					GPIO_WriteLow(GPIOB,GPIO_PIN_3);
					}break; 
 
		case 2:
		for (d=0;d<20000;d++){
			  GPIO_WriteHigh(GPIOC,GPIO_PIN_1);
	      GPIO_WriteHigh(GPIOB,GPIO_PIN_2);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_1);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_3);
	      }break;
		case 3:
		for (d=0;d<20000;d++){
			  GPIO_WriteHigh(GPIOC,GPIO_PIN_1);
	      GPIO_WriteHigh(GPIOB,GPIO_PIN_3);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_1);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_2);
	      }break;
		case 4:
		for (d=0;d<20000;d++){
			  GPIO_WriteHigh(GPIOC,GPIO_PIN_1);
	      GPIO_WriteHigh(GPIOB,GPIO_PIN_3);
	      GPIO_WriteHigh(GPIOB,GPIO_PIN_1);
	      GPIO_WriteHigh(GPIOB,GPIO_PIN_2);
	      }break;
	}
}
 
if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_6) == FALSE){
 
	      GPIO_WriteLow(GPIOC,GPIO_PIN_1);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_1);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_2);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_3);	
}   
 
}
 
}

[Vincent PETIT]

Salut,
Bonne idée la machine a état (le switch/case) c'est souvent l'idéal sur un microcontrôleur, c'est simple et redoutablement efficace.

Par contre, tu ne gères toujours pas tes boutons par des interruptions mais toujours par du polling dans le soft. C'est souvent très embêtant car si l'utilisateur appuie juste avant ou juste après le if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE) le programme ne le verra pas. Souvent le polling fonctionne tout de même mais sache que tu ne maîtrises pas grand choses pour ne pas dire que c'est grandement de la chance dans bien des cas de figures.


Pourquoi le polling est hasardeux ?

- Le programme est souvent court et comme il tourne en boucle, il passe de ce fait rapidement sur if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE) et ça fonctionne. Sauf que plus ton programme va grandir et plus il se passera de temps entre deux if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE) au risque de louper un appuie sur le bouton, par l'utilisateur. Si jamais du place des tempos dans ton programme, tu vas encore plus accentuer ce problème.

- Le fantôme de l'anti-rebond naturel est lié a l'incidence de que j'ai écrit au dessus, plus il se passe de temps entre deux if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE) et plus on se moque des rebonds car ils arriveront entre deux lectures du bouton. Il arrive très souvent qu'on en arrivera à négliger carrément ce problème de rebond puisqu'il ne pose pas de problèmes, jusqu'au jour où le programme se raccourcisse (optimisation ? mise à jour ? modification ?) ce qui va diminuer le temps entre deux if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE) et là on peut tomber sur un rebond que le programme pensera être un appuie.

- On compte souvent sur l'utilisateur pour que le temps d'appui sur l'interrupteur soit relativement long sauf que rien en le garantie et que le jour à ce n'est pas un homme qui appuie sur le bouton mais que tu lis un signal logique, un état haut ou un état bas comme un bouton, suivant sa rapidité il y a toutes les chances que la version polling te fasse le rater, en tombant pas mal chance entre deux if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE), et tout dépendra de la taille de ton programme et des tempos.

Personnellement j'ai toujours gérer mes interrupteurs par des interruptions. Bref !


Tu peux faire ça je pense :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_6) == FALSE){
 
	      choix = 0; // on s'arrête
 
	      GPIO_WriteLow(GPIOC,GPIO_PIN_1);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_1);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_2);
	      GPIO_WriteLow(GPIOB,GPIO_PIN_3);	
 
}

[jerepout]

D'abord, merci de ta réponse.
J'ai essayé ta proposition avec le choix =0; mais rien ne se passe lors d'un appui sur ce bouton. Si je comprends bien, il serait bien plus judicieux de gérer par des interruptions. Comment puis-je les définir ? Je dois créer des fonctions propres aux interruptions ?
Puis jepartir du code avec mes switchs?

[Vincent PETIT]

Donne nous le schéma du hard pour qu'on voit les boutons poussoirs, dit nous aussi le micro sur le quel tu travailles et avec quel compilateur (avec de la chance j'ai peut être déjà bossé dessus).

Oui il faut partir sur la machine a état donc le switch/case et moi je partirai sur une gestion avec des interruptions pour ne pas devoir tout refaire parce que le programme devient trop grand et trop long. Dit toi que la méthode polling veut que ton programme soit capable de détecter l'appuie sur le bouton uniquement quand il rencontre cette ligne if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE). Avant ou après celle-ci le micro fait autre chose et si jamais ce autre chose dure longtemps bah l'utilisateur n'a plus qu'a rester appuyer en attendant que le programme repasse par la ligne qui lit l'état du bouton.

[jerepout]

Alors je travailles sur un stm8s, et je compile avec STVisual Develop ( Cosmic). Je souhaite donc par plusieurs appuis choisir un mode, puis l'arrêter avec un autre bouton. Je vais m'intéresser ce soir à ta méthode.
ENsuite, voici mon schéma représentant la logique que je voudrais faire :

[Vincent PETIT]

Alors je travailles sur un stm8s

Le quel exactement ? C'est pour voir qu'est ce qu'il est capable de faire en terme d'interruption, tous les micros ne sont pas capables des mêmes choses.

et je compile avec STVisual Develop ( Cosmic).

Je ne connais pas du tout ce compilateur et j'espère réussir au moins à trouver une doc sinon je ne vais rien pouvoir faire En fait je veux voir comment on déclare une interruption par exemple, etc... et ça c'est typique au compilateur.

ENsuite, voici mon schéma représentant la logique que je voudrais faire

Ok mais je voulais d'abord voir le schéma électronique, je te fais confiance mais il n'y a rien de plus frustrant de tourner en rond sur le soft pendant des jours alors que le problème est sur le hard (oublie d'une résistance de rappel, résistance trop élevée, présence ou pas d'un condensateur anti-rebond pour s'épargner de faire un debouncer soft, ...)

[jerepout]

Alors c'est un STM8S003K3(discovery) et il me semble que la déclaration de s interruptions se fait telle quel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
INTERRUPT_HANDLER(EXTI_PORTA_IRQHandler, 3)
{
  }

[jerepout]

[Vincent PETIT]

Re,
C'est quoi ces condensateurs C1, C2 et C7 qui ne sont pas reliés ? C'est pour faire un anti-rebond hard ? Tu voulais générer une impulsion brève avec un circuit CR ? Genre ça ?


Si c'est ça alors ça génère une impulsion très brève (en rouge) que tu as toutes les chances de louper en faisant du polling dans le soft. De plus, tu as une impulsion négative dont il faut te protéger via une diode par exemple, sans ça elle peut casser le micro. C'est l'exemple parfait de ce que j'avais écrit plus haut !

[...] et que le jour où ce n'est pas un homme qui appuie sur le bouton mais que tu lis un signal logique, un état haut ou un état bas comme un bouton, suivant sa rapidité il y a toutes les chances que la version polling te fasse le rater, en tombant par mal chance entre deux if(GPIO_ReadInputPin(GPIOD, GPIO_PIN_7) == FALSE) [...]

Voici une config d'anti-rebond plus conventionnel :


On voit la gestion de l'anti-rebond dans la décharge exponentielle de la capa, qui dure grosso modo 50ms (bien sur c'est à ajuster en fonction de la durée réelle des rebonds).


Du coup on a déjà un problème hardware a régler pour être sur de ne pas tourner en rond des semaines entières dans le soft alors que le problème est bel et bien en dehors.
As tu la main sur le hard ? Est ce que tu peux mettre un condo de 100nF comme sur le schéma juste au dessus ?

[jerepout]

Oui, c'était pour gérer mon anti-rebond. Je vais de ce pas modifier mon montage. Merci

En ce qui concerne le soft,
je pense que je dois établir des priorités au niveau de mes boutons non ?
Que par exemple, le bouton stop, soit prioritaire au bouton On.

[sambia39]

En ce qui concerne le soft,
je pense que je dois établir des priorités au niveau de mes boutons non ?
Que par exemple, le bouton stop, soit prioritaire au bouton On.

C’est-à-dire les IRQ?
Alors si c’est pour gère les IRQ, vous serez obligé de revoir l’ensemble du code. À vue d’œil, les IRQ ici peuvent être utilisés pour la température, niveaux d'eau et le bouton-stop. Honnêtement, commencez par faire plus simple. Commencer à gérer l'interruption d'une tâche à tout moment peut importer le bouton puis évoluer au fur.

[Vincent PETIT]

[...] il me semble que la déclaration de l'interruptions se fait telle quel :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
INTERRUPT_HANDLER(EXTI_PORTA_IRQHandler, 3)
{
 
}

C'est possible, je ne connais absolument pas ce compilateur et il n'a pas l'air de courir les rues car je ne trouve pas beaucoup de doc, ni d'exemples, ni d'explications. La syntaxe ne ressemble ni au compilateur Keil, ni IAR, ni MPLABX , ni GCC !?

En ce qui concerne le soft,
je pense que je dois établir des priorités au niveau de mes boutons non ?
Que par exemple, le bouton stop, soit prioritaire au bouton On.

Oui c'est l'idée et ça se fait de différentes manières en fonction du micro car tous ont des astuces qui facilitent la vie mais pour le savoir il faut se taper la datasheet du micro et chez ST.

Avant ça il faut être sur que tu as mis les interrupteurs sur des entrées interruptibles (sur le schéma que tu as posté je n'arrive pas à lire le nom des broches)

Il faut configurer le types d'interruptions, par exemple on peut déclencher une interruption sur un front montant, un front descendant, les deux à la fois.

Suivant comment on déclare une interruption avec ton compilateur, dès qu'il y aura un appuie sur le bouton sur le port A par exemple, le programme principal main va se stopper et tu vas atterrir directement ici :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
INTERRUPT_HANDLER(EXTI_PORTA_IRQHandler, 3)
{
   //trouver quelle broche a causé l'interruption
}

Par contre, je ne sais pas d'où sort ce micro mais c'est bizarre que je ne trouve quasiment aucune ressource sur le net ? Ton micro sait gérer des priorités d'interruptions mais je ne trouve pas d'exemples et le peu d'explications dans la doc ne permet pas de clairement comprendre de quoi il en retourne. J'ai toujours trouvé les doc de chez ST, pas clairs mais là ça m'étonne de ne pas comprendre a ce point là !

[jerepout]

D'accord sambia. Mais justement pour l'instant, j'ai essayé d'incorporer un deuxième bouton, mais rien ne se passe lors d'un appui de ce dernier qui doit effectuer la fonction stop.

Je suis totalement d'accord avec toi Vincent en ce qui concerne la doc mais je n'ai pas le choix, je suis obligé d'utiliser ce microcontroleur. Je vais mettre en application ce que tu viens de me renseigner. merci infiniment pour ton aide.

[Vincent PETIT]

Juste pour information :
Voici un exemple clair mais je ne pense pas qu'il a été fait avec ton compilateur car toute la syntaxe est quasiment la même que celle que j'utilise avec les micros MSP430 ou ATMEGA

http://blog.mark-stevens.co.uk/2012/...-on-the-stm8s/

ps : la doc du micro pour que les lecteurs sachent de quel document nous parlons : https://www.st.com/content/ccc/resou...CD00190271.pdf