'C" und bits

Hallo,

unsigned int x=0b10011110;

invalid suffix "b10011110" on integer constant

Zitat:

---

Also bei Gnu GCC bin ich mir nicht sicher, aber bei AvrGCC ist das möglich.

---

Ich benutze PN2 fur Asuro ist dass denn nicht AvrGCC?

Gruss

Henk

Wenn ich eine Variable von char deklariere, hat sie noch nichts mit ASCII zu tun:
Grundlagen C:

char 1 Byte min -128 max 127
unsigned char 1 Byte min 0 max 255
bei 32 Bit Prozesoren:
int 4 Bytes -2147483648 max 2147483647
unsigned int 4 Bytes min 0 max 4294967295

int ist wiederrum Prozessorabhängig sehe z.B inttypes.h
Hiermit ist wohl klar, wenn ich eine Zahl darstellen will, die maximal den Wert 255 annehmen kann nehm ich unsigned char und nicht int, das wäre Speicherverschwendung!

Gruß Sebastian

P.S.
Es gibt kein GNU gcc...
was meint Ihr für was dieses g steht ?

Ich habe mal in den Kernigan + Ritchie geschaut:

Code:

---

2.4.1 Ganzzahlige Konstanten
  Eine ganzzahlige Konstante besteht aus einer Kette von Ziffern. Sie hat den Typ int und wird normalerweise dezimal interpretiert.

  Falls die Kette mit der Ziffer 0(null) beginnt, wird sie oktal, also in Basis 8, interpretiert. Dabei besitzen die Ziffern 8 und 9 jeweils die oktalen Werte 10 und 11.

  Falls die Kette mit der Folge 0x oder 0X (Ziffer null, Buchstabe x) beginnt, wird sie hexadezimal, also in Basis 16, interpretiert. Dabeigelten dann die Buchstaben a (oder A) bis f (oder F) als hexadezimale Ziffern mit den dezimalen Werten 10 bis 15.

---

Da dieses Buch ja so etwas wie die Bibel für C ist und da nichts von b oder B steht, muss das auch nicht in jedem Compiler vorhanden sein. #-o

@Vogon,
eben ein Blick in die schon von mir genannte inttypes.h sagt genau dasselbe,
nix mit 'b'...
Ich warte aber noch ab, bis die richtigen C Profis hier ans Wort kommen,
aber meine leise Behauptung lautet, vergiß es mit 0bblabla , das klappt wohl in Assembler und nicht in C.
Außerdem wozu das ganze ? Hex zu schreiben ist doch viel einfacher.

Gruß Sebastian

Genau, schreibs als Hex-Wert! Binär-System sagt dir was? Also wie man das berechnet?

Also ich verwende ICC AVR, der Compiler beinhaltet 0b (blablabla)

Scheint also wirklich Compilerabhängig zu sein. Aber wie ihr schon sagtet, HEX oder Dezimal tuts ja auch...

Aber gerade für den Anfang find ich die binäre Darstellung einfacher, weil Verständlicher (man sieht sofort, welche Bits angesprochen werden)

Die Präfix 0b für Binärkonstanten gibt es nur ein einigen Versionen für avr-gcc. Mal war es drinne, dann wurde es rausgeworfen, dann wieder rein...

Standard-C ist es nicht. Wenn man es haben will, könnte man sich eine solche avr-gcc-Version installieren oder wenn man sich die Arbeit machen will, seinen Compiler patchen. Die Quellen hat man ja. Ich hatte hier auch mal beschrieben wo man was ändern muss, aber ich find den Post nicht mehr, womöglich wurde er sogar gelöscht?

Wenn man öfter mit hex-Zahlen arbeitet, dann sieht man auch schnell, welche Bits da gesetzt sind und welche nicht. Es sind ja nur die 16 Werte 0...15 und beim nächsten Nibble siehts wieder gleich aus

0000 = 0x0
0001 = 0x1
0010 = 0x2
...
1010 = 0xa
1011 = 0xb
...
1111 = 0xf

Oder man mache es mit einer Maske:
0b100 = (1 << 2)
Wenn mehrere Bits gesetzt werden sollen, ist das allerdings umständlich.

::EDIT::

Hier ist der Beitrag:
https://www.roboternetz.de/phpBB2/ze...=125217#125217

Bei uns an der Fh hatten wir auch eine avr.h, die es ermöglicht z.B. soetwas zu konstruieren:

TIMSK=TIMSK|BIT(OCIE1A);

wobei BIT (OCIE1A) eine Bitfolge mit einer 1 an der entsprechenden Position erzeugte (Bit4)...

Das machte das ganze sehr übersichtlich...

War allerdings nur auf den 8535 gemünzt....

Code:

---

#define BIT(x) (1 << (x))

---

Dafür gibt es auch das Makro _BV(x)

Genau, das hat dann allerdings solch riesen Konstrukte, wie dieses dort zufolge:

Code:

---


XYZ |= _BV(1) | _BV(3) | _BV(6) | _BV(7);

---

... wo man jedes Bit einzeln setzen muss. Bei festen Werten finde ich es daher übersichtlicher, den Wert nach Hex umzurechnen.