vier 8bit Variablen in eine 32bit Variable

[test (Gast)]

Hallo,

ich möchte eine 32bit Zahl in ein CAN-Frame verpacken, vom RPi 
verschicken und in einem µC wieder entpacken.

Ist das so wie dargestellt richtig?

unsigned int _4567;

frame.data[4] = _4567;
frame.data[5] = _4567>>8;
frame.data[6] = _4567>>16;
frame.data[7] = _4567>>24;

[...]
sende ueber can 
[...]

uint32_t msg_in_32 = 0;

msg_in_32 = msg.data[7];
msg_in_32 = 8<<msg_in_32;
msg_in_32 = msg.data[6];
msg_in_32 = 8<<msg_in_32;
msg_in_32 = msg.data[5];
msg_in_32 = 8<<msg_in_32;
msg_in_32 = msg.data[4];

[Karl H. (kbuchegg)]

test schrieb:

> msg_in_32 = msg.data[7];
> msg_in_32 = 8<<msg_in_32;
> msg_in_32 = msg.data[6];

Nope.
Hier überschreibst du dir ja msg_in_32 komplett!

Das ist nicht das was du willst. Denn selbst, wenn die vorhergehenden 
Operationen korrekt gewesen wären, wäre damit der 'Beitrag' von 
msg.data[7] komplett 'aus dem Rennen' genommen worden. Zuweisung ist 
Zuweisung. Und dabei wird der linke Teil von der Zuweisung unter 
Beachtung seines Datentyps komplett beschrieben.

Ausserdem stimmt die Angabe beim Verschieben nicht

    a << b

bedeutet: verschiebe den Inhalt von a um b Bits nach links.
Genauso wie

    a >> b

bedeutet: verschiebe den Inhalt von a um b Bits nach rechts.

Links von der Operation, egal ob << oder >>, steht das "womit". Und 
rechts von der Operation steht um "wieviele" Bits.
Liest du denn kein C Buch, ehe du mit programmieren anfängst? Da wirst 
du noch ein paar mal schön auf die Schnauze fallen.

[test (Gast)]

Wie kann ich dann das Problem lösen?

[Tobias S. (x12z34)]

Hallo,

ich denke*, Du suchst etwas wie das Folgende, wobei msg_in_32 den 
übertragenen Wert enthält, der in die 4 Array-Werte msg.data[x] 
"aufgesplittet" wird.

msg.data[4] = (msg_in_32 & 0x000F);
msg.data[5] = (msg_in_32 & 0x00F0) >> 8;
msg.data[6] = (msg_in_32 & 0x0F00) >> 16;
msg.data[7] = (msg_in_32 & 0xF000) >> 24;

*Oder habe ich mal wieder einen kapitalen Denkfehler gemacht? ;-)

[Karl H. (kbuchegg)]

Tobias S. schrieb:
> Hallo,
>
> ich denke*, Du suchst etwas wie das Folgende, wobei msg_in_32 den
> übertragenen Wert enthält, der in die 4 Array-Werte msg.data[x]
> "aufgesplittet" wird.
>
>

msg.data[4] = (msg_in_32 & 0x000F);
> msg.data[5] = (msg_in_32 & 0x00F0) >> 8;
> msg.data[6] = (msg_in_32 & 0x0F00) >> 16;
> msg.data[7] = (msg_in_32 & 0xF000) >> 24;

>
> *Oder habe ich mal wieder einen kapitalen Denkfehler gemacht? ;-)

Falsche Datenflussrichtung.
Er hat die 4 Einzelwerte und will sie zusammensetzen.

[Karl H. (kbuchegg)]

test schrieb:
> Wie kann ich dann das Problem lösen?

Na, ja.
Die 4 Bytes eben geeignet verschoben wieder zusammensetzen.

msg_in_32  = ( (uint32_t)msg.data[7] << 24 )   |
             ( (uint32_t)msg_data[6] << 16 )   |
             ( (uint32_t)msg_data[5] <<  8 )   |
             ( (uint32_t)msg_data[4]       );

ein bischen optimieren könnte man das noch bezüglich der Casts.

[Tobias S. (x12z34)]

Hallo Karl Heinz, ich zitiere mal von oben:

unsigned int _4567;

[...]
sende ueber can 
[...]
uint32_t msg_in_32 = 0;
msg_in_32 = msg.data[7];
[...]

für mich sah das so aus, dass er schon über CAN gesendet hat und den 
32bitter wieder auseinanderpfriemeln will, daher auch der Name 
msg_*in*_32.

Wie gesagt, wäre aber nicht das erste Mal, dass ich mich irre ;-)

[TomA. (Gast)]

Hallo Test,

fasse deine Variablen, auf beiden Seiten, in einer "union" zusammen und 
das Problem ist gelöst.

Gruß. Tom

[Random .. (thorstendb)]

packed union, um sicherzugehen :-)

[Dr. Sommer (Gast)]

TomA. schrieb:
> fasse deine Variablen, auf beiden Seiten, in einer "union" zusammen und
> das Problem ist gelöst.
Ja, aber nur wenn Ziel&Quell -Platform die selbe Endianness haben. 
Ansonsten sind die Bytes falsch herum. Wenn man hingegen Bitshifts wie 
oben verwendet, stellt der Compiler sicher dass sie immer die richtige 
Reihenfolge haben (LE in diesem Fall). So bleibt der Code portabel.

[test (Gast)]

Karl Heinz schrieb:

> msg_in_32  = ( (uint32_t)msg.data[7] << 24 )   |
>              ( (uint32_t)msg_data[6] << 16 )   |
>              ( (uint32_t)msg_data[5] <<  8 )   |
>              ( (uint32_t)msg_data[4]       );

Ich werde es genau so machen.
Danke!

[Frank M. (ukw) (Moderator)]

Karl Heinz schrieb:
>>

msg.data[4] = (msg_in_32 & 0x000F);
>> msg.data[5] = (msg_in_32 & 0x00F0) >> 8;
>> msg.data[6] = (msg_in_32 & 0x0F00) >> 16;
>> msg.data[7] = (msg_in_32 & 0xF000) >> 24;

>>
>> *Oder habe ich mal wieder einen kapitalen Denkfehler gemacht? ;-)
>
> Falsche Datenflussrichtung.

Nicht nur das. Maskieren von Nibbles statt Bytes ist hier wenig 
zielführend. ;-)

[PittyJ (Gast)]

msg.data[4] = (msg_in_32 & 0x000000FF);
 msg.data[5] = (msg_in_32 & 0x0000FF00) >> 8;
 msg.data[6] = (msg_in_32 & 0x00FF0000) >> 16;
 msg.data[7] = (msg_in_32 & 0xFF000000) >> 24;

oder erst schieben, und dann maskieren. ist dann immer 0xff:

..
 msg.data[4] = (msg_in_32 >>  0 ) & 0xff;
 msg.data[5] = (msg_in_32 >>  8 ) & 0xff;
 msg.data[6] = (msg_in_32 >> 16 ) & 0xff;
 msg.data[7] = (msg_in_32 >> 24 ) & 0xff;
..

[Jobst Q. (joquis)]

Wenn msg.data[] vom typ unsigned char ist, kann man sich das maskieren 
mit 0xff sparen, weil nicht mehr Bits reinpassen.

[hp-freund (Gast)]

Mit Zeigern kann man das Ganze doch einfacher machen oder?

[Dr. Sommer (Gast)]

hp-freund schrieb:
> Mit Zeigern kann man das Ganze doch einfacher machen oder?

Dann hast du aber genau das gleiche Problem wie mit unions:

Dr. Sommer schrieb:
> TomA. schrieb:
>> fasse deine Variablen, auf beiden Seiten, in einer "union" zusammen und
>> das Problem ist gelöst.
> Ja, aber nur wenn Ziel&Quell -Platform die selbe Endianness haben.
> Ansonsten sind die Bytes falsch herum. Wenn man hingegen Bitshifts wie
> oben verwendet, stellt der Compiler sicher dass sie immer die richtige
> Reihenfolge haben (LE in diesem Fall). So bleibt der Code portabel.

[hp-freund (Gast)]

Ok. Das ist Richtig.

[Peter II (Gast)]

hp-freund schrieb:
> Mit Zeigern kann man das Ganze doch einfacher machen oder?

nur wenn du immer auf gleichen (Big|Little) Edian-Systemen arbeitest.


Auch mit memcpy kann man arbeiten, aber das gleichen Problem.