3 hex bytes zu 1 dezimalwert umrechnen

OP #650080
Lesenswert?

Und ich schon wieder! Ein Problem jagt das nächste...

Ich bekomme von meinem 24bit AD Wandler 3bytes zurück, die ich in die 
gemessene Spannung umrechnen möchte (z.B. 7b, 6c, 9d). Am liebsten nach 
folgendem Schema:

     D:  13 ·       1 =       13
     9:   9 ·      16 =      144
     C:  12 ·     256 =     3072
     6:   6 ·    4096 =    24576
     B:  11 ·   65536 =   720896
     7:   7 · 1048576 =  7340032
                        ————————
                         8088733

Nur verstehe ich ncoh nicht, wie ich die 3 einzelnen bytes zerlegen kann 
und dann damit weiterrechen soll...

Hat jemand einen Vorschlag?

MfG
Björn
#650091
Lesenswert?

@ Björn W. (bjoern2007)

>Ich bekomme von meinem 24bit AD Wandler 3bytes zurück, die ich in die
>gemessene Spannung umrechnen möchte (z.B. 7b, 6c, 9d). Am liebsten nach

>Nur verstehe ich ncoh nicht, wie ich die 3 einzelnen bytes zerlegen kann

Warum zerlegen? Du musst sie eher zusammenführen.

unsigned long big;

big = value1 <<16L | value2 <<8L | value3;

>und dann damit weiterrechen soll...

Festkommaartihmetik

MfG
Falk
#650094
Lesenswert?

Björn W. wrote:

> Nur verstehe ich ncoh nicht, wie ich die 3 einzelnen bytes zerlegen kann
> und dann damit weiterrechen soll...

Garnicht.

Die Bytes sind ja schon binär und damit im richtigen Format jeder CPU.

Unter C mußt Du sie nur auf 32 Bit erweitern, da C keinen 24Bit-Typ 
kennt.
1
unsigned long val = byte0 | (byte1 <<8) | ((unsigned long)byte2 << 16);


Peter
#650096
Lesenswert?

Vielleicht besser mit Klammern, bei C kann das bisweilen schief gehen.

big = (value1 <<16L) | (value2 <<8L) | value3;

Das L ist so ein Trick den man wissen muss, damit werden die 
Schiebeoperationen in 32 Bit long durchgeführt. Ohne würden sie implizit 
in 16 Bit INT durchgeführt und zumindest des höchstwertige Byte würde im 
Nirvana landen. Böser Fehler.

MfG
Falk
#650102
Lesenswert?

Falk Brunner wrote:

> Das L ist so ein Trick den man wissen muss, damit werden die
> Schiebeoperationen in 32 Bit long durchgeführt.


Hab ich eigentlich auch so gelernt, daß der Ergebnistyp immer der größte 
aus beiden Operanden ist.

Aber einmal bin ich damit furchtbar auf die Fresse gefallen. Eine 
WINAVR-Version hat sich nur am Typ des linken Operanden orientiert und 
das L des rechten Operanden ignoriert. Seitdem caste ich jetzt immer den 
linken Operanden.

Muß mal probieren, ob der aktuelle WINAVR es wieder richtig macht.


Peter
#650119
Lesenswert?

@ Björn W. (bjoern2007)

>Wenn ich 14329 wieder in Hex manuell umwandle, erhalte ich 0x37F9. Das
>würde bedeuten, daß die 0x78 verloren gehen...

Wie Peter feststellte scheinen einge Compiler da etwas nachlässig zu 
sein. Versuch mal das was Peter schrieb.

MfG
Falk

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren