Discussion :

[bm]

bonjour,


Je n'ai pas énoncé le dispositif à la première publication de ce post.

On cherche à réaliser un dispositif avec une entrée et deux sorties.
L'entrée (Pous1) reçoit un signal rectangulaire, dont la fréquence peut
varier de 1 à 100 Hz. La première sortie (Led1) doit s'activer si le rapport
cyclique est inférieur à 40%, la seconde (Led2)s'il est supérieur à 60%.
S'il n'y a pas de signal, ou si le signal est carré, aucune sortie ne doit
s'activer.

[Vincent PETIT]

Salut,
Il y a plusieurs choses que je ne comprends pas dans ton programme ou alors il n'y a pas tout.

L'algorithme est bon car luminosité va de 0 à 255 puis il décroît jusque 0 (c'est une forme de triangle). Si tu as branché une Led sur une sortie PWM du micro et avec une résistance adéquate pour faire passer 20mA dans la Led alors ça devrait fonctionner. La luminosité devrait varier.

Par contre si l'objectif est de faire varier le PWM pourquoi vouloir éteindre et allumer d'autres Led ? Elles sont reliées ou ? Et c'est quoi Led1on ?

[bm]

C'est une étape .. mais il faut passer par un timer que je n'ai jamais encore programmé.

On cherche à réaliser un dispositif avec une entrée et deux sorties.
L'entrée (Pous1) reçoit un signal rectangulaire, dont la fréquence peut
varier de 1 à 100 Hz. La première sortie (Led1) doit s'activer si le rapport
cyclique est inférieur à 40%, la seconde (Led2)s'il est supérieur à 60%.
S'il n'y a pas de signal, ou si le signal est carré, aucune sortie ne doit
s'activer.

Pin 2 (Pous1) est une entrée digitale et c'est une association avec un timer plus rapide
qui va compter les signaux low et hight entrant sur pin 2.
Le cycle après calcul du %, activera les Led1On/Off et Led2On/Off dans les bons intervalles

Ma carte est arduino uno.

nb : je n'ai pas de générateur de fréquence pour une simulation, et je ne vois pas comment
vérifier quoique ce soit

@+

[Vincent PETIT]

Je comprends un peu mieux mais il me manque des infos.

Je vois que tu fais "analogWrite(Pous2, luminosite); "
Pourquoi ? Tu génère un pwm qui va où ? Tu veux générer un signal rectangulaire que tu viendras lire sur une entrée de capture Pous1 ?
C'est pour toi remplacer un générateur de signaux ?

Tu veux faire un espèce de fréquencemètre ?

[Vincent PETIT]

Ton programme fonctionne bien.
3 choses a regarder :

1 - Le câblage des LED 1 et 2 a moins qu'elles ne soient déjà intégrées sur le Arduino (je ne sais pas, je ne l'utilise pas)

2 - Les #define de Led1on, Led1off etc... afin de s'assurer qu'ils fonctionnent tous

3 - Passer le delay(300) à 500ms car si ça va trop vite, il se peut que tu ne le vois pas (c'est la persistance rétinienne)

Tiens nous au courant.
A+

[Auteur]

bonjour,

ce qui m'ennuie dans ce code c'est l'absence de la fonction setup() J'aimerai bien voir ce qu'elle contient.
Led1Off, Led2On, Led1On, Led2Off c'est quoi ? Car en l'état, dans le code, ça n'a aucun sens.

@Vincent PETIT : une seule LED est intégrée sur la carte, sur le pin13.

[Vincent PETIT]

Salut Auteur,
Merci pour cette précision. Je pense que notre ami a récupérer un code qu'il souhaite adapter à son problème.

[deletme]

Bonjour,

Pourrais-tu poster la totalité de ton code, surtout la fonction setup ?

Pour ton problème de générateur de PWM, tu pourrais simplement relier une sortie PWM sur une entrée Analogique ? Je vais voir si électroniquement il n'y pas de problèmes.

[bm]

On cherche à réaliser un dispositif avec une entrée et deux sorties.
L'entrée (Pous1) reçoit un signal rectangulaire, dont la fréquence peut
varier de 1 à 100 Hz. La première sortie (Led1) doit s'activer si le rapport
cyclique est inférieur à 40%, la seconde (Led2)s'il est supérieur à 60%.
S'il n'y a pas de signal, ou si le signal est carré, aucune sortie ne doit
s'activer.

AnalogWrite c'était pour simuler un rapport cyclique avec pwm.
Mais ce qu'il faut réaliser est une sorte de fréquence-mètre qui allume Led 1-2.
C'est réalisable sans timer, mais vu que je suit un mooc qui propose en semaine 5 :
timer, tables, moyenne, ce mooc continue avec surtout du bricolage sans correction type.

Code :

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
/*
 
FREQUENCE ET RAPPORT CYCLIQUE
  
*/
 
#define Led1 4 // actif à 1
#define Led2 5 // actif à 1
#define Pous1 2 // actif à 0
#define Pous2 3 // actif à 0
#define Pous1On !digitalRead (Pous1) // actif à 0
#define Pous2On !digitalRead (Pous2) // actif à 0
#define Led1On digitalWrite (Led1, HIGH)
#define Led1Off digitalWrite (Led1, LOW)
#define Led2On digitalWrite (Led2, HIGH)
#define Led2Off digitalWrite (Led2, LOW)
#define Tempo delay(50)
#define SensorPin A0 // entrée potentiomètre
 
long haut=0;
long bas=0;
float cycle=0;
 
void setup() { 
 
    pinMode (Pous1, INPUT) ;
    pinMode (Pous2, INPUT) ;
    pinMode (Led1,OUTPUT) ;
    pinMode (Led2,OUTPUT) ;  
}
 
 
void loop() {
 
for (int i=1; i <= 5; i++){ 
        delay(1);
	if (Pous1On) {bas=bas+1;}
}
 
for (int i=1; i <= 5; i++){ 
        delay(1);
	if (!Pous1On) {haut=haut+1;}
}
cycle=float(bas)/float(haut);
 
bas=0,haut=0;
if(cycle>0 && cycle<0.4){Led1On;Led2Off;}
if(cycle>0.6){Led1Off;Led2On;}
if(cycle==0){Led1Off;Led2Off;}
if(cycle>=0.4 && cycle<=0.6){Led1Off;Led2Off;}
 
}

Feedback : Le programme ne differencie pas les rapports cycliques
En augmentant la borne max de la boucle i, la détection est plus mauvaise
Feedback Le programme ne detecte par correctement les signaux

[Auteur]

Euh, personnellement, je ne comprends plus rien. A quoi correspond ce second code ? Il n'a rien à voir avec le premier.

Explique nous clairement ce qui pose problème.

[bm]

Si c'était limpide avec une méthode, les microcontrôleurs seraient tous
programmés avec du langage C.

Je vais poster le sujet dans le forum C, si il y a des susceptibilités dans ce forum.

nb : C'est assez simple à réaliser avec une interruption matérielle

[Vincent PETIT]

AnalogWrite c'était pour simuler un rapport cyclique avec pwm.

Ok alors il faut le garder pour debuger ton programme.

Mais ce qu'il faut réaliser est une sorte de fréquence-mètre qui allume Led 1-2.

Ok pour l'exposé du problème.

C'est réalisable sans timer

C'est très aléatoire sans timer et ça marchera par coup de chance.
Ton programme fait du pooling et c'est la pire manière de faire. Pour te donner une image du pooling dans la vie de tous les jours :
Imagine que tu veuilles parler au facteur pendant qu'il met du courrier dans ta boîte aux lettres. Le facteur passe à 10h00 et met 5 secondes pour faire ça puis il repart. Si tu fais du pooling, tu décides de ne pas regarder ta montre et de sortir toutes les 3min quand tu penses qu'il est environ l'heure de son passage, en espérant tomber sur le facteur. Nous sommes tous d'accord pour dire que si tu tombes sur le facteur, c'est un coup de bol ! Parfois ça marchera, parfois pas, des fois tu sortiras 1 seconde après son départ, des fois tu rentreras juste quand il arrivera....

Dans mon exemple le "toi" est le fréquence-mètre, le facteur sont les front montant et descendant du signal PWM et le fait de ne pas regarder sa montre c'est faire du pooling donc sans timer.

mais vu que je suit un mooc qui propose en semaine 5 :
timer, tables, moyenne, ce mooc continue avec surtout du bricolage sans correction type.

Je ne comprends pas ce que tu as écrit.

Feedback : Le programme ne differencie pas les rapports cycliques
En augmentant la borne max de la boucle i, la détection est plus mauvaise
Feedback Le programme ne detecte par correctement les signaux

C'est normal !

Il faut utiliser un timer avec une entrée interruptibles sur front.

[bm]

Change : Combine le mode Rising et Falling. En conséquence, la fonction d'interruption est appelée à chaque fois que le
signal change (de Haut vers Bas ou de Bas vers Haut).

attachInterrupt( 0, Cycle, CHANGE ); // pin 2 est attaché à une interruption

Après c'est une gestion avec un index.

[Résolu]

[sevyc64]

Imagine que tu veuilles parler au facteur pendant qu'il met du courrier dans ta boîte aux lettres. Le facteur passe à 10h00 et met 5 secondes pour faire ça puis il repart. Si tu fais du pooling, tu décides de ne pas regarder ta montre et de sortir toutes les 3min quand tu penses qu'il est environ l'heure de son passage, en espérant tomber sur le facteur. Nous sommes tous d'accord pour dire que si tu tombes sur le facteur, c'est un coup de bol ! Parfois ça marchera, parfois pas, des fois tu sortiras 1 seconde après son départ, des fois tu rentreras juste quand il arrivera....

Dans mon exemple le "toi" est le fréquence-mètre, le facteur sont les front montant et descendant du signal PWM et le fait de ne pas regarder sa montre c'est faire du pooling donc sans timer.

De manière générale, le pooling est une méthode "bon marché". C'est plus simple à mettre en œuvre que de l'évènementiel par exemple, mais ça consomme des ressources inutilement.
Donc lorsque le processus n'a rien d'autre à faire qu'attendre et lorsque la consommation de ressources superflues n'est pas un problème, le pooling peut être mis en œuvre, sinon il faudrait envisager autre chose.

Pour que le pooling fonctionne, il faut que la fréquence de scrutation de l'évènement soit plus élevée que la durée de cet événement de sorte que tout le temps que durera l'évènement que l'on veut intercepter on vienne potentiellement le scruter plusieurs fois pour être sur de ne pas le louper (on prend une certaine marge). Généralement, on prend un facteur d'au minimum 8 à 10.

Dans l'exemple donné, le facteur reste 5 sec. Donc pour être certain de l'attraper avec un facteur 10, il ne faut pouvoir scrutter la boite aux lettres au moins 10 fois durant une période de 5 secondes. Il faudra donc scruter toutes les 500ms.


Dans le cas d'un traitement évènementiel, nul besoin de scruter, on peut faire autre chose, ne pas se soucier de l'arrivée du facteur. Par contre, quand le facteur arrivera, on sera interrompu quoique l'on fasse et on ira voir celui-ci quelque soit la situation. Dommage si c'est le moment ou on est sur le trône ou sous la douche
Il peut y avoir des situations critiques ou l’interruption n'est pas la bien venue mais c'est généralement toujours une meilleure solution que le pooling.

[Vincent PETIT]

De manière générale, le pooling est une méthode "bon marché". C'est plus simple à mettre en œuvre que de l'évènementiel par exemple, mais ça consomme des ressources inutilement.
Donc lorsque le processus n'a rien d'autre à faire qu'attendre et lorsque la consommation de ressources superflues n'est pas un problème, le pooling peut être mis en œuvre, sinon il faudrait envisager autre chose.

Pour que le pooling fonctionne, il faut que la fréquence de scrutation de l'évènement soit plus élevée que la durée de cet événement de sorte que tout le temps que durera l'évènement que l'on veut intercepter on vienne potentiellement le scruter plusieurs fois pour être sur de ne pas le louper (on prend une certaine marge). Généralement, on prend un facteur d'au minimum 8 à 10.

Salut sevyc64,
Ma réponse concernait le problème du fréquence mètre.

Effectivement, le pooling est la méthode que l'on utilise lorsque l'on fait de l'échantillonnage avec un ADC par exemple. Le théorème de Shannon http://fr.wikipedia.org/wiki/Th%C3%A...yquist-Shannon dit que pour échantillonner un signal il faut que la fréquence d'échantillonnage soit supérieur au double de la fréquence max du signal a échantillonner. Et pour échantillonner correctement un signal moi aussi je sur-échantillonne à 10x la fréquence du signal a échantillonner. Par contre cette méthode donne une représentation discrète du signal et ne permet pas de répondre à l'énoncé qu'avait donné bm (car trop précis)

La première sortie (Led1) doit s'activer si le rapport
cyclique est inférieur à 40%, la seconde (Led2)s'il est supérieur à 60%.
S'il n'y a pas de signal, ou si le signal est carré, aucune sortie ne doit
s'activer.

Par contre tu as raison, j'aurai expliquer pourquoi le pooling était la pire manière de faire dans ce cas très précis.
A+

[bm]

Avec une interruption et sa fonction, le codage est le suivant avec un flag
CHANGE ne distingue pas les fronts montant/descendant

Je ne vois pas comment rendre plus compact le rapport(cyclique)
qui n'est pas satisfaisant pour toutes les fréquences :

Code :

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
/*
 
FREQUENCE ET RAPPORT CYCLIQUE ( AVEC INTERRUPTION )
  
*/
 
#define Led1 4 // actif à 1
#define Led2 5 // actif à 1
#define Pous1 2 // actif à 0
#define Pous2 3 // actif à 0
#define Pous1On !digitalRead (Pous1) // actif à 0
#define Pous2On !digitalRead (Pous2) // actif à 0
#define Led1On digitalWrite (Led1, HIGH)
#define Led1Off digitalWrite (Led1, LOW)
#define Led2On digitalWrite (Led2, HIGH)
#define Led2Off digitalWrite (Led2, LOW)
 
float rapport;
unsigned long chrono1;
unsigned long chrono2;
unsigned long chrono3;
byte inter=0;
byte pass=0;
 
void cyc(){
inter=1; // activé sur la pin 2 qui est un poussoir Pous1 (arduino UNO)
}
 
void setup() { 
    pinMode (Led1,OUTPUT) ;
    pinMode (Led2,OUTPUT) ;  
    Serial.begin(9600);// moniteur série
    attachInterrupt(0,cyc,CHANGE);
}
 
void loop() {
 
if(inter==1 && pass==0 ){
chrono1=millis();
inter=0;
pass=1;
 
}
if(inter==1 && pass==1 ){
chrono2=millis();
inter=0;
pass=2;
 
}
if(inter==1 && pass==2 ){
chrono3=millis();
inter=0;
pass=0;
 
}
 
rapport=float(chrono2-chrono1)/float(chrono3-chrono1);
if(rapport>0 && rapport<0.4){Led1On;Led2Off;}
if(rapport>0.6 && rapport<=1){Led1Off;Led2On;}
if(rapport==0){Led1Off;Led2Off;}
if(rapport>=0.4 && rapport<=0.6){Led1Off;Led2Off;}
 
}