Discussion :

[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

[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 )

[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