www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR GCC Tutorial


Autor: tutorial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Comunity,

ich habe etwas im Tutorial gestöbert und bin über Bitfelder gestolpert:
struct
{
  unsigned bStatus_1:5;   // 5 Bit zuweißen
  unsigned bStatus1_1:2;  // 2 Bit zuweißen
  unsigned bStatus_2:1;   // 1 Bit zuweißen
} test;   // Name der Variable

Jetzt ist das wie im Tutorial beschrieben ein unsigned char, also mit 8 
Bit die ich zuweißen kann.
Wenn ich jetzt zum Beispiel 40 Bit in so einem Bitfeld bräuchte, kann 
ich dann einfach 40 zuweißen oder wie kann ich dies umsetzten?

Viele Grüße

Autor: Prof.Dr.Schlau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann mußt du 5 structs anlegen. 5Byte a 8Bit = 40Bit

Autor: tutorial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prof.Dr.Schlau schrieb:
> Dann mußt du 5 structs anlegen. 5Byte a 8Bit = 40Bit

Also die Structs dann GLEICH nennen und dann eben andere Bitfelder 
drinnen anlegen oder? also ein STRUCT ist dann IMMER gleich 8 Bit breit.
Weil der Compiler nicht meckert, wenn ich jetzt innerhalb eines Structs 
40 Bit zuweiße.

Danke schonmal!

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prof.Dr.Schlau schrieb:
> Dann mußt du 5 structs anlegen. 5Byte a 8Bit = 40Bit

Bullshit.

In einer struct kannst Du (ganzzahlige) Datentypen Deiner Wahl 
implementieren, also z.B.
struct
{
  uint8_t bStatus_1:5;    // 5 Bit zuweisen
  uint16_t bStatus1_1:12; // 12 Bit zuweisen
  unsigned bStatus_2:1;   // 1 Bit zuweisen
} test;   // Name der Variable

Du kannst natürlich auch in einer struct 5 byte anlegen. Generell sind 
Bitfelder aber nur sinnvoll, wenn RAM wirklich knapp wird, da mehr 
Flash und Zeit verbraucht werden.

Autor: tutorial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das heißt, über solche Bitfelder braucht mein Code länger? Und auch mehr 
Speicher? Ist ja irgednwie wiedersprüchlich oder?
Ich dachte mir ich Spar somit den Platz, weil jetzt hab ich ja wieder 
nur (mit dem obigen Beispiel) einen UINT8_T mit 5 Bit belegt, also auch 
wieder verschwendung?
Wo ist jetzt der Fehler meiner Ansicht?

Grüße

Autor: Bitfeld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lutz schrieb:
> Generell sind
> Bitfelder aber nur sinnvoll, wenn RAM wirklich knapp wird

Das ist eine gewagte Aussage. Ich wage es meinerseits zu behaupten
das die Verwendung von Bitfeldern in den allermeisten Fällen nicht aus
Speichermangel erfolgt.
Unter den ARM Controllern z.B. sind Bitfelder weit verbreitet um
auf Register zuzugreifen. Und sicher nicht weil die zu wenig Speicher
haben.
Flashverbrauch und Ausführungszeit müssen sich nicht zwangsläufig
erhöhen wenn die Alternative zu den Bitfeldern darin besteht händisch
mit Bitshifts zu arbeiten. Wenn es darum geht RAM zu sparen erhöhen
sich diese Wert aber in der Regel schon.
Doch wie gesagt, spielt das RAM-Sparen bei Bitfeldern eine eher
untergeordnete Rolle.

tutorial schrieb:
> Das heißt, über solche Bitfelder braucht mein Code länger?

Möglicherweise. Wenn die tatsächliche Anordnung der Daten im
Speicher für die Funktion des Programms keine Rolle spielt, ist
der Code bestimmt langsamer.

Vielleicht hilft folgendende Abschätzung:
Wenn das Programm auch funktionieren würde wenn man in der Struct
die Bitbreite wegläßt, wird der Code wahrscheinlich größer und
langsamer. Aber sollte das Programm dann nicht laufen, ist die
Alternative wohl auch nicht besser.

Einfacher:
Wenn du dir nicht sicher bist das du Bitfelder brauchst - lass es
bleiben ;)

Autor: tutorial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, aaaalso ich habe Interrupts, diese setzten vieeele vieele 
Arbeitsflags, also wie die LED´s sein soll, was im nächsten durchlauf 
gemacht werden muss usw. Jetzt wollte ich nicht immer 8 Bit für eine 
normale AN / AUS Abfrage machen, drum also ein Bitfeld, welches dann 
gleich acht Flags sind.

Ich verstehe nur noch nicht, warum man in einem Struct dann nochmal ein 
unsigned char einsetzt, diesem dann wiederum nur sechs Bit zuordnet. 
Macht für mich iwie keinen Sinn.

Grüße

Autor: Bitfeld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tutorial schrieb:
> ich habe Interrupts, diese setzten vieeele vieele
> Arbeitsflags

Da würde ein Bitfeld RAM sparen, das Programm aber würde größer und
langsamer werden. Der "Codevision AVR" - ein C-Compiler - kann bei
bei Variablen vom Typ bool einzelne Bits in dafür vorgesehenden
CPU-Registern setzen. Das geht sogar eher schneller als ein
normaler RAM Zugriff und verbraucht überhaupt kein RAM. Bis zu
32 Bool Werte sind da möglich. Das ist einer der wenigen Vorteile
dieses Compilers gegenüber dem avr-gcc.

> Ich verstehe nur noch nicht, warum man in einem Struct dann nochmal ein
> unsigned char einsetzt, diesem dann wiederum nur sechs Bit zuordnet.

Es gibt zwei Anwendungsfälle für Bitfelder:
1. RAM sparen
2. Zugriff auf gegebene Datenstrukturen

Poste doch mal ein Beispiel das du nicht verstehst.

Autor: tutorial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lutz schrieb:
> struct
> {
>   uint8_t bStatus_1:5;    // 5 Bit zuweisen -> Hätte doch 8 Platz?!
>   uint16_t bStatus1_1:12; // 12 Bit zuweisen -> Ich hätte doch 16 platz?!
>   unsigned bStatus_2:1;   // 1 Bit zuweisen
> } test;   // Name der Variable

Hier jetzt mal der Code...
Da hab ich ein Struct und eben in dem variablen angelegt, wobei im 
Tutorial eben nur unsigned dran steht, konnte ich hier eben die 8 Bit 
verteilen und dann war gut.

Also wenn ich jetzt auf die schnelle 20 mal je 2 Bit bräuchte, die ich 
WÄHREND dem Programm nach 0 ... 3 Abfrage, wie mach ich dies dann am 
besten?

Grüße

Autor: Bitfeld (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein einsames "unsigned" bedeutet beim avr-gcc "unsigned int" bzw.
"uin16_t".
Bitfelder sind stark plattformabhängig (Maschine wie Compiler).
Der C-Standard definiert die Funktionsweise einer zusammenhängenden
Bitfolge nur innerhalb eines "in". Beim AVR also 16Bit. Ob ein
Bitfeld nun beim niederwertigsten Bit (AVR) oder beim höchstwertigen
beginnt, ist ebenfalls plattformabhängig.

Wie sich 20*2 Bits am besten verteilen lassen hängt vom Einzelfall
ab. Als Bitfeld könnte man im besten Fall mit 5 Bytes auskommen.
Ohne wären es 20 Bytes. Sollte die 15 Bytes Differenz im RAM Bedarf
tatsächlich entscheidend sein, würde ich es so machen:
struct {
  uint8_t var1  : 2;
  uint8_t var2  : 2;
  uint8_t var3  : 2;
  uint8_t var4  : 2;
  uint8_t var5  : 2;
  ...
  uint8_t var20 : 2;
} meineDaten;

Ein Zugriff auf ein Element wäre dann so möglich:
meineDaten.var7 = 2;
Doch sollte es nicht auf die 15 Bytes ankommen, würde das Programm
schneller laufen wenn man in der Struktur jeweils die ":2" wegläßt.

Strukturen wie sie Lutz genannt hat dienen nicht dazu RAM
einzusparen. Oft haben bestimmte Bits in einer Datenstruktur
eine besondere Bedeutung. Ein Beispiel ist das SPI_I2SPR Register
eines STM32F103 Controllers. Im Anhang ist ein 16Bit Register zu
sehen. Die "Variablen" I2SDIV, ODD und MCKOE belegen bestimmte
Bereiche im Register.
Mit folgender Struktur könnte man darauf zugreifen:
struct {
   uint16_t I2SDIV : 8;
   uint16_t ODD    : 1;
   uint16_t MCKOE  : 1;
} *SPI_I2SPR = SPI_I2SPR_ADDR;
Die Bits 10-15 werden nicht benutzt. Zugriff auf die Felder erfolgt
dann so:
SPI_I2SPR->I2SDIV = 16;
SPI_I2SPR->ODD = 1;

Autor: Prof.Dr.Schlau (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prof.Dr.Schlau schrieb:
> Dann mußt du 5 structs anlegen. 5Byte a 8Bit = 40Bit

klar Quatsch. Ich meinte eigentlich 5Byte a 8Bit in einen struct 
(rausred...)

Autor: tutorial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo wieder ;)

so, also wenn ich das jetzt anwenden will, ist die richtige Anwendung 
dann so geschrieben?:
struct {
   unsigned status0:2;
   unsigned status1:2;
   unsigned status2:2;
   ...
   unsigned status19:2;
} test;

Ich will das auf einem ATmega2560 durchführen, der Compiler meckert 
nicht...
Oder soll ich eben doch lieber 20 8-Bit Variablen anlegen?

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tutorial schrieb:
> Oder soll ich eben doch lieber 20 8-Bit Variablen anlegen?

Würd ich empfehlen.
Außerden kannst du ja die Bitvariablen logisch gruppieren und dann 
zusammen in einem Byte ablegen.
z.B.
#define I2CSTART 1  //als 2er-Potenzwerte
#define I2CLESEN 2
#define I2CSCHREIBEN 4
//...

uint8_t i2c_flag = 0;
//...
if(i2c_flag & (I2CSTART + I2CLESEN))
  //tu was

Sind Bitfelder eigentlich überhaupt im C-Standard? (bin mir nicht 
sicher)
:-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Floh schrieb:

> Sind Bitfelder eigentlich überhaupt im C-Standard? (bin mir nicht
> sicher)
> :-)

Ja sind sie.
Allerdings nur sehr rudimentär und unspezifiziert. Es gibt sie. Recht 
viel mehr steht da nicht drinnen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tutorial schrieb:

> Oder soll ich eben doch lieber 20 8-Bit Variablen anlegen?

Wenn du den Speicher hast, warum nicht?


Über eines musst du dir im klaren sein. Auch wenn die Syntax einfach 
erscheint, den Aufwand da Bits frei zu maskieren und zu extrahieren 
nimmst du dem Prozessor auch mit Bitfeldern nicht ab. So gesehen sind 
Bitfelder syntaktischer Zucker für etwas, was man mit UND und ODER 
Operationen genauso gut erreichen kann. Nur dass dann im Klartext dort 
steht, wenn eine Operation aufwändiger ist und bei Bitfeldern eben 
nicht.

Autor: tutorial (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo und danke für die schnellen Rückmeldungen.

Ich werde jetzt ersteinmal die Variablen mit unsigned char anlegen, 
falls der Platz später wirklich kanpp wird, mach ich das mit der 
Gruppierung und mir UND / ODER.

Danke nochmal!

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tutorial schrieb:
> Ich werde jetzt ersteinmal die Variablen mit unsigned char anlegen,

Man sollte char wirklich nur für ASCI-Zeichen nutzen, ansonsten 
unsigned-Werte (gerade für Flags, es sei denn, man braucht wirklich 
vorzeichenbehaftete Größen). Der Grund war die nationale Sicherheit oder 
so ähnlich. Am besten ist sowieso die Nutzung von uint8_t etc. als 
Notation; da weiß man immer, wie groß der Datentyp wirklich ist (ist ja 
leider plattformabhängig).

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
typedef unsigned char uint8_t;
:-)

Autor: Lutz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitfeld schrieb:
> Das ist eine gewagte Aussage. Ich wage es meinerseits zu behaupten
> das die Verwendung von Bitfeldern in den allermeisten Fällen nicht aus
> Speichermangel erfolgt.
> Unter den ARM Controllern z.B. sind Bitfelder weit verbreitet um
> auf Register zuzugreifen.

Du bist sicher, daß Du nicht "normale" structs meinst? Da hättest Du 
natürlich recht. Hier sind aber explizit Bitfelder gemeint, welche ein 
Sonderfall der structs sind.

Bitfeld schrieb:
> Mit folgender Struktur könnte man darauf zugreifen:struct {
>    uint16_t I2SDIV : 8;
>    uint16_t ODD    : 1;
>    uint16_t MCKOE  : 1;
> } *SPI_I2SPR = SPI_I2SPR_ADDR;

Aus der Standard Peripheral Lib ist das aber nicht, oder? Die benutzen 
da auch immer byte-Vielfache.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.