Vấn đề

Trong ngữ cảnh nhúng trần kim loại cấp thấp , tôi muốn tạo một khoảng trống trong bộ nhớ, trong cấu trúc C ++ và không có bất kỳ tên nào, để cấm người dùng truy cập vào vị trí bộ nhớ đó.

Ngay bây giờ, tôi đã đạt được điều đó bằng cách đặt một uint32_t :96;bitfield xấu xí sẽ thuận tiện thay thế cho ba từ, nhưng nó sẽ đưa ra cảnh báo từ GCC (Bitfield quá lớn để vừa với uint32_t), điều này khá hợp pháp.

Mặc dù nó hoạt động tốt, nhưng nó không được sạch sẽ cho lắm khi bạn muốn phân phối một thư viện với hàng trăm cảnh báo đó ...

Làm thế nào để làm điều đó đúng cách?

Tại sao có vấn đề ngay từ đầu?

Dự án mà tôi đang thực hiện bao gồm việc xác định cấu trúc bộ nhớ của các thiết bị ngoại vi khác nhau của toàn bộ dòng vi điều khiển (STMicroelectronics STM32). Để làm như vậy, kết quả là một lớp chứa liên hợp của một số cấu trúc xác định tất cả các thanh ghi, tùy thuộc vào bộ vi điều khiển được nhắm mục tiêu.

Một ví dụ đơn giản cho một thiết bị ngoại vi khá đơn giản như sau: Một Đầu vào / Đầu ra Mục đích Chung (GPIO)

union
{

    struct
    {
        GPIO_MAP0_MODER;
        GPIO_MAP0_OTYPER;
        GPIO_MAP0_OSPEEDR;
        GPIO_MAP0_PUPDR;
        GPIO_MAP0_IDR;
        GPIO_MAP0_ODR;
        GPIO_MAP0_BSRR;
        GPIO_MAP0_LCKR;
        GPIO_MAP0_AFR;
        GPIO_MAP0_BRR;
        GPIO_MAP0_ASCR;
    };
    struct
    {
        GPIO_MAP1_CRL;
        GPIO_MAP1_CRH;
        GPIO_MAP1_IDR;
        GPIO_MAP1_ODR;
        GPIO_MAP1_BSRR;
        GPIO_MAP1_BRR;
        GPIO_MAP1_LCKR;
        uint32_t :32;
        GPIO_MAP1_AFRL;
        GPIO_MAP1_AFRH;
        uint32_t :64;
    };
    struct
    {
        uint32_t :192;
        GPIO_MAP2_BSRRL;
        GPIO_MAP2_BSRRH;
        uint32_t :160;
    };
};

Trong đó tất cả đều GPIO_MAPx_YYYlà macro, được định nghĩa là uint32_t :32hoặc kiểu thanh ghi (cấu trúc chuyên dụng).

Ở đây, bạn thấy cái uint32_t :192;nào hoạt động tốt, nhưng nó kích hoạt cảnh báo.

Những gì tôi đã xem xét cho đến nay:

Tôi có thể đã thay thế nó bằng một số uint32_t :32;(6 ở đây), nhưng tôi có một số trường hợp cực đoan mà tôi có uint32_t :1344;(42) (trong số những người khác). Vì vậy, tôi không muốn thêm khoảng một trăm dòng trên 8k dòng khác, mặc dù việc tạo cấu trúc đã được viết sẵn.

Thông điệp cảnh báo chính xác là một cái gì đó như: width of 'sool::ll::GPIO::<anonymous union>::<anonymous struct>::<anonymous>' exceeds its type(Tôi chỉ thích nó mờ ám như thế nào).

Tôi thà không giải quyết việc này bằng cách đơn giản loại bỏ các cảnh báo, nhưng việc sử dụng

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-WTheRightFlag"
/* My code */
#pragma GCC diagnostic pop

có thể là một giải pháp ... nếu tôi tìm thấy TheRightFlag. Tuy nhiên, như đã chỉ ra trong chủ đề này , gcc/cp/class.cvới phần mã đáng buồn này:

warning_at (DECL_SOURCE_LOCATION (field), 0,
        "width of %qD exceeds its type", field);

Điều này cho chúng ta biết rằng không có -Wxxxcờ nào để xóa cảnh báo này ...

Sử dụng nhiều trường bit ẩn danh liền kề. Vì vậy, thay vì:

    uint32_t :160;

ví dụ, bạn có:

    uint32_t :32;
    uint32_t :32;
    uint32_t :32;
    uint32_t :32;
    uint32_t :32;

Một cho mỗi đăng ký bạn muốn ẩn danh.

Nếu bạn có khoảng trống lớn để lấp đầy, nó có thể rõ ràng hơn và ít bị lỗi hơn khi sử dụng macro để lặp lại không gian 32 bit duy nhất. Ví dụ, đã cho:

#define REPEAT_2(a) a a
#define REPEAT_4(a) REPEAT_2(a) REPEAT_2(a)
#define REPEAT_8(a) REPEAT_4(a) REPEAT_4(a)
#define REPEAT_16(a) REPEAT_8(a) REPEAT_8(a)
#define REPEAT_32(a) REPEAT_16(a) REPEAT_16(a)

Sau đó, một không gian 1344 (42 * 32 bit) có thể được thêm vào do đó:

struct
{
    ...
    REPEAT_32(uint32_t :32;) 
    REPEAT_8(uint32_t :32;) 
    REPEAT_2(uint32_t :32;)
    ...
};

Làm thế nào về một C ++ - cách?

namespace GPIO {

static volatile uint32_t &MAP0_MODER = *reinterpret_cast<uint32_t*>(0x4000);
static volatile uint32_t &MAP0_OTYPER = *reinterpret_cast<uint32_t*>(0x4004);

}

int main() {
    GPIO::MAP0_MODER = 42;
}

Bạn nhận được tự động hoàn thành vì GPIOkhông gian tên và không cần đệm giả. Thậm chí, nó còn rõ ràng hơn những gì đang xảy ra, vì bạn có thể thấy địa chỉ của từng thanh ghi, bạn không cần phải dựa vào hành vi đệm của trình biên dịch nữa.

Trong lĩnh vực hệ thống nhúng, bạn có thể mô hình hóa phần cứng bằng cách sử dụng cấu trúc hoặc bằng cách xác định con trỏ đến địa chỉ thanh ghi.

Mô hình hóa theo cấu trúc không được khuyến khích vì trình biên dịch được phép thêm phần đệm giữa các thành viên cho mục đích liên kết (mặc dù nhiều trình biên dịch cho hệ thống nhúng có pragma để đóng gói cấu trúc).

Thí dụ:

uint16_t * const UART1 = (uint16_t *)(0x40000);
const unsigned int UART_STATUS_OFFSET = 1U;
const unsigned int UART_TRANSMIT_REGISTER = 2U;
uint16_t * const UART1_STATUS_REGISTER = (UART1 + UART_STATUS_OFFSET);
uint16_t * const UART1_TRANSMIT_REGISTER = (UART1 + UART_TRANSMIT_REGISTER);

Bạn cũng có thể sử dụng ký hiệu mảng:

uint16_t status = UART1[UART_STATUS_OFFSET];  

Nếu bạn phải sử dụng cấu trúc, IMHO, thì phương pháp tốt nhất để bỏ qua địa chỉ là xác định một thành viên và không truy cập nó:

struct UART1
{
  uint16_t status;
  uint16_t reserved1; // Transmit register
  uint16_t receive_register;
};

Trong một trong những dự án của chúng tôi, chúng tôi có cả hằng số và cấu trúc từ các nhà cung cấp khác nhau (nhà cung cấp 1 sử dụng hằng số trong khi nhà cung cấp 2 sử dụng cấu trúc).

geza đúng rằng bạn thực sự không muốn sử dụng các lớp cho việc này.

Nhưng, nếu bạn muốn nhấn mạnh, cách tốt nhất để thêm một phần tử không sử dụng của chiều rộng n byte, chỉ đơn giản là làm như vậy:

char unused[n];

Nếu bạn thêm một pragma dành riêng cho việc triển khai để ngăn việc thêm phần đệm tùy ý vào các thành viên của lớp, điều này có thể hoạt động.

Đối với GNU C / C ++ (gcc, clang và những thứ khác hỗ trợ cùng một phần mở rộng), một trong những vị trí hợp lệ để đặt thuộc tính là:

#include <stddef.h>
#include <stdint.h>
#include <assert.h>  // for C11 static_assert, so this is valid C as well as C++

struct __attribute__((packed)) GPIO {
    volatile uint32_t a;
    char unused[3];
    volatile uint32_t b;
};

static_assert(offsetof(struct GPIO, b) == 7, "wrong GPIO struct layout");

(ví dụ trên trình khám phá trình biên dịch Godbolt hiển thị offsetof(GPIO, b)= 7 byte.)

Để mở rộng câu trả lời của @ Clifford và @Adam Kotwasinski:

#define REP10(a)        a a a a a a a a a a
#define REP1034(a)      REP10(REP10(REP10(a))) REP10(a a a) a a a a

struct foo {
        int before;
        REP1034(unsigned int :32;)
        int after;
};
int main(void){
        struct foo bar;
        return 0;
}

Để mở rộng câu trả lời của Clifford, bạn luôn có thể lấy macro ra các trường bit ẩn danh.

Vì vậy, thay vì

uint32_t :160;

sử dụng

#define EMPTY_32_1 \
 uint32_t :32
#define EMPTY_32_2 \
 uint32_t :32;     \ // I guess this also can be replaced with uint64_t :64
 uint32_t :32
#define EMPTY_32_3 \
 uint32_t :32;     \
 uint32_t :32;     \
 uint32_t :32
#define EMPTY_UINT32(N) EMPTY_32_ ## N

Và sau đó sử dụng nó như

struct A {
  EMPTY_UINT32(3);
  /* which resolves to EMPTY_32_3, which then resolves to real declarations */
}

Thật không may, bạn sẽ cần nhiều EMPTY_32_Xbiến thể với số byte bạn có :( Tuy nhiên, nó cho phép bạn có các khai báo duy nhất trong cấu trúc của mình.

Để xác định một khoảng đệm lớn dưới dạng các nhóm 32 bit.

#define M_32(x)   M_2(M_16(x))
#define M_16(x)   M_2(M_8(x))
#define M_8(x)    M_2(M_4(x))
#define M_4(x)    M_2(M_2(x))
#define M_2(x)    x x

#define SPACER int : 32;

struct {
    M_32(SPACER) M_8(SPACER) M_4(SPACER)
};

Tôi nghĩ sẽ có lợi nếu giới thiệu thêm một số cấu trúc; do đó có thể giải quyết vấn đề về bộ đệm.

Đặt tên cho các biến thể

Mặc dù không gian tên phẳng rất hay, nhưng vấn đề là bạn phải kết thúc với một bộ sưu tập các trường phức tạp và không có cách nào đơn giản để chuyển tất cả các trường liên quan lại với nhau. Hơn nữa, bằng cách sử dụng các cấu trúc ẩn danh trong một liên hợp ẩn danh, bạn không thể chuyển các tham chiếu đến chính các cấu trúc hoặc sử dụng chúng làm tham số mẫu.

Do đó, bước đầu tiên, tôi sẽ xem xét việc phá vỡstruct :

// GpioMap0.h
#pragma once

// #includes

namespace Gpio {
struct Map0 {
    GPIO_MAP0_MODER;
    GPIO_MAP0_OTYPER;
    GPIO_MAP0_OSPEEDR;
    GPIO_MAP0_PUPDR;
    GPIO_MAP0_IDR;
    GPIO_MAP0_ODR;
    GPIO_MAP0_BSRR;
    GPIO_MAP0_LCKR;
    GPIO_MAP0_AFR;
    GPIO_MAP0_BRR;
    GPIO_MAP0_ASCR;
};
} // namespace Gpio

// GpioMap1.h
#pragma once

// #includes

namespace Gpio {
struct Map1 {
    // fields
};
} // namespace Gpio

// ... others headers ...

Và cuối cùng, tiêu đề chung:

// Gpio.h
#pragma once

#include "GpioMap0.h"
#include "GpioMap1.h"
// ... other headers ...

namespace Gpio {
union Gpio {
    Map0 map0;
    Map1 map1;
    // ... others ...
};
} // namespace Gpio

Bây giờ, tôi có thể viết void special_map0(Gpio:: Map0 volatile& map);, cũng như có được một cái nhìn tổng quan về tất cả các kiến ​​trúc có sẵn trong nháy mắt.

Dấu cách đơn giản

Với định nghĩa được chia thành nhiều tiêu đề, các tiêu đề riêng lẻ dễ quản lý hơn nhiều.

Do đó, cách tiếp cận ban đầu của tôi để đáp ứng chính xác yêu cầu của bạn là gắn bó với việc lặp lại std::uint32_t:32;. Có, nó thêm một vài dòng 100s vào dòng 8k hiện có, nhưng vì mỗi tiêu đề nhỏ hơn riêng lẻ, nó có thể không tệ bằng.

Tuy nhiên, nếu bạn sẵn sàng xem xét các giải pháp kỳ lạ hơn ...

Giới thiệu $.

Một thực tế ít được biết đến $là một ký tự khả thi cho các mã định danh C ++; nó thậm chí còn là một ký tự bắt đầu khả thi (không giống như các chữ số).

Một sự $xuất hiện trong mã nguồn có thể sẽ khiến bạn phải kinh ngạc và $$$$chắc chắn sẽ thu hút sự chú ý trong quá trình đánh giá mã. Đây là thứ mà bạn có thể dễ dàng tận dụng:

#define GPIO_RESERVED(Index_, N_) std::uint32_t $$$$##Index_[N_];

struct Map3 {
    GPIO_RESERVED(0, 6);
    GPIO_MAP2_BSRRL;
    GPIO_MAP2_BSRRH;
    GPIO_RESERVED(1, 5);
};

Bạn thậm chí có thể đặt cùng nhau một "lint" đơn giản làm móc cam kết trước hoặc trong CI của bạn để tìm kiếm $$$$mã C ++ đã cam kết và từ chối các cam kết đó.

Mặc dù tôi đồng ý rằng không nên sử dụng cấu trúc để truy cập cổng I / O MCU, câu hỏi ban đầu có thể được trả lời theo cách này:

struct __attribute__((packed)) test {
       char member1;
       char member2;
       volatile struct __attribute__((packed))
       {
       private:
              volatile char spacer_bytes[7];
       }  spacer;
       char member3;
       char member4;
};

Bạn có thể cần thay thế __attribute__((packed))bằng #pragma packhoặc tương tự tùy thuộc vào cú pháp trình biên dịch của bạn.

Việc trộn các thành viên private và public trong một cấu trúc thường dẫn đến việc bố trí bộ nhớ không còn được đảm bảo bởi tiêu chuẩn C ++. Tuy nhiên, nếu tất cả các thành viên không tĩnh của một cấu trúc là riêng tư, thì nó vẫn được coi là POD / bố cục tiêu chuẩn và các cấu trúc nhúng chúng cũng vậy.

Vì lý do nào đó mà gcc đưa ra cảnh báo nếu một thành viên của cấu trúc ẩn danh là riêng tư, vì vậy tôi phải đặt tên cho nó. Ngoài ra, gói nó vào một cấu trúc ẩn danh khác cũng sẽ loại bỏ cảnh báo (đây có thể là một lỗi).

Lưu ý rằng spacerbản thân thành viên không phải là riêng tư, vì vậy dữ liệu vẫn có thể được truy cập theo cách này:

(char*)(void*)&testobj.spacer;

Tuy nhiên, một biểu thức như vậy trông giống như một vụ hack rõ ràng và hy vọng sẽ không được sử dụng mà không có lý do thực sự chính đáng, chứ đừng nói là một sai lầm.

Giải pháp chống.

KHÔNG LÀM VIỆC NÀY: Trộn các trường riêng tư và công khai.

Có thể một macro có bộ đếm để tạo tên biến uniqie sẽ hữu ích?

#define CONCAT_IMPL( x, y ) x##y
#define MACRO_CONCAT( x, y ) CONCAT_IMPL( x, y )
#define RESERVED MACRO_CONCAT(Reserved_var, __COUNTER__) 


struct {
    GPIO_MAP1_CRL;
    GPIO_MAP1_CRH;
    GPIO_MAP1_IDR;
    GPIO_MAP1_ODR;
    GPIO_MAP1_BSRR;
    GPIO_MAP1_BRR;
    GPIO_MAP1_LCKR;
private:
    char RESERVED[4];
public:
    GPIO_MAP1_AFRL;
    GPIO_MAP1_AFRH;
private:
    char RESERVED[8];
};