Bitweiser Schiebeoperator über 8 stellen

[pszy (Gast)]

Hallo,
Ich habe im EEPROM 4 Bytes, die ich in eine Variable vom Typ unsigned 
long speichern muss.
Dazu habe ich folgenden Code geschrieben:

unsigned long epoch = 0;

epoch = (EEPROM.read(1) << 24);
epoch += (EEPROM.read(2) << 16);
epoch += (EEPROM.read(3) << 8);
epoch += (EEPROM.read(4));

In der variable steht jetzt aber immer statt z.b. 4F11A2D5 der wert 
FFFFA2D5. Warum? Die Daten sind im eeprom auf jeden Fall 
richtigbabgelegt und werden auch korrekt ausgelesen.

Grüße

[na sowas (Gast)]

Mein Tipp: vor dem Schieben kommt das Casten...

[pszy (Gast)]

Vielleicht sollte ich noch erwähnen, dass ich einen atmega328 verwende

[pszy (Gast)]

Die Antwort war ja schnell :)

Wie genau gehts das denn in meinem Fall? Ich habe so probiert:

epoch = static_cast<unsigned long> (EEPROM.read(1) << 24);

Compiler hat nicht gemeckert. Funktionieren tuts dennoch nicht.

[Chris H. (hergi)]

probier mal so:

unsigned long epoch = 0;

epoch = (((unsigned long)EEPROM.read(1)) << 24);
epoch += (((unsigned long)EEPROM.read(2) << 16);
epoch += (((unsigned long)EEPROM.read(3) << 8);
epoch += (((unsigned long)EEPROM.read(4));

[pszy (Gast)]

Danke Chris!
Bis dass da ein paar Klammern fehlten hat es so funktioniert :)

Grüße

[marcus6100 (Gast)]

Nimm lieber uint32_t anstatt unsigned long. Das ist deutlicher.

Auch wenn der Compiler den Aufwand der Addition vermutlich wegoptimiert 
solltest du | benutzen.

Die Verwendung einer Addition um bitweise einen Wert zusammenzusetzen 
ungewöhnlich. Die Operator Precedence von bitwise or passt mit addition 
auch nicht zusammen.

Die Operator precedence ist:
erst: typecast
dann: addition
dann: bitwise shift
dann: bitwise or

Du kannst das also ohne die ganzen Klammern auch so schreiben:

uint32_t epoch;
epoch = (uint32_t)EEPROM.read(1) << 24
        | (uint32_t)EEPROM.read(2) << 16
        | (uint16_t)EEPROM.read(3) << 8
        | EEPROM.read(4);

oder:
epoch = (uint32_t)EEPROM.read(1) << 24 | (uint32_t)EEPROM.read(2) << 16 | (uint16_t)EEPROM.read(3) << 8 | EEPROM.read(4);

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

marcus6100 schrieb:
> Nimm lieber uint32_t anstatt unsigned long. Das ist deutlicher.
Ähm...
Kannst du das mal begründen?

[Peter D. (peda)]

marcus6100 schrieb:
> Auch wenn der Compiler den Aufwand der Addition vermutlich wegoptimiert
> solltest du | benutzen.

Macht der AVR-GCC nicht.
Aber der OR-Code ist noch umständlicher (größer).
Der AVR-GCC ignoriert alle Codetextoptimierungen hartnäckig.


Peter

[Oo0 (Gast)]

Lothar Miller schrieb:
> marcus6100 schrieb:
>> Nimm lieber uint32_t anstatt unsigned long. Das ist deutlicher.
> Ähm...
> Kannst du das mal begründen?

uint32_t ist ein 32 Bit Integer ohne Vorzeichen. unsigned long ist von 
der Plattform abhaengig in der Laenge, ohne Vorzeichen.

Da im EEPROM 4 Byte abgespeichert sind die einen Integer-Wert abbilden, 
ist es durchaus sinnvoll, einen dazu passenden Datentyp zu verwenden und 
erst anschliessend in den im Programm verwendeten Typ zu konvertieren. 
Was im Idealfall sowieso wegfaellt.