Bitfeld: Datentyp der Elemente

Was ist hier der Unterscheid?
und wozu das reserved was die 16bit auffüllt?

typedef struct
{
  T_U8          foo1          :2;
  T_U8          foo2          :1;   
  T_U8          foo3          :1;	
  T_U8          foo4          :1;
  T_U8          foo5          :1;	
  T_U8          foo6          :1;	
  T_U8          foo7          :1;
  T_U8          foo8          :1;	
  T_U8          foo9          :1;	
  T_U8          reserved	   :6;
} Foo_8;

typedef struct
{
  T_U32          foo1          :2;
  T_U32          foo2          :1;   
  T_U32         foo3          :1;	
  T_U32         foo4          :1;
  T_U32         foo5          :1;	
  T_U32         foo6          :1;	
  T_U32         foo7          :1;
  T_U32         foo8          :1;	
  T_U32         foo9          :1;	
  T_U32         reserved	   :6;
} Foo_32;

^^garkein unterschied, wenn beides unsigned-typen sind (so wie's aussieht). wieviel bits es werden sollen, steht ja rechts neben den doppelpünktchen. mit dem 'reserved' wollte wohl einer erreichen, dass so'n bitfield aus mindestens 16 bits besteht.

ne so einfach ist die antwort nicht.
das hat schon alles seinen grund, nur ich weis nicht warum.

test123 schrieb:

das hat schon alles seinen grund.

das können wir erst sagen, wenn du uns T_U8 und T_U32 zeigst. aber die chancen für einen grund stehen schlecht, denn als bitfield member-typen sind eigentlich nur 'int', und 'unsigned' von bedeutung.

es geht hier um embedded entwicklung. irgendjemand hat das in der file history geändert, und ich würde gerne wissen warum.
im C handbuch habe ich gelesen dass die datentypen eigentlich integer sein sollten, daher frage ich mich warum er sie auf T_U8 geändert hat.

test124 schrieb:

... daher frage ich mich warum er sie auf T_U8 geändert hat.

zwei möglichkeiten:

er ist doof
er verwendet GCC und es ist eine 'nonstandard extension'.
der gcc ist ja berüchtigt für seine eigenwillige interpretation der sprache C, schau doch mal im GCC manual, ob da irgendwelche erweiterungen erwähnt sind, die bitfields betreffen.

Der grund war einsparung von memory.
wenn man datentyp 32bit nimmt reserviert er für eine variable vom typ bitfeld immer 32 bit, wenn 8bit dann nur soviel wie er braucht.

jedenfalls konnte ich das so am x86 reproduzieren. gehe nun an den µC da werde ich wohl das gleiche feststellen.

alles hat seinen grund.

evtl. erklärst uns mal lieber was du damit vorhast, denn dann wolltest nen tipp und gehst am ende mit nem anderen ansatz heim

evtl. so

#define LAMP 0x1
#define CAR  (0x1<<1)
#define BALL (0x1<<2)

uint16_t bitty;

bitty |= LAMP;//lamp on
bitty ^= LAMP;//lamp off

brauch ich nicht so häufig, aber evtl. stimmst

lg lolo

"stimmst" sollte "stimmts" heißen kpl. wieso ich heut derart viele buchstaben dreher drin hab

test124 schrieb:

jedenfalls konnte ich das so am x86 reproduzieren. gehe nun an den µC da werde ich wohl das gleiche feststellen.

naja, vielleicht...

test124 schrieb:

alles hat seinen grund.

aber nicht das. du kannst dich nicht darauf verlassen, wie ein compiler bitfields speichert und zusammensetzt. das ist doch garantiert wieder so'n thema, wobei der c-standard dem compilerprogrammierer maximale freiheiten lässt. versuch's doch mal mit '#pragma pack' für die structs oder sonstigen platzspar-optimierungen deines compilers.

ok,

auf einem Freescale macht er bei int 4 bytes aus dem bitfeld bei einem Infineon nur 2.

Ich bin mir sicher das liegt auch an den Compileroptionen.

Jedenfalls bin ich gezwungen nach dem C99 Standard zu programmieren, und da heißt es ich muss int nehmen.

Ok danke das Thema ist dann gegessen

;fricky schrieb:

er verwendet GCC und es ist eine 'nonstandard extension'.
der gcc ist ja berüchtigt für seine eigenwillige interpretation der sprache C, schau doch mal im GCC manual, ob da irgendwelche erweiterungen erwähnt sind, die bitfields betreffen.

struct {
  char foo1 :1;
  int foo2 :7;
} f;

/* ... */

main.c:2: Warnung: Typ des Bitfeldes »foo1« ist eine Erweiterung des GCC

Natürlich konnte ich's in der Anleitung nicht finden.

pointercrash**

test124 schrieb:

ok,

auf einem Freescale macht er bei int 4 bytes aus dem bitfeld bei einem Infineon nur 2.

Ich bin mir sicher das liegt auch an den Compileroptionen.

Jedenfalls bin ich gezwungen nach dem C99 Standard zu programmieren, und da heißt es ich muss int nehmen.

Ok danke das Thema ist dann gegessen

Deswegen gibt's ja #pragma pack. Obendrein verwendest Du schon Typenersatz, wieder mal nach einem anderen Schema, um die unterschiedliche Bitbreite in den Griff zu bekommen. Mit C99 hat das jetzt direkt nix zu tun. Eher mit GCC und Plattformrelevanten Compileroptionen.

µngbd schrieb:

main.c:2: Warnung: Typ des Bitfeldes »foo1« ist eine Erweiterung des GCC

na, ich war ja wieder ein spitzenmässiger ratefuchs. *fg*