const int led = 13;
Esse é o método correto. Ou até:
const byte led = 13;
Quantos pinos você tem?
Alguns dos tutoriais não passaram pelo controle de qualidade que poderiam ter.
O desempenho será melhor usando const byte, compare com into compilador, no entanto, pode ser inteligente o suficiente para perceber o que você está fazendo.
O que você pode fazer é incentivar gentilmente as pessoas a usar técnicas mais eficientes, usando-as em seu próprio código.
Respostas aos comentários
Um comentarista sugeriu que bytenão é o padrão C. Isso está correto, no entanto, este é um site do Arduino StackExchange, e acredito que o uso de tipos padrão fornecidos pelo IDE do Arduino seja aceitável.
No Arduino.h existe esta linha:
typedef uint8_t byte;
Observe que isso não é exatamente o mesmo que unsigned char. Consulte uint8_t vs char não assinado e Quando uint8_t char char não assinado? .
Outro comentarista sugeriu que o uso de byte não melhorará necessariamente o desempenho, porque números menores do que intserão promovidos para int(consulte Regras de Promoção Inteira, se você quiser saber mais sobre isso).
No entanto, no contexto de um identificador const , o compilador irá gerar código eficiente em qualquer caso. Por exemplo, desmontar "piscar" fornece isso na forma original:
00000086 <loop>:
86: 8d e0 ldi r24, 0x0D ; 13
88: 61 e0 ldi r22, 0x01 ; 1
8a: 1b d1 rcall .+566 ; 0x2c2 <digitalWrite>
De fato, gera o mesmo código se 13:
- É um literal
- É um
#define
- É um
const int
- É um
const byte
O compilador sabe quando pode caber um número em um registro e quando não pode. No entanto, é uma boa prática usar codificação que indique sua intenção . Tornar constclaro que o número não será alterado e deixar claro byte(ou uint8_t) deixa claro que você espera um número pequeno.
Mensagens de erro confusas
Outro motivo importante para evitar #definesão as mensagens de erro que você recebe se cometer um erro. Considere este esboço "intermitente" que possui um erro:
#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);
}
Na superfície, parece bom, mas gera as seguintes mensagens de erro:
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
Você olha para a primeira linha destacada (linha 4) e nem vê o símbolo "=". Além disso, a linha parece bem. Agora é bastante óbvio qual é o problema aqui ( = 13está sendo substituído LED), mas quando a linha está 400 linhas mais abaixo no código, não é óbvio que o problema está na maneira como o LED é definido.
Já vi pessoas se apaixonarem por isso muitas vezes (inclusive eu).