Das Thema

In einem Bare-Metal-Embedded- Kontext auf niedriger Ebene möchte ich einen leeren Bereich im Speicher innerhalb einer C ++ - Struktur und ohne Namen erstellen, um dem Benutzer den Zugriff auf diesen Speicherort zu verbieten.

Im Moment habe ich es erreicht, indem ich ein hässliches uint32_t :96;Bitfeld eingefügt habe, das bequemerweise drei Wörter ersetzt, aber eine Warnung von GCC auslöst (Bitfeld zu groß, um in uint32_t zu passen), was ziemlich legitim ist.

Es funktioniert zwar einwandfrei, ist aber nicht sehr sauber, wenn Sie eine Bibliothek mit mehreren Hundert dieser Warnungen verteilen möchten ...

Wie mache ich das richtig?

Warum gibt es überhaupt ein Problem?

Das Projekt, an dem ich arbeite, besteht darin, die Speicherstruktur verschiedener Peripheriegeräte einer gesamten Mikrocontrollerleitung (STMicroelectronics STM32) zu definieren. Das Ergebnis ist eine Klasse, die eine Vereinigung mehrerer Strukturen enthält, die abhängig vom Ziel-Mikrocontroller alle Register definieren.

Ein einfaches Beispiel für ein ziemlich einfaches Peripheriegerät ist das folgende: ein GPIO (General Purpose Input / Output)

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;
    };
};

Wobei alles GPIO_MAPx_YYYein Makro ist, das entweder als uint32_t :32oder als Registertyp definiert ist (eine dedizierte Struktur).

Hier sehen Sie, uint32_t :192;was gut funktioniert, aber es löst eine Warnung aus.

Was ich bisher bedacht habe:

Ich hätte es vielleicht durch mehrere ersetzen können uint32_t :32;(6 hier), aber ich habe einige extreme Fälle, in denen ich uint32_t :1344;(42) (unter anderem) habe. Daher möchte ich lieber nicht etwa hundert Zeilen über 8.000 Zeilen hinzufügen, obwohl die Strukturgenerierung in Skripten ausgeführt ist.

Die genaue Warnmeldung ist ungefähr so: width of 'sool::ll::GPIO::<anonymous union>::<anonymous struct>::<anonymous>' exceeds its type(Ich liebe es einfach, wie schattig es ist).

Ich würde dies lieber nicht lösen, indem ich einfach die Warnung entferne, sondern die Verwendung von

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

kann eine Lösung sein ... wenn ich finde TheRightFlag. Wie in diesem Thread erwähnt , gcc/cp/class.cmit diesem traurigen Codeteil:

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

Was uns sagt, dass es keine -WxxxFlagge gibt, um diese Warnung zu entfernen ...

Verwenden Sie mehrere benachbarte anonyme Bitfelder. Also statt:

    uint32_t :160;

Zum Beispiel hätten Sie:

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

Eine für jedes Register, für das Sie anonym bleiben möchten.

Wenn Sie große Leerzeichen ausfüllen müssen, ist es möglicherweise klarer und weniger fehleranfällig, Makros zum Wiederholen des einzelnen 32-Bit-Speicherplatzes zu verwenden. Zum Beispiel gegeben:

#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)

Dann kann ein 1344 (42 * 32 Bit) Speicherplatz wie folgt hinzugefügt werden:

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

Wie wäre es mit einem C ++ - ish Weg?

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;
}

Sie erhalten aufgrund des GPIONamespace eine automatische Vervollständigung , und es ist kein Dummy-Padding erforderlich. Es ist jedoch klarer, was los ist, da Sie die Adresse jedes Registers sehen können, müssen Sie sich überhaupt nicht auf das Auffüllverhalten des Compilers verlassen.

Im Bereich eingebetteter Systeme können Sie Hardware entweder mithilfe einer Struktur oder durch Definieren von Zeigern auf die Registeradressen modellieren.

Die Modellierung nach Struktur wird nicht empfohlen, da der Compiler zu Ausrichtungszwecken Auffüllungen zwischen Elementen hinzufügen darf (obwohl viele Compiler für eingebettete Systeme ein Pragma zum Packen der Struktur haben).

Beispiel:

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);

Sie können auch die Array-Notation verwenden:

uint16_t status = UART1[UART_STATUS_OFFSET];  

Wenn Sie die Struktur IMHO verwenden müssen, besteht die beste Methode zum Überspringen von Adressen darin, ein Mitglied zu definieren und nicht darauf zuzugreifen:

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

In einem unserer Projekte haben wir sowohl Konstanten als auch Strukturen von verschiedenen Anbietern (Anbieter 1 verwendet Konstanten, während Anbieter 2 Strukturen verwendet).

geza hat recht, dass du dafür wirklich keine klassen verwenden willst.

Wenn Sie jedoch darauf bestehen möchten, können Sie ein unbenutztes Element mit einer Breite von n Bytes am besten einfach folgendermaßen hinzufügen :

char unused[n];

Wenn Sie ein implementierungsspezifisches Pragma hinzufügen, um zu verhindern, dass den Mitgliedern der Klasse beliebige Auffüllungen hinzugefügt werden, kann dies funktionieren.

Für GNU C / C ++ (gcc, clang und andere, die dieselben Erweiterungen unterstützen) ist eine der gültigen Stellen für das Attribut:

#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");

(Beispiel im Godbolt-Compiler-Explorer mit offsetof(GPIO, b)= 7 Bytes.)

Um die Antworten von @ Clifford und @Adam Kotwasinski zu erweitern:

#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;
}

Um die Antwort von Clifford zu erweitern, können Sie die anonymen Bitfelder jederzeit makroauslesen.

Also statt

uint32_t :160;

verwenden

#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

Und dann benutze es gerne

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

Leider benötigen Sie so viele EMPTY_32_XVarianten wie Sie Bytes haben :( Trotzdem können Sie einzelne Deklarationen in Ihrer Struktur haben.

Definieren eines großen Abstandshalters als Gruppen von 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)
};

Ich denke, es wäre vorteilhaft, etwas mehr Struktur einzuführen. Dies kann wiederum das Problem der Abstandshalter lösen.

Nennen Sie die Varianten

Flache Namespaces sind zwar nett, aber das Problem ist, dass Sie am Ende eine bunte Sammlung von Feldern haben und keine einfache Möglichkeit, alle verwandten Felder zusammen zu übergeben. Wenn Sie anonyme Strukturen in einer anonymen Vereinigung verwenden, können Sie keine Verweise auf die Strukturen selbst übergeben oder sie als Vorlagenparameter verwenden.

Als ersten Schritt würde ich daher in Betracht ziehen, Folgendes auszubrechenstruct :

// 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 ...

Und schließlich der globale Header:

// Gpio.h
#pragma once

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

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

Jetzt kann ich eine schreiben void special_map0(Gpio:: Map0 volatile& map); auf einen Blick einen schnellen Überblick über alle verfügbaren Architekturen verschaffen.

Einfache Abstandshalter

Da die Definition in mehrere Header aufgeteilt ist, sind die Header einzeln viel einfacher zu verwalten.

Daher wäre mein erster Ansatz, um Ihre Anforderungen genau zu erfüllen, wiederholt zu bleiben std::uint32_t:32;. Ja, es werden einige 100s-Zeilen zu den vorhandenen 8k-Zeilen hinzugefügt, aber da jeder Header einzeln kleiner ist, ist er möglicherweise nicht so schlecht.

Wenn Sie jedoch bereit sind, exotischere Lösungen in Betracht zu ziehen ...

Wir stellen $ vor.

Es ist eine wenig bekannte Tatsache, dass dies $ein brauchbares Zeichen für C ++ - Bezeichner ist. Es ist sogar ein brauchbarer Startcharakter (im Gegensatz zu Ziffern).

Ein $Erscheinen im Quellcode würde wahrscheinlich die Augenbrauen hochziehen und $$$$wird bei Codeüberprüfungen definitiv Aufmerksamkeit erregen. Dies ist etwas, das Sie leicht nutzen können:

#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);
};

Sie können sogar einen einfachen "Flusen" als Pre-Commit-Hook oder in Ihrem CI zusammenstellen, der $$$$im festgeschriebenen C ++ - Code sucht, und solche Commits ablehnen.

Obwohl ich damit einverstanden bin, dass Strukturen nicht für den Zugriff auf MCU-E / A-Ports verwendet werden sollten, kann die ursprüngliche Frage folgendermaßen beantwortet werden:

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

Sie können ersetzen müssen __attribute__((packed))mit #pragma packoder ähnlich je nach Compiler - Syntax.

Das Mischen von privaten und öffentlichen Mitgliedern in einer Struktur führt normalerweise dazu, dass das Speicherlayout vom C ++ - Standard nicht mehr garantiert wird. Wenn jedoch alle nicht statischen Elemente einer Struktur privat sind, wird sie weiterhin als POD / Standard-Layout betrachtet, ebenso wie Strukturen, die sie einbetten.

Aus irgendeinem Grund gibt gcc eine Warnung aus, wenn ein Mitglied einer anonymen Struktur privat ist, sodass ich ihm einen Namen geben musste. Wenn Sie es alternativ in eine weitere anonyme Struktur einbinden, wird die Warnung ebenfalls entfernt (dies kann ein Fehler sein).

Beachten Sie, dass das spacerMitglied selbst nicht privat ist, sodass auf folgende Weise auf Daten zugegriffen werden kann:

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

Ein solcher Ausdruck sieht jedoch wie ein offensichtlicher Hack aus und würde hoffentlich nicht ohne einen wirklich guten Grund verwendet werden, geschweige denn als Fehler.

Anti-Lösung.

TUN SIE DAS NICHT: Mischen Sie private und öffentliche Felder.

Vielleicht ist ein Makro mit einem Zähler zum Generieren eindeutiger Variablennamen hilfreich?

#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];
};