Qual è il modo migliore per definire un pin I / O?


9

Ho letto definizioni come

const int ledPin = 9;

e anche

#define ledPin 9

So che una definizione piace

int ledPin = 9;

è una cattiva pratica se non hai intenzione di cambiarlo (cosa che di solito non lo farai), anche se l'ho visto più volte nei programmi Arduino. Quale degli altri due è preferito?

Risposte:


6

#define ledPin 9è preferito. In questo modo int ledPin = 9;assegnerai una intmemoria il cui valore viene utilizzato ogni volta che lo usi ledPin. #defineè diverso nel senso che non alloca memoria. non c'è memoria chiamata ledPin. Prima di compilare tutti i "ledPin" nel codice (tranne le stringhe) sono sostituiti da 9. Quindi in poche parole

digitalWrite(ledPin);

diventa

digitalWrite(9);

Vantaggi di #define: consente di risparmiare memoria e poiché tutti ledPinsono sostituiti da 9 prima dell'esecuzione , consente di risparmiare tempo del processore.

Non importa davvero in piccoli codici ...


I compilatori incorporati sono davvero così male da non piegarsi costantemente durante l'uso const int?
Chuu,

1
@chuu per quanto ne so Arduino usa gcc per avr. Quindi dovrebbe quasi sicuramente essere ottimizzato. Le risposte qui non mostrano molta comprensione delle buone pratiche in C ++
chbaker0

3
in C ++, const int ledPin = 9;è preferito rispetto ad altre 2 opzioni. Questo NON alloca memoria per un inttranne se si definisce un puntatore ad esso da qualche parte, cosa che nessuno farebbe.
jfpoilpret,

Const int alloca memoria @jfpoilpret. #define non occupa memoria perché è solo un nome simbolico di un'espressione e non il nome di una memoria ...

Dai un'occhiata a questo link cplusplus.com/forum/beginner/28089 e vedi di persona. Altrimenti esegui semplicemente il controllo con Arduino IDE: controlla la dimensione dei dati con const e con #define.
jfpoilpret,

4

A rigor di termini, l' #defineapproccio utilizzerà un po 'meno memoria. La differenza è generalmente minuscola però. Se è necessario ridurre l'utilizzo della memoria, probabilmente altre ottimizzazioni sarebbero molto più efficaci.

Un argomento a favore dell'uso const intè la sicurezza dei tipi . Ovunque ti riferisca a quel numero di pin per variabile, sai esattamente quale tipo di dati stai ricevendo. Potrebbe essere promosso / convertito implicitamente o esplicitamente dal codice che lo utilizza, ma dovrebbe comportarsi in modo molto chiaro.

Al contrario, il valore in a #defineè aperto all'interpretazione. La maggior parte delle volte, probabilmente non ti causerà alcun problema. Devi solo stare un po 'attento se hai un codice che fa ipotesi sul tipo o sulla dimensione del valore.

Personalmente, preferisco quasi sempre la sicurezza dei tipi a meno che non abbia un bisogno molto serio di risparmiare memoria.


Ero nel campo #define finché non ho letto la risposta di Peter. Suppongo di sapere chi eseguirà il refactoring del codice questo fine settimana. ;)
linhartr22

2

Probabilmente il modo migliore sarebbe
const uint8_t LED_PIN = 9; // may require to #include <stdint.h>
o
const byte LED_PIN = 9; // with no include necessary
const unsigned char LED_PIN = 9; // similarly
Il nome è in maiuscolo come da pratica generale in C ++ (e altri) per nominare le costanti. Questo non dovrebbe usare alcuna RAM in sé e usare circa 1 byte di memoria del programma per uso.
Tuttavia, potrebbero esserci problemi quando il numero è superiore a 127 e viene esteso al segno mentre viene promosso a numeri interi con segno più grandi (non del tutto sicuro su questo), anche se è improbabile che ciò accada con i numeri di pin.


-1

Non solo lo farà

const int ledPin = 9;

occupa RAM, ma in questo caso utilizzerà più RAM del necessario in quanto digitalWrite(uint8_t, uint8_t)necessita solo di argomenti a un byte e un int di solito è di due byte (dipendente dal compilatore, ma tipico). Nota che puoi dare al letterale un tipo esplicito in #define:

#define ledPin ((int)9) 

anche se in un contesto come un argomento di funzione in cui è richiesto un tipo specifico (perché la funzione è stata correttamente prototipata!), verrebbe implicitamente lanciato o otterrebbe un messaggio di errore se i tipi non corrispondono.


@DrivebyDownvoter, vorresti commentare le tue ragioni?
JRobert,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.