Discussion :

[JPP3939]

Bonjour,

J'ai essayé de faire un programme pour allumer une led dès que je touche un GPIO touch du Teensy LC hors quand je téléverse le programme dans la Teensy LC, la led s'allume direct et ne s'éteint jamais même quand je touche le GPIO touch. Je pense que mon programme est faux, puis-je avoir de l'aide pour le réussir? merci

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
int ledPin = 11;
int touchPin = touchRead(1);
const int threshold = 30;
 
 
void setup() {
  Serial.begin(9600);
  // initialize the digital pin as an output.
  pinMode(ledPin, OUTPUT);
  pinMode(touchPin, OUTPUT);
}
void loop() {
  { touchPin = touchRead(1);
    Serial.print(touchPin);
    if (touchPin < threshold)
    digitalWrite(ledPin, LOW);   // set the LED on
    else (touchPin > threshold);
    digitalWrite(ledPin, HIGH);
  }
}

[Jay M]

à mon avis ça ce n'est pas bon

Code :

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

 pinMode(touchPin, OUTPUT);

vous avez une pin en entrée.
si je me souviens bien, il ne faut rien mettre du tout

Si vous faites tourner ce code et regardez la console série à 115200 bauds, ça vous dit quoi?

Code :

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

1
2
3
4
5
6
7
8
9
10
const uint8_t touchPin = 1; 
 
void setup() {
  Serial.begin(115200); 
}
 
void loop() {
  Serial.println(touchRead(touchPin)); 
  delay(100); 
}

[JPP3939]

Bonsoir ,

Comment ça il ne faut rien mettre dutout ?

Ca me donne ça, le rouge c'est quand je touche pas et le orange quand je touche.

[Jay M]

Rien mettre du tout comme pinMode()

Donc ça fonctionne bien - on voit bien quand vous touchez ou pas

[Guesset]

Bonjour,

Le code initial ne peut pas fonctionner (en outre pourquoi autant d'accoladses et aussi peu d'indentations ?) :

Code C++ :

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

1
2
3
4
5
6
7
8
void loop() {
   touchPin = touchRead(1);
   Serial.print(touchPin);
   if (touchPin < threshold)
      digitalWrite(ledPin, LOW);   // set the LED on
   else (touchPin > threshold);    // ??? (touchPin > threshold); ne sert à rien mais termine les tests
   digitalWrite(ledPin, HIGH);     // Sera donc toujours exécutée ! Led éteinte (le temps entre allumage/extinction très court
}

Plutôt écrire quelque chose comme :

Code C++ :

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

1
2
3
4
5
void loop() {
   touchPin = touchRead(1);       // touchPin devrait plutôt s'appeler touchVal
   Serial.print(touchPin);
   digitalWrite(ledPin, touchPin > threshold);   // touchPin > threshold == 1 si vrai (led éteinte) et == 0 si faux (led allumée)
}

Salutations

[Jay M]

Code C++ :

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

digitalWrite(ledPin, touchPin > threshold);   // touchPin > threshold == 1 si vrai (led éteinte) et == 0 si faux (led allumée)

pour le respect des types et des API documentées on préfèrera écrire

Code :

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

 digitalWrite(ledPin, touchPin > threshold ? HIGH : LOW);

[JPP3939]

Bonjour,

J'ai testé avec touchPin et touchVal mais ca me met comme erreur pour les deux :

Code :

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

1
2
3
4
5
6
7
Code_moi_2: In function 'void loop()':
Code_moi_2:11: error: assignment of read-only variable 'touchPin'
     touchPin = touchRead(1);
 
              ^
 
assignment of read-only variable 'touchPin'

Et je dois aussi enlever les pinMode() ?

[Guesset]

Bonjour,

Dans la déclaration, il faut juste écrire :

Code C++ :

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

1
2
3
int touchVal;   // Pourrait être également déclarée dans loop() puisqu'il ne sert que là.
const int touchPin = 1;
...

Et dans loop():

Code C++ :

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

1
2
3
4
5
void loop() {
   touchVal = touchRead(touchPin);       // touchPin devrait plutôt s'appeler touchVal
   Serial.print(touchVal);
   digitalWrite(ledPin, touchVal > threshold);   // touchPin > threshold == 1 si vrai (led éteinte) et == 0 si faux (led allumée)
}

En ce qui concerne l'écriture proposée par Jay, cela se discute. Il n'y a pas de problème de type car HIGH et LOW ne sont pas des types mais des alias. Pour la bonne compréhension, l'écriture de Jay est nettement préférable. Pour l'efficacité, l'écriture élidée sera certainement traduite par un code plus efficient (à vérifier selon l'optimisation du compilateur). Pour moi, c'est un choix de style que chacun fait selon ses goûts et objectifs .

Salutations

[Jay M]

bravo !

bonne soirée

[Jay M]

Salut

En fait je crois qu'on est d'accord sur le fond:

Comme l'avait dit Donald Knuth (en reprenant Tony Hoare) "Premature Optimization Is the Root of All Evil" (même s'il ne faut pas non plus faire n'importe quoi sous prétexte que l'on optimisera plus tard).

Bien sûr lorsqu'on développe pour micro-contrôleur souvent il faut faire attention à la mémoire et au temps d'exécution. Si l'écriture "correcte" n'était pas assez rapide ou trop gourmande en mémoire parce que l'optimiseur n'a pas "vu" comment faire, alors bien sûr on peut prendre des optimisations quand on sait ce que l'on fait. Mais dans ce cas avant de dépendre d'effets de bords sur HIGH et LOW, je pense que j'enlèverai l'appel à digitalWrite() pour utiliser directement les PORTS...

En pratique on est d'accord sur le fait que votre approche fonctionne aujourd'hui et sans doute encore pour longtemps vu les dépendances et l'historique qui entraineraient des conséquences sur de nombreux codes si cela venait à être modifié.

Là où on n'est peut-être pas d'accord c'est plus conceptuel et un respect des bonnes pratiques: Comme le C++ est beaucoup plus typé que le langage C (et que ce typage fort est de plus en plus imposé par les compilateurs), essayer de respecter la cohérence des types en C++ est pour moi important pour éviter des soucis dans le futur et former "les apprentis développeurs" aux bonnes pratiques. Par exemple utiliser des effets de bords (la dépendance à des valeurs non documentées si ce n'est en regardant dans le code) n'est pas considéré comme une bonne pratique. C'est pour cela qu'ici je ne le recommanderai pas votre raccourci dans un code qui a vocation d'exemple pour un débutant.


----------------------------------------

Sinon long débat sur votre point

Si j'écris : byte a = 1; le compilateur ne passera pas par la case "1 est un entier" avant de se raviser à l'optimisation.

Je pense qu'on est d'accord mais ça dépend de ce que vous entendez par là.

Si vous voulez dire qu'il ne génère pas le code tout de suite avec un entier puis ensuite génère encore plus de code pour transformer les 2 ou 4 octets en 1 seul octets et espérer que l'optimiseur ensuite fasse le ménage, on est d'accord.

Schématiquement le compilateur (le parser) va d'abord évaluer l'expression et bâtir un arbre de représentation. l'opération est '=' avec 2 feuilles à gauche et à droite.
Le compilateur évalue d'abord la feuille de droite. il n'y a pas d'opération à droite et voit une rvalue (techniquement une constante littérale de type entier), donc pour le moment il la conserve comme rvalue typée. Ensuite il regarde à gauche et comme c'est une affectation attend une lvalue (un endroit en mémoire), ici c'est simple, on a une variable donc directement la lvalue.

Cet arbre n'est pas OK tel quel puisque le type sous jacent de la rvalue n'est pas identique à celui de la lvalue. Le compilateur déclenche donc ses règles de conversion implicites. La règle dit que le programme ne peut compiler que s'il existe une séquence de conversion implicite non ambiguë du premier type vers le second type. Ici le compilateur applique la règle dite de "Lvalue to rvalue conversion" et commence par regarder la règle de "Numeric promotions". Mais ici comme le type à droite est "plus petit" que le type à gauche, il appliquera la règle de "Numeric conversions" qui peut conduire à de la perte d'information et modification de la valeur. Le compilateur - au vu des types - détecte que la règle applicable est la suivante:

If the destination type is unsigned, the resulting value is the smallest unsigned value equal to the source value modulo 2ⁿ where n is the number of bits used to represent the destination type.

Comme on a une rvalue de type littéral sur 2 octets, le compilateur sait prendre tout seul l'octet de poids faible (il connait directement la valeur) et génère le code d'affectation à la mémoire associée à la lvalue a dont il connait aussi l'adresse. Si ce n'était pas un littéral mais une autre variable, il aurait aussi su aller chercher uniquement l'octet correspondant au poids faible donc sans appliquer de masque non plus. Si c'était un calcul, il aurait une représentation dans un ou plusieurs registres du résultat du calcul et saurait quel est l'octet là encore qui représente le poids faible et donc n'affecterait que celui là.

Quand je fais

Code :

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

digitalWrite(ledPin, touchVal > threshold);

ce sont d'autres règles qui s'appliquent:

le compilateur doit évaluer les paramètres à mettre sur la pile pour appeler la fonction.
il voit `touchVal > threshold` et donc c'est une opération transitoire de type rvalue (pas de mémoire associée). L'arbre correspond à un opérateur '>' et deux lvalue. le type du résultat, porté par le noeud du graphe lié au >, est une rvalue de type booléen.

le compilateur sait qu'il doit générer un test et disposera dans un registre transitoire du booléen vrai ou faux.

Il voit ensuite que cette rvalue doit être affectée sur la pile à une lvalue de type uint8_t. Il n'y a pas égalité de type donc il doit faire appel aux "Implicit conversions" et ce coup ci la règle qui s'applique n'est plus une transformation numérique mais une règle d'abord spécifique aux booléens qui dit

the type bool can be converted to int with the value false becoming ​0​ and true becoming 1

donc il sait obtenir un type entier (une rvalue de type littéral) et ensuite il sait transformer (par la même règle que la règle précédente) cet entier sur plusieurs octets en un seul octet en prenant l'octet de poids faible.

C'est ce qu'il fait et vous avez donc 0 ou 1 sur la pile, sous forme d'un seul octet et votre code fonctionne parce que "par chance" HIGH c'est 1 et LOW c'est 0.

dans ma version plus compliquée des choses avec l'opérateur ternaire

Code :

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

touchPin > threshold ? HIGH : LOW

l'arbre d'évaluation est plus compliqué: il a comme racine l'opérateur ternaire et attend à gauche un booléen et à droite deux expressions.

Je vous passe le cheminement des conversions et règles appliquées par le compilateur, elles sont identiques à celles que l'on a vu plus haut, mais comme les expressions que l'on retourne suivant le booléen sont aussi des constantes littérales, là c'est l'optimiseur qui va faire son travail et identifier que le résultat est équivalent à celui de la promotion du booléen. L'optimiseur va aussi aller plus loin et in-liner la fonction digitalWrite() sans doute plutôt que de faire un appel d'ailleurs

bref - si vous avez la variable (lvalue) b de type booléen en mémoire à l'adresse 0x100 et que vous faites

Code :

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

digitalWrite(13, b);

ou

Code :

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

digitalWrite(13, b ? HIGH : LOW);

, l'assembleur généré pour le second paramètre sera simplement similaire à un

Code :

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

 lds r18, 0x0100

c'est à dire que l'on va chercher un octet en mémoire qui est simplement l'octet reprenant b. c'est ce registre qui sera ensuite utilisé

Même coût informatiquement parlant, mais une version est plus "maintenable" et lisible que l'autre à mon avis et donc devrait avoir la préférence du développeur.

[Guesset]

Bonjour,

Nous sortons un peu du sujet initial aussi je m'arrêterai là.

Que le compilateur fasse sa cuisine n'a pas tellement d'importance. Deux compilateurs différents respectant la même version du langage à traiter auront des résultats identiques (pour peu qu'ils soient de même qualité). Ceci indépendamment d'une représentation interne différente (par exemple avec des entiers internes sous 64 bits ou 32 bits). Je peux écrire un compilateur dans n'importe quel langage pour n'importe quelle cible. Son propre code n'est pas assujetti au langage cible tant qu'il fournit ce qu'on attend de lui (il y a des outils de développement de compilateurs ou translateurs qui peuvent générer du java ou du c indifféremment). Ainsi en est-il du typage interne.

Ceci étant, je respecte le code proposé et l'attachement à la forme.

Salut.

[Jay M]

oui on s'éloigne

je respecte le code proposé et l'attachement à la forme

C'était ce que je voulais dire
si on veut ne pas dépendre de constantes "non documentées", c'est mieux

[kaitlyn]

Salut,

Tu ne peux pas lui reprocher la conversion (implicite) bool int. À la rigueur le postulat sur HIGH et LOW ok, ça, ça peut se comprendre, dans ce cas une simple compilation conditionnelle qui vérifie cette assertion réglera le problème.

[Jay M]

—— Hors sujet - donc dernier post de ma part sur ce thème ——

Salut kaitlyn

Qu'on soit clair - je ne reprochais rien, chacun fait bien comme il veut.

Je proposais (ou du moins j'essayais de proposer) une alternative avec

pour le respect des types et des API documentées on préfèrera écrire

que pour un code qui a vocation d'exemple, respecter les types me semble une bonne idée et passer un booléen en dépendant de la promotion implicite (tout à fait officielle) qui est sans doute une notion qui dépasse les connaissances de JPP n'était pas idéal (outre la dépendance aux valeurs des constantes HIGH et LOW).

la doc dit

Syntax
digitalWrite(pin, value)

Parameters
pin: the Arduino pin number.
value: HIGH or LOW.

donc rien ne dit que value est de type entier.

Comme expliqué par ailleurs sur la notion du respect des types, si d'aventure HIGH et LOW devenaient membre d'un bête enum comme proposé dans le Arduino Core

Code :

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

1
2
3
4
5
6
7
 typedef enum {
  LOW     = 0,
  HIGH    = 1,
  CHANGE  = 2,
  FALLING = 3,
  RISING  = 4,
} PinStatus;

C++ n'accepterait plus la conversion implicite d'une constante littérale entière vers une des constantes énumérées (warning sur AVR, erreur de la compilation sur ESP/ARM). La conversion implicite à elle seule ne suffit donc pas toujours.

[Guesset]

Bonjour,

Dans Arduino.h on a : void digitalWrite(uint8_t pin, uint8_t val);

Donc même si la doc laisse penser à tort que HIGH et LOW sont (ou appartiennent à) des types à part entière, ce ne sont que des alias qui seront remplacés par les caractères 1 ou 0 là où le préprocesseur les rencontrera dans le source. Dans le cas de digitalWrite ces valeurs sont de facto des uint_8 (bytes).

Je sais que j'avais dit arrêter mais c'est dur de lutter contre les addictions

Une remarque, je ne vois pas comment l'enum proposé pourrait fonctionner. En effet, une variable de ce type ne peut prendre que l'une des valeurs. Or en cas de FALLING ou RISING il y a également CHANGE ce qui ne paraît pas très cohérent.

Salutations

[kaitlyn]

Salut,

Dans Arduino.h on a : void digitalWrite(uint8_t pin, uint8_t val);

Ce n'est pas ça le problème. Ce qu'il y a, c'est que par rapport à la lib arduino, le code de @Jay se base sur son interface, telle que présentée par la documention, alors que toi tu te bases sur son implémentation. Si cette dernière venait à changer, ton code ne serait plus compatible. Ça veut dire que si demain Arduino change l'alias de LOW en (-1) histoire de faire simple, ton code source ne fonctionnera plus comme attendu, celui de @Jay si.
C'est pour ça que dans mon précédent message je parle de la compilation conditionnelle. Elle consiste à dire au compilateur OK, je pars du principe que HIGH est un alias de 1 et LOW de 0, merci de le vérifier pour moi avant de compiler le code. Évidemment ça n'empêchera pas la nécessité de remanier le code en cas d'échec, mais ça évitera bien des surprises et surtout on saura pourquoi il faut le faire.

[Guesset]

Bonjour kaitlyn,

Ce n'est pas ça le problème. Ce qu'il y a, c'est que par rapport à la lib arduino, le code de @Jay se base sur son interface, telle que présentée par la documention, alors que toi tu te bases sur son implémentation.

Sur le principe, je suis d'accord mais comme cela les amènerait à reprendre également le code des divers fonctions les utilisant, les rendant moins efficaces car in fine c'est toujours un 0 ou un 1 qui va être modifié dans un registre, je suppose qu'il va se passer du temps avant. En fait je compte, peut être à tort, sur le pragmatisme. C'est vrai que quand je vois une énumération qui mélange états et transitions (ce qui implique deux états), je devrais peut être me méfier.

La solution de la compilation conditionnelle est sympathique mais quitte à ajouter du code autant prendre la solution de Jay ou un casting explicite du booléen.

Salut et merci

[Jay M]

les rendant moins efficaces

En pratique l’optimiseur fait le job. Donc ce n’est pas moins efficace

[Jay M]

Si vous regardez dans le code du core, ils changeraient aussi la signature et l'utiliseraient pour les interruptions aussi

Code :

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

1
2
3
void digitalWrite(pin_size_t pinNumber, PinStatus status);
 
void attachInterrupt(pin_size_t interruptNumber, voidFuncPtr callback, PinStatus mode);

certaines valeurs "légales" sont donc un peu incohérentes pour un digitalWrite() mais la doc dit HIGH ou LOW et de ne pas utiliser autre chose.


Vous avez raison, si on met le nez dans le code on voit bien que ce que vous proposez fonctionnera. Mais l'idée c'est de dépendre plus de la documentation que du code à un instant T. (même si la doc Arduino laisse vraiment souvent à désirer, voire est erronée ou incomplète).


Promis j'arrête demain ( pareil ici )