Apa cara terbaik untuk mendefinisikan pin I / O?


9

Saya membaca definisi suka

const int ledPin = 9;

dan juga

#define ledPin 9

Saya tahu bahwa definisi suka

int ledPin = 9;

adalah praktik yang buruk jika Anda tidak akan mengubahnya (yang biasanya tidak Anda lakukan), meskipun saya sudah melihat ini beberapa kali dalam program Arduino. Yang mana dari dua lainnya yang lebih disukai?

Jawaban:


6

#define ledPin 9lebih disukai. Dengan melakukan int ledPin = 9;Anda akan mengalokasikan intmemori yang nilainya digunakan setiap kali Anda menggunakan ledPin. #defineberbeda dalam arti tidak mengalokasikan memori. tidak ada memori yang dipanggil ledPin. Sebelum mengkompilasi semua "ledPin" dalam kode (selain string) diganti dengan 9. Pada dasarnya

digitalWrite(ledPin);

menjadi

digitalWrite(9);

Keuntungan dari #define: Menghemat memori dan karena semua ledPindiganti oleh 9 sebelum eksekusi , ini menghemat waktu prosesor.

Tidak terlalu penting dalam kode kecil ...


Apakah kompiler tertanam sangat buruk sehingga mereka tidak melakukan pelipatan konstan saat menggunakan const int?
Chuu

1
@ chuu sejauh yang saya tahu Arduino menggunakan gcc untuk avr. Jadi hampir harus dioptimalkan. Jawaban di sini tidak menunjukkan banyak pemahaman tentang praktik yang baik dalam C ++
chbaker0

3
di C ++, const int ledPin = 9;lebih disukai dari 2 opsi lain. Ini TIDAK akan mengalokasikan memori untuk intkecuali jika Anda menetapkan pointer ke suatu tempat, yang tidak akan dilakukan siapa pun.
jfpoilpret

Kon int tidak mengalokasikan memori @jfpoilpret. #define tidak mengambil memori apa pun karena itu hanya nama simbol dari sebuah ekspresi dan bukan nama memori ...

Lihat tautan ini cplusplus.com/forum/beginner/28089 dan buktikan sendiri. Jika tidak, cukup lakukan pemeriksaan dengan IDE Arduino: periksa ukuran data dengan const dan dengan #define.
jfpoilpret

4

Sebenarnya, #definependekatan ini akan menggunakan memori yang sedikit lebih sedikit. Perbedaannya biasanya kecil. Jika Anda perlu mengurangi penggunaan memori, maka optimasi lain mungkin akan jauh lebih efektif.

Argumen yang mendukung penggunaan const intadalah tipe safety . Di mana pun Anda merujuk nomor pin itu dengan variabel, Anda tahu persis tipe data apa yang Anda peroleh. Mungkin dipromosikan / dikonversi secara implisit atau eksplisit oleh kode yang menggunakannya, tetapi harus berperilaku dengan cara yang sangat jelas.

Sebaliknya, nilai dalam a #defineterbuka untuk interpretasi. Sebagian besar waktu, mungkin tidak akan menimbulkan masalah sama sekali bagi Anda. Anda hanya perlu sedikit berhati-hati jika memiliki kode yang membuat asumsi tentang jenis atau ukuran nilainya.

Secara pribadi, saya hampir selalu lebih suka tipe keselamatan kecuali saya memiliki kebutuhan yang sangat serius untuk menghemat memori.


Saya berada di kamp #define sampai saya membaca jawaban Peter. Kira saya tahu siapa yang akan menjadi kode refactoring akhir pekan ini. ;)
linhartr22

2

Mungkin cara terbaik adalah
const uint8_t LED_PIN = 9; // may require to #include <stdint.h>
atau
const byte LED_PIN = 9; // with no include necessary
const unsigned char LED_PIN = 9; // similarly
Nama dalam huruf besar sesuai praktik umum dalam C ++ (dan lainnya) untuk menyebutkan konstanta. Ini seharusnya tidak menggunakan RAM apa pun dalam dirinya sendiri, dan menggunakan sekitar 1 byte memori program per penggunaan.
Namun, mungkin ada masalah ketika jumlahnya lebih tinggi dari 127 dan diperpanjang tanda saat dipromosikan menjadi bilangan bulat yang lebih besar (tidak sepenuhnya yakin akan hal ini), meskipun itu tidak mungkin terjadi dengan nomor pin.


-1

Tidak hanya akan

const int ledPin = 9;

mengambil RAM, tetapi dalam kasus ini, akan menggunakan lebih banyak RAM daripada yang diperlukan karena digitalWrite(uint8_t, uint8_t)hanya membutuhkan argumen satu byte, dan int biasanya dua byte (bergantung pada compiler, tetapi tipikal). Perhatikan bahwa Anda dapat memberikan literal jenis eksplisit di #define:

#define ledPin ((int)9) 

meskipun dalam konteks seperti argumen fungsi di mana jenis tertentu diperlukan (karena fungsi itu benar prototyped!) baik akan secara implisit dilemparkan atau mendapatkan pesan kesalahan jika jenis tidak cocok.


@DrivebyDownvoter, maukah Anda mengomentari alasan Anda?
JRobert
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.