Sử dụng các biến toàn cục trong Hệ thống nhúng

Tôi bắt đầu viết firmware cho sản phẩm của mình và tôi là một tân binh ở đây. Tôi đã đi qua nhiều bài viết về việc không sử dụng các biến hoặc hàm toàn cầu. Có giới hạn nào cho việc sử dụng các biến toàn cục trong hệ thống 8 bit hay không hoặc nó hoàn toàn là 'Không-Không'. Tôi nên sử dụng các biến toàn cục trong hệ thống của mình như thế nào hoặc tôi nên tránh hoàn toàn chúng?

Tôi muốn nhận lời khuyên có giá trị từ các bạn về chủ đề này để làm cho phần sụn của tôi nhỏ gọn hơn.

Bạn có thể sử dụng các biến toàn cục thành công, miễn là bạn ghi nhớ các nguyên tắc của @ Phil. Tuy nhiên, đây là một số cách hay để tránh các vấn đề của họ mà không làm cho mã được biên dịch trở nên nhỏ gọn hơn.

1. Sử dụng các biến tĩnh cục bộ cho trạng thái liên tục mà bạn chỉ muốn truy cập bên trong một hàm.

   #include <stdint.h>
   void skipper()
   {
       static uint8_t skip_initial_cycles = 5;
       if (skip_initial_cycles > 0) {
           skip_initial_cycles -= 1;
           return;
       }
       /* ... */
   }

2. Sử dụng một cấu trúc để giữ các biến liên quan với nhau, để làm cho nó rõ ràng hơn ở nơi chúng nên được sử dụng và nơi không.

   struct machine_state {
        uint8_t level;
        uint8_t error_code;
   } machine_state;
   
   struct led_state {
       uint8_t red;
       uint8_t green;
       uint8_t blue;
   } led_state;
   
   void machine_change_state()
   {
       machine_state.level += 1;
       /* ... */
       /* We can easily remember not to use led_state in this function. */
   }
   
   void machine_set_io()
   {
       switch (machine_state.level) {
       case 1:
           PIN_MACHINE_IO_A = 1;
           /* ... */
       }
   }

3. Sử dụng các biến tĩnh toàn cục để làm cho các biến chỉ hiển thị trong tệp C hiện tại. Điều này ngăn chặn truy cập ngẫu nhiên bằng mã trong các tệp khác do xung đột đặt tên.

   /* time_machine.c */
   static uint8_t current_time;
   /* ... */
   
   /* delay.c */
   static uint8_t current_time; /* A completely separate variable for this C file only. */
   /* ... */

Như một lưu ý cuối cùng, nếu bạn đang sửa đổi một biến toàn cục trong một thói quen ngắt và đọc nó ở nơi khác:

• Đánh dấu biến volatile.
• Hãy chắc chắn rằng nó là nguyên tử cho CPU (tức là 8 bit cho CPU 8 bit).

HOẶC LÀ

• Sử dụng một cơ chế khóa để bảo vệ quyền truy cập vào biến.

Những lý do bạn không muốn sử dụng các biến toàn cục trong hệ thống 8 bit giống như bạn không muốn sử dụng chúng trong bất kỳ hệ thống nào khác: chúng khiến việc lập luận về hành vi của chương trình trở nên khó khăn.

Chỉ những lập trình viên tồi mới bị treo lên theo các quy tắc như "không sử dụng biến toàn cục". Lập trình viên giỏi hiểu lý do đằng sau các quy tắc, sau đó đối xử với các quy tắc giống như hướng dẫn hơn.

Chương trình của bạn có dễ hiểu không? Là hành vi của nó có thể dự đoán được? Có dễ dàng để sửa đổi các phần của nó mà không phá vỡ các phần khác? Nếu câu trả lời cho mỗi câu hỏi này là có , thì bạn đang trên đường đến một chương trình tốt.

Bạn hoàn toàn không nên tránh sử dụng các biến toàn cục (gọi tắt là "toàn cầu"). Nhưng, bạn nên sử dụng chúng một cách thận trọng. Các vấn đề thực tế với việc sử dụng quá mức toàn cầu:

• Globals có thể nhìn thấy trong suốt đơn vị biên dịch. Bất kỳ mã nào trong đơn vị biên dịch có thể sửa đổi toàn cục. Hậu quả của việc sửa đổi có thể xuất hiện ở bất cứ nơi nào mà toàn cầu này được đánh giá.
• Kết quả là toàn cầu làm cho mã khó đọc và hiểu hơn. Lập trình viên luôn phải ghi nhớ tất cả những nơi mà toàn cầu được đánh giá và phân công.
• Việc sử dụng quá mức toàn cầu làm cho mã dễ bị lỗi hơn.

Đó là một cách thực hành tốt để thêm tiền tố g_vào tên của các biến toàn cục. Ví dụ , g_iFlags. Khi bạn thấy biến có tiền tố trong mã, bạn ngay lập tức nhận ra rằng đó là toàn cầu.

Ưu điểm của cấu trúc dữ liệu toàn cầu trong công việc nhúng là chúng là tĩnh. Nếu mọi biến bạn cần là toàn cục, thì bạn sẽ không bao giờ vô tình hết bộ nhớ khi các chức năng được nhập và không gian được tạo cho chúng trên ngăn xếp. Nhưng sau đó, tại thời điểm đó tại sao có chức năng? Tại sao không phải là một chức năng lớn xử lý tất cả logic và quy trình - như chương trình BASIC không cho phép GOSUB. Nếu bạn đưa ý tưởng này đủ xa, bạn sẽ có một chương trình hợp ngữ điển hình từ những năm 1970. Hiệu quả, và không thể duy trì và rắc rối bắn.

Vì vậy, hãy sử dụng toàn cầu một cách thận trọng, như các biến trạng thái (ví dụ: nếu mọi hàm cần biết hệ thống đang ở trạng thái diễn giải hay chạy trạng thái) và các cấu trúc dữ liệu khác cần được xem bởi nhiều hàm và như @PhilFrost nói, là hành vi của chức năng của bạn có thể dự đoán? Có khả năng lấp đầy ngăn xếp với một chuỗi đầu vào không bao giờ kết thúc không? Đây là những vấn đề cho thiết kế thuật toán.

Lưu ý rằng tĩnh có ý nghĩa khác nhau bên trong và bên ngoài một chức năng. /programming/5868947/difference-b between-static-variable-inside-and-outide-of-a-hàm

/programming/5033627/static-variable-inside-of-a-f ghép-in-c

Biến toàn cầu chỉ nên được sử dụng cho nhà nước toàn cầu thực sự. Sử dụng một biến toàn cục để biểu thị một cái gì đó như ví dụ vĩ độ của ranh giới phía bắc của bản đồ sẽ chỉ hoạt động nếu chỉ có thể có một "ranh giới phía bắc của bản đồ". Nếu trong tương lai, mã có thể phải hoạt động với nhiều bản đồ có ranh giới phía bắc khác nhau, mã sử dụng biến toàn cục cho ranh giới phía bắc có thể sẽ cần phải được làm lại.

Trong các ứng dụng máy tính thông thường, thường không có lý do cụ thể nào để cho rằng sẽ không bao giờ có nhiều hơn một thứ gì đó. Tuy nhiên, trong các hệ thống nhúng, các giả định như vậy thường hợp lý hơn nhiều. Mặc dù có thể một chương trình máy tính thông thường có thể được yêu cầu hỗ trợ nhiều người dùng đồng thời, giao diện người dùng của một hệ thống nhúng thông thường sẽ được thiết kế để hoạt động bởi một người dùng tương tác với các nút và màn hình. Như vậy, bất cứ lúc nào nó cũng có một trạng thái giao diện người dùng. Thiết kế hệ thống sao cho nhiều người dùng có thể tương tác với nhiều bàn phím và màn hình sẽ đòi hỏi sự phức tạp hơn rất nhiều và mất nhiều thời gian hơn để thực hiện, hơn là thiết kế nó cho một người dùng. Nếu hệ thống không bao giờ được yêu cầu hỗ trợ nhiều người dùng, bất kỳ nỗ lực bổ sung nào được đầu tư để tạo điều kiện cho việc sử dụng như vậy sẽ bị lãng phí. Trừ khi có khả năng sẽ cần hỗ trợ nhiều người dùng, sẽ có nguy cơ khôn ngoan hơn khi phải loại bỏ mã được sử dụng cho giao diện một người dùng trong trường hợp cần hỗ trợ nhiều người dùng, hơn là dành thêm thời gian để thêm nhiều người hỗ trợ người dùng có thể sẽ không bao giờ cần thiết.

Một yếu tố liên quan với các hệ thống nhúng là trong nhiều trường hợp (đặc biệt là liên quan đến giao diện người dùng), cách thực tế duy nhất để hỗ trợ có nhiều hơn một thứ sẽ là sử dụng nhiều luồng. Trong trường hợp không có một số nhu cầu khác về đa luồng, có lẽ nên sử dụng một thiết kế đơn luồng đơn giản hơn là tăng độ phức tạp của hệ thống với đa luồng có thể không bao giờ thực sự cần thiết. Nếu thêm nhiều hơn một thứ gì đó sẽ yêu cầu thiết kế lại hệ thống khổng lồ, thì nó cũng không thành vấn đề nếu nó cũng yêu cầu làm lại việc sử dụng một số biến toàn cục.

Rất nhiều người nhầm lẫn về chủ đề này. Định nghĩa của một biến toàn cục là:

Một cái gì đó có thể truy cập từ mọi nơi trong chương trình của bạn.

Đây không giống như các biến phạm vi tệp , được khai báo bởi từ khóa static. Chúng không phải là biến toàn cục, chúng là biến riêng cục bộ.

 int x; // global variable
 static int y; // file scope variable

 void some_func (void) {...} // added to demonstrate that the variables above are at file scope.

Bạn có nên sử dụng các biến toàn cầu? Có một vài trường hợp là ổn:

• Các biến chỉ đọc có thể là toàn cục. Bài liên quan với thông tin chi tiết về chủ đề đó
• Các thanh ghi phần cứng tương ứng với bản đồ đăng ký MCU của bạn có thể là toàn cầu.

Trong mọi trường hợp khác, bạn sẽ không sử dụng các biến toàn cục. Không bao giờ có một lý do để làm như vậy. Thay vào đó sử dụng các biến phạm vi tập tin , đó là hoàn toàn tốt.

Bạn nên cố gắng viết các mô-đun mã độc lập, tự trị được thiết kế để thực hiện một nhiệm vụ cụ thể. Trong các mô-đun đó, các biến phạm vi tệp nội bộ sẽ nằm trong các thành viên dữ liệu riêng tư. Phương pháp thiết kế này được gọi là hướng đối tượng và được công nhận rộng rãi là thiết kế tốt.