Bit-Shifting Verständnisproblem

[Manuel H. (manu77)]

Hallo,
eine kurze Frage zu einem Bit-Shift:

uint32_t FirmwareByteAnzahl;
FirmwareByteAnzahl = (uint8_t)0x80;
FirmwareByteAnzahl |= ((uint8_t)0x80 << 8) & 0xFF00;
FirmwareByteAnzahl |= ((uint8_t)0 << 16) & 0xFF0000;

Ohne die UND Operatoren kommt:

11111111 11111111 10000000 10000000

heraus. Wieso sind die letzten beiden Bytes 0xFF ?

[(prx) A. K. (prx)]

Weil "int" auf deiner Maschine nur 16 Bits breit ist.

[Karl M. (Gast)]

Diese Zeile mach schon mal gar nichts!

FirmwareByteAnzahl |= ((uint8_t)0 << 16) & 0xFF0000;

[(prx) A. K. (prx)]

Merke: Bei
  var = expr;
ist die Breite der Arithmetik nicht von "var" abhängig, sondern nur 
von dem, was in "expr" steht.

[Manuel H. (manu77)]

Karl M. schrieb:
> Diese Zeile mach schon mal gar nichts!
> FirmwareByteAnzahl |= ((uint8_t)0 << 16) & 0xFF0000;

Ja Imgrunde stammt der Code aus einer Routine. Die Null kann dort ein 
weiteres Byte sein.

Trotzdem ist es mir nocht nicht klarer geworden.

Wenn ich 0x80 in die Variable lade kommt das raus:

00000000 00000000 00000000 10000000

Wenn ich das Byte 0x80 Shifte und mit Oder reinkopple, müsste doch 
eigentlich folgendes herauskommen:

00000000 00000000 10000000 10000000

[Manuel H. (manu77)]

A. K. schrieb:
> Merke: Bei
>   var = expr;
> ist die Breite der Arithmetik nicht von "var" abhängig, sondern nur
> von dem, was in "expr" steht.

Okay, also muss ich casten:

FirmwareByteAnzahl = 0x80;
FirmwareByteAnzahl |= ((uint32_t)0x80 << 8);

Danke!

[(prx) A. K. (prx)]

Und schau auf die Warnungen des Compilers.
Die sind nicht zum Spass da.

[Rolf M. (rmagnus)]

Manuel H. schrieb:
> Trotzdem ist es mir nocht nicht klarer geworden.
>
> Wenn ich 0x80 in die Variable lade kommt das raus:
> 00000000 00000000 00000000 10000000
> Wenn ich das Byte 0x80 Shifte und mit Oder reinkopple,
> müsste doch eigentlich folgendes herauskommen:
> 00000000 00000000 10000000 10000000

Nur wenn int bei dir 32 Bit breit ist. Bei einem 16-Bit-int kommt 
erstmal raus:
10000000 10000000
Zur Erweiterung auf den uint32_t auf der linken Seite wird nun erstmal 
der int vorzeichenrichtig auf 32 Bit erweitert, was im Prinzip bedeutet, 
daß das oberste Bit des int in die nächsten 16 Bit reinkopiert wird. 
Danach wird dieses Bitpattern dann in einen uint32_t geschrieben.

[(prx) A. K. (prx)]

Und bei der Version mit "& 0xFF00" wirds noch etwas subtiler. Denn 
0xFF00 ist vom Typ "unsigned". Das ändert zwar zunächst nichts am 
Bitpattern des Ergebnisses, aber an dessen Typ. Der ist nun auch vom Typ 
"unsigned". Und der wird bei der Zuweisung ohne Vorzeichen auf 32 Bits 
erweitert.

[Manuel H. (manu77)]

A. K. schrieb:
> Und schau auf die Warnungen des Compilers.
> Die sind nicht zum Spass da.

Das wird bei mir nicht als Warnung aufgeführt.

[(prx) A. K. (prx)]

Welcher Compiler? GCC liefert
warning: left shift count >= width of type
für (uint8_t)0 << 16

[quarzlöter (Gast)]

Da du mal wieder hier vorbeischaust: was ist denn aus der 
Quarz-Reflowsache geworden? wüsste schon gern, worans lag.

[Manuel H. (manu77)]

Habe leider noch keine defekte Platine erwischt, an der ich endlich 
testen kann. Sobald ich eine in den Händen halte, werde ich die neue 
Firmware testen. Teile es dann natürlich im anderen Thread ;)

@ A.K. die Null Version kommt in meinem Code gar nicht vor, ist nur beim 
Posten entstanden.

[(prx) A. K. (prx)]

Ob 0 oder nicht 0, das ist hier nicht die Frage.
Die 16 ist's, um die es geht.

[Manuel H. (manu77)]

A. K. schrieb:
> Ob 0 oder nicht 0, das ist hier nicht die Frage.
> Die 16 ist's, um die es geht.

Die ganze Zeile kommt nicht vor. Hab sie gerade hinzugefügt und du hast 
Recht, er warnt (ist der GCC). Ich werde mehr auf Warnungen achten.