Jörg Esser schrieb:
> Gut verstanden. Danke euch erstmal. Muss ich wohl nochmal was lesen und
> lernen.
>
> Kann es sein das man besser die Finger davon läßt damit man portierbar
> bleibt?
Ein weises Wort.
Denn: Wie genau die beiden Bytes in einem 16-Bit int im Speicher
abgelegt werden (in welcher Reihenfolge), wird von C nicht festgelegt.
Das entscheidet die Plattform (also im weitesten Sinne der Hersteller,
der die CPU gebaut hat).
Natürlich gibt es Mittel und Wege, wie man die Operation, so wie du sie
dir vorstellst, implementieren kann. Eine Möglichkeit, umcasten, wurde
ja schon genannt.
Wert1 = *(uint16_t*)&bq2084.V;
Der spingende Punkt ist dann eben: Jetzt bist du in der Pflicht. Der
Compiler ist aus dem Schneider (wie bei allen Casts). WEnn das auf einer
Plattform nicht funktioniert (aus welchen Gründen auch immer: wegen
Padding Bytes, wegen unterschiedlicher Endianess, ....), dann hast du
Mist gebaut und nicht der Compiler.
Die einzig mögliche tatsächlich portierbare Version hast du ja in deinem
Programm schon benutzt. Wenn du die nimmst, dann kann dir nie irgendwas
passieren. Du erkaufst dir das möglicherweise mit ein wenig erhöhter
Laufzeit, bist dafür aber unabhängig.
> Ich habe eigentlich nur damit angefangen um den Code besser lesbar zu
> machen.
> Und eventuell ein wenig komfortabler.
Tja. Das Mittel dazu führt aber eigentlich immer darüber, dass man sich
Funktionalität in Funktionen auslagert. Mit solchem klein/klein
Geplänkel erreicht man nicht sehr viel.
1 | struct results
|
2 | {
|
3 | uint16_t Charge_mA;
|
4 | uint16_t Charge_Voltage;
|
5 | sint16_t mA;
|
6 | uint16_t V;
|
7 | uint16_t Temp;
|
8 | uint16_t Full;
|
9 | } bq2084;
|
10 |
|
11 | ...
|
12 |
|
13 | uint8_t i2cMessageBuf[I2C_MESSAGE_BUFFER_MAX_SIZE];
|
14 |
|
15 | ...
|
16 |
|
17 | bq2084.V = toUint16_t( i2cMessageBuf[0], i2cMessageBuf[1] );
|
18 | uart_put_u16( bq2084.V );
|
19 | uart_put_s( "\n" );
|
Noch übersichtlicher geht dann kaum noch. Und der ganze Kleinkram steckt
in Funktionen.