Cách tốt nhất để xác định chân I / O là gì?


9

Tôi đọc các định nghĩa như

const int ledPin = 9;

và cũng

#define ledPin 9

Tôi biết rằng một định nghĩa như

int ledPin = 9;

là một thực tế tồi nếu bạn sẽ không thay đổi nó (mà bạn thường không làm), mặc dù tôi đã thấy điều này nhiều lần trong các chương trình Arduino. Mà một trong hai người kia được ưa thích?

Câu trả lời:


6

#define ledPin 9được ưa thích. Bằng cách thực hiện, int ledPin = 9;bạn sẽ phân bổ một intbộ nhớ có giá trị được sử dụng mỗi khi bạn sử dụng ledPin. #definelà khác nhau theo nghĩa nó không phân bổ bộ nhớ. không có bộ nhớ gọi ledPin. Trước khi biên dịch tất cả các "ledPin" trong mã (trừ chuỗi) được thay thế bằng 9. Nên về cơ bản

digitalWrite(ledPin);

trở thành

digitalWrite(9);

Ưu điểm của #define: Tiết kiệm bộ nhớ và vì tất cả ledPinđược thay thế bằng 9 trước khi thực hiện , nó giúp tiết kiệm thời gian xử lý.

Không thực sự quan trọng trong các mã nhỏ ...


Các trình biên dịch nhúng có thực sự tệ đến mức chúng không thực hiện gập liên tục khi sử dụng const int?
Chuu

1
@chuu theo như tôi biết Arduino sử dụng gcc cho avr. Vì vậy, nó gần như chắc chắn sẽ được tối ưu hóa. Các câu trả lời ở đây không cho thấy nhiều hiểu biết về thực hành tốt trong C ++
chbaker0

3
trong C ++, const int ledPin = 9;được ưu tiên hơn 2 tùy chọn khác. Điều này sẽ KHÔNG phân bổ bộ nhớ cho intngoại trừ nếu bạn xác định một con trỏ tới nó ở đâu đó, điều mà không ai sẽ làm.
jfpoilpret

Const int không cấp phát bộ nhớ @jfpoilpret. #define không chiếm bất kỳ bộ nhớ nào vì nó chỉ là một tên biểu tượng của một biểu thức chứ không phải tên của một bộ nhớ ...

Kiểm tra liên kết này cplusplus.com/forum/beginner/28089 và tự mình xem. Mặt khác, chỉ cần thực hiện kiểm tra với Arduino IDE: kiểm tra kích thước dữ liệu với const và với #define.
jfpoilpret

4

Nói đúng ra, #definecách tiếp cận sẽ sử dụng ít bộ nhớ hơn. Sự khác biệt thường là nhỏ mặc dù. Nếu bạn cần giảm sử dụng bộ nhớ, thì việc tối ưu hóa khác có thể sẽ hiệu quả hơn nhiều.

Một đối số có lợi cho việc sử dụng const intloại an toàn . Bất cứ nơi nào bạn đề cập đến số pin đó theo biến, bạn sẽ biết chính xác loại dữ liệu bạn nhận được. Nó có thể được quảng bá / chuyển đổi ngầm định hoặc rõ ràng bởi mã sử dụng nó, nhưng nó nên hành xử theo những cách rất rõ ràng.

Ngược lại, giá trị trong a #definelà mở để giải thích. Phần lớn thời gian, nó có thể sẽ không gây ra cho bạn bất kỳ vấn đề nào cả. Bạn chỉ cần cẩn thận một chút nếu bạn có mã đưa ra các giả định về loại hoặc kích thước của giá trị.

Cá nhân, tôi hầu như luôn thích loại an toàn trừ khi tôi có nhu cầu rất nghiêm trọng để tiết kiệm bộ nhớ.


Tôi đã ở trong trại #define cho đến khi tôi đọc câu trả lời của Peter. Đoán tôi biết ai sẽ tái cấu trúc mã vào cuối tuần này. ;)
linhartr22

2

Có lẽ cách tốt nhất sẽ là
const uint8_t LED_PIN = 9; // may require to #include <stdint.h>
hoặc
const byte LED_PIN = 9; // with no include necessary
const unsigned char LED_PIN = 9; // similarly
Tên được đặt theo mũ theo thông lệ chung trong C ++ (và các tên khác) để đặt tên hằng. Điều này không nên sử dụng bất kỳ RAM nào và sử dụng khoảng 1 byte bộ nhớ chương trình cho mỗi lần sử dụng.
Tuy nhiên, có thể có vấn đề khi số cao hơn 127 và được gia hạn đăng nhập trong khi được thăng cấp lên số nguyên có chữ ký lớn hơn (không hoàn toàn chắc chắn về điều này), mặc dù điều đó khó xảy ra với số pin.


-1

Không chỉ sẽ

const int ledPin = 9;

chiếm RAM, nhưng trong trường hợp này, sẽ sử dụng nhiều RAM hơn mức cần thiết vì digitalWrite(uint8_t, uint8_t)chỉ cần đối số một byte và int thường là hai byte (phụ thuộc vào trình biên dịch, nhưng điển hình). Lưu ý rằng bạn có thể cung cấp loại chữ rõ ràng trong #define:

#define ledPin ((int)9) 

mặc dù trong ngữ cảnh như đối số hàm trong đó yêu cầu một loại cụ thể (vì hàm được tạo nguyên mẫu chính xác!), nó sẽ được đặt ngầm hoặc nhận thông báo lỗi nếu các loại không khớp.


@DrivebyDownvoter, bạn có thể nhận xét về lý do của bạn?
JRobert
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.