'C" und bits

[Arexx-Henk]

Hallo,

vielleicht eine dumme Frage,

aber kan mann in GNU GCC auch bitweis ein Variabele fullen?
Ich find daruber nix im GNU Dokumentation.

z.B.
unsigned char x;

x='10011110';

???

Gruss

Henk

[PasstScho]

Hi,


//bits
unsigned char x=0b10011110;
//hexa
unsigned char x=0xAB; // ist aber nicht 10011110

MfG Alex

[Arexx-Henk]

@Alex

unsigned char x=0b10011110;

gibt bei mir compiler fehler,

invalid suffix "b10011110" on integer constant


Gruss

Henk

[nabla]

Genau,

bei deiner Variante

x=10011110

würde er es als Dezimalzahl

und bei

x="10011110"

als String übernehmen !

[nabla]

Du kannst es natürlich nicht als char-Datentyp initialisieren, sondern als integer (int) Wert!

also

unsigned int x=0b10011110;

[skillii]

Das hat nichts mit dem Typ der Variable zu Tun, also ob die Variable vom Typ "unsigned char" ist oder vom Typ "unsigned int".
"unsigned char" ist kein String sondern nur ein einziges Zeichen bzw. einfach ein Datenbyte, jenachdem wie man den Wert halt interpretiert.

Ich glaube das mit dem 0b10101010 funktioniert nicht bei jedem Compiler, also ich schreibe es immer mit "0x" (also im Hex Format), ein bisschen Kopfrechnen schadet außerdem keinen ;).

mfg

[PasstScho]

unsigned char x=0b10011110;

gibt bei mir compiler fehler,

invalid suffix "b10011110" on integer constant


Gruss

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

MfG Alex

[nabla]

Wie gesagt falscher Datentyp!

[izaseba]

Wie gesagt falscher Datentyp!

Kannst Du diese Aussage begründen ?

Gruß Sebastian

[nabla]

Nee Sorry,

hab falsch gedacht. Ich weise dann ja bei char halt nur das jeweilige ASCII-Zeichen zu, oder?

Also für 0b00110001 z.B. die 1

Richtig, oder denke ich gerade völlig falsch...

[Arexx-Henk]

Hallo,

unsigned int x=0b10011110;

invalid suffix "b10011110" on integer constant



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

[izaseba]

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 ?

[Vogon]

Ich habe mal in den Kernigan + Ritchie geschaut:

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

[izaseba]

@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

[SeveQ]

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

[nabla]

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)

[SprinterSB]

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/zeigebeitrag.php?p=125217#125217

[nabla]

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

[SprinterSB]

#define BIT(x) (1 << (x))
Dafür gibt es auch das Makro _BV(x)

[SeveQ]

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




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.