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

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.