Le problème

Dans un contexte embarqué bare-metal de bas niveau , je voudrais créer un espace vide dans la mémoire, dans une structure C ++ et sans aucun nom, pour interdire à l'utilisateur d'accéder à un tel emplacement mémoire.

Pour le moment, je l'ai réalisé en mettant un vilain uint32_t :96;champ de bits qui remplacera commodément trois mots, mais cela soulèvera un avertissement de GCC (Bitfield trop grand pour tenir dans uint32_t), ce qui est assez légitime.

Bien que cela fonctionne bien, ce n'est pas très propre lorsque vous souhaitez distribuer une bibliothèque avec plusieurs centaines de ces avertissements ...

Comment faire ça correctement?

Pourquoi y a-t-il un problème en premier lieu?

Le projet sur lequel je travaille consiste à définir la structure mémoire des différents périphériques de toute une ligne de microcontrôleurs (STMicroelectronics STM32). Pour ce faire, le résultat est une classe qui contient une union de plusieurs structures qui définissent tous les registres, en fonction du microcontrôleur ciblé.

Voici un exemple simple de périphérique assez simple: une entrée / sortie à usage général (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;
    };
};

Où tout GPIO_MAPx_YYYest une macro, définie soit comme uint32_t :32soit le type de registre (une structure dédiée).

Ici, vous voyez uint32_t :192;qui fonctionne bien, mais cela déclenche un avertissement.

Ce que j'ai considéré jusqu'à présent:

J'aurais pu le remplacer par plusieurs uint32_t :32;(6 ici), mais j'ai quelques cas extrêmes où j'ai uint32_t :1344;(42) (entre autres). Je préférerais donc ne pas ajouter une centaine de lignes sur 8k autres, même si la génération de structure est scriptée.

Le message d'avertissement exact est quelque chose comme: width of 'sool::ll::GPIO::<anonymous union>::<anonymous struct>::<anonymous>' exceeds its type(J'adore à quel point c'est louche).

Je préfère ne pas résoudre ce problème en supprimant simplement l'avertissement, mais en utilisant

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

peut être une solution ... si je trouve TheRightFlag. Cependant, comme indiqué dans ce fil , gcc/cp/class.cavec cette triste partie de code:

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

Ce qui nous indique qu'il n'y a pas de -Wxxxdrapeau pour supprimer cet avertissement ...

Utilisez plusieurs champs de bits anonymes adjacents. Donc au lieu de:

    uint32_t :160;

par exemple, vous auriez:

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

Un pour chaque registre dont vous voulez être anonyme.

Si vous avez de grands espaces à remplir, il peut être plus clair et moins sujet aux erreurs d'utiliser des macros pour répéter l'espace unique de 32 bits. Par exemple, étant donné:

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

Ensuite, un espace de 1344 (42 * 32 bits) peut être ajouté ainsi:

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

Que diriez-vous d'une manière C ++ - ish?

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

Vous obtenez une saisie semi-automatique à cause de l' GPIOespace de noms et il n'y a pas besoin de remplissage factice. Même, ce qui se passe est plus clair, car vous pouvez voir l'adresse de chaque registre, vous n'avez pas du tout à vous fier au comportement de remplissage du compilateur.

Dans l'arène des systèmes embarqués, vous pouvez modéliser le matériel en utilisant une structure ou en définissant des pointeurs vers les adresses de registre.

La modélisation par structure n'est pas recommandée car le compilateur est autorisé à ajouter un remplissage entre les membres à des fins d'alignement (bien que de nombreux compilateurs pour systèmes embarqués aient un pragma pour empaqueter la structure).

Exemple:

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

Vous pouvez également utiliser la notation de tableau:

uint16_t status = UART1[UART_STATUS_OFFSET];  

Si vous devez utiliser la structure, à mon humble avis, la meilleure méthode pour ignorer les adresses serait de définir un membre et de ne pas y accéder:

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

Dans l'un de nos projets, nous avons à la fois des constantes et des structures de différents fournisseurs (le fournisseur 1 utilise des constantes tandis que le fournisseur 2 utilise des structures).

geza a raison de ne pas vouloir utiliser de classes pour cela.

Mais, si vous insistez, la meilleure façon d'ajouter un membre inutilisé d'une largeur de n octets est simplement de le faire:

char unused[n];

Si vous ajoutez un pragma spécifique à l'implémentation pour empêcher l'ajout d'un remplissage arbitraire aux membres de la classe, cela peut fonctionner.

Pour GNU C / C ++ (gcc, clang et autres qui prennent en charge les mêmes extensions), l'un des emplacements valides pour placer l'attribut est:

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

(exemple sur l'explorateur du compilateur Godbolt montrant offsetof(GPIO, b)= 7 octets.)

Pour développer les réponses de @ Clifford et @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;
}

Pour développer la réponse de Clifford, vous pouvez toujours supprimer les champs de bits anonymes.

Donc au lieu de

uint32_t :160;

utilisation

#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

Et puis utilisez-le comme

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

Malheureusement, vous aurez besoin d'autant de EMPTY_32_Xvariantes que d'octets que vous avez :( Pourtant, cela vous permet d'avoir des déclarations uniques dans votre structure.

Pour définir un grand espaceur sous forme de groupes de 32 bits.

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

Je pense qu'il serait avantageux d'introduire une structure supplémentaire; ce qui peut, à son tour, résoudre le problème des entretoises.

Nommez les variantes

Bien que les espaces de noms plats soient agréables, le problème est que vous vous retrouvez avec une collection hétéroclite de champs et aucun moyen simple de passer tous les champs associés ensemble. De plus, en utilisant des structures anonymes dans une union anonyme, vous ne pouvez pas passer de références aux structures elles-mêmes, ni les utiliser comme paramètres de modèle.

Dans un premier temps, j'envisagerais donc de sortirstruct :

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

Et enfin, l'en-tête global:

// Gpio.h
#pragma once

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

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

Maintenant, je peux écrire un void special_map0(Gpio:: Map0 volatile& map);, ainsi qu'obtenir un aperçu rapide de toutes les architectures disponibles en un coup d'œil.

Espaceurs simples

Avec la définition divisée en plusieurs en-têtes, les en-têtes sont individuellement beaucoup plus gérables.

Par conséquent, mon approche initiale pour répondre exactement à vos besoins serait de m'en tenir à des répétitions std::uint32_t:32;. Oui, cela ajoute quelques centaines de lignes aux lignes 8k existantes, mais comme chaque en-tête est individuellement plus petit, il peut ne pas être aussi mauvais.

Si vous êtes prêt à envisager des solutions plus exotiques, cependant ...

Présentation de $.

C'est un fait peu connu qui $est un caractère viable pour les identificateurs C ++; c'est même un personnage de départ viable (contrairement aux chiffres).

Une $apparition dans le code source soulèverait probablement des sourcils et $$$$attirera certainement l'attention lors des révisions de code. C'est quelque chose dont vous pouvez facilement profiter:

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

Vous pouvez même créer un simple «lint» comme hook de pré-validation ou dans votre CI qui recherche $$$$dans le code C ++ validé et rejeter de tels validations.

Bien que je convienne que les structures ne doivent pas être utilisées pour l'accès au port d'E / S MCU, la question d'origine peut être répondue de cette manière:

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

Vous devrez peut-être remplacer __attribute__((packed))par #pragma packou similaire en fonction de la syntaxe de votre compilateur.

Le mélange de membres privés et publics dans une structure entraîne normalement que la disposition de la mémoire n'est plus garantie par la norme C ++. Cependant, si tous les membres non statiques d'une structure sont privés, il est toujours considéré comme une mise en page POD / standard, tout comme les structures qui les incorporent.

Pour une raison quelconque, gcc produit un avertissement si un membre d'une structure anonyme est privé, j'ai donc dû lui donner un nom. Alternativement, l'envelopper dans une autre structure anonyme supprime également l'avertissement (cela peut être un bogue).

Notez que le spacermembre n'est pas lui-même privé, donc les données sont toujours accessibles de cette façon:

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

Cependant, une telle expression ressemble à un piratage évident et, espérons-le, ne serait pas utilisée sans une très bonne raison, et encore moins comme une erreur.

Anti-solution.

NE FAITES PAS CELA: Mélangez les champs privés et publics.

Peut-être qu'une macro avec un compteur pour générer des noms de variables uniqie sera utile?

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