const int led = 13;
C'est la bonne méthode. Ou même:
const byte led = 13;
Combien de broches avez-vous?
Certains didacticiels n'ont pas tout à fait subi autant de contrôle de la qualité qu'ils auraient pu.
Les performances seront meilleures à utiliser const byte, comparez à, intmais le compilateur peut être suffisamment intelligent pour réaliser ce que vous faites.
Ce que vous pouvez faire est d'encourager doucement les gens à utiliser des techniques plus efficaces en les utilisant dans votre propre code.
Réponses aux commentaires
Un commentateur a suggéré que ce byten'est pas la norme C. C'est correct, mais il s'agit d'un site Arduino StackExchange, et je pense que l'utilisation de types standard fournis par l'IDE Arduino est acceptable.
Dans Arduino.h, il y a cette ligne:
typedef uint8_t byte;
Notez que ce n'est pas exactement le même que unsigned char. Voir uint8_t vs caractère non signé et quand uint8_t char caractère non signé? .
Un autre intervenant a suggéré que l'utilisation d'octets n'améliorera pas nécessairement les performances, car des nombres plus petits que ceux intqui seront promus int(voir Règles de promotion d'entiers si vous en voulez plus).
Cependant, dans le contexte d'un identificateur const , le compilateur générera un code efficace dans tous les cas. Par exemple, le démontage du "clignotement" donne ceci sous la forme originale:
00000086 <loop>:
86: 8d e0 ldi r24, 0x0D ; 13
88: 61 e0 ldi r22, 0x01 ; 1
8a: 1b d1 rcall .+566 ; 0x2c2 <digitalWrite>
En fait, il génère le même code que 13:
- Est un littéral
- Est un
#define
- Est un
const int
- Est un
const byte
Le compilateur sait quand il peut rentrer un nombre dans un registre et quand il ne le peut pas. Cependant, il est recommandé d'utiliser un codage qui indique votre intention . Le faire constindique clairement que le nombre ne changera pas et le fait byte(ou uint8_t) indique clairement que vous attendez un petit nombre.
Messages d'erreur déroutants
Une autre raison majeure à éviter #defineest les messages d'erreur que vous obtenez si vous faites une erreur. Considérez ce croquis "clignotant" qui a une erreur:
#define LED = 13;
void setup() {
pinMode(LED, OUTPUT); // <---- line with error
}
void loop() {
digitalWrite(LED, HIGH); // <---- line with error
delay(1000);
digitalWrite(LED, LOW); // <---- line with error
delay(1000);
}
En surface, il semble OK, mais il génère ces messages d'erreur:
Blink.ino: In function ‘void setup()’:
Blink:4: error: expected primary-expression before ‘=’ token
Blink:4: error: expected primary-expression before ‘,’ token
Blink:4: error: expected `;' before ‘)’ token
Blink.ino: In function ‘void loop()’:
Blink:8: error: expected primary-expression before ‘=’ token
Blink:8: error: expected primary-expression before ‘,’ token
Blink:8: error: expected `;' before ‘)’ token
Blink:10: error: expected primary-expression before ‘=’ token
Blink:10: error: expected primary-expression before ‘,’ token
Blink:10: error: expected `;' before ‘)’ token
Vous regardez la première ligne en surbrillance (ligne 4) et ne voyez même pas de symbole "=". De plus, la ligne semble bien. Maintenant, il est assez évident de savoir quel est le problème ici ( = 13est remplacé LED), mais lorsque la ligne se trouve 400 lignes plus loin dans le code, il n'est pas évident que le problème réside dans la façon dont la LED est définie.
J'ai vu des gens tomber à plusieurs reprises (y compris moi-même).