Umrechnung MSB LSB zu INT

[Mauro]

Hallo!

Ich habe einen Sensor, der mir seine Werte als Little Endian rausgibt, also die Bytes MSB und LSB. Soweit bin ich noch dabei :-)

Nun will ich natürlich das ganze umrechnen und bin da jetzt noch nicht ganz schlau.

Sehe ich das richtig, dass MSB und LSB je 8 Bit haben?
Ist das quasi dann MSB*256+LSB=int16_t?

Liebe Grüße und Danke!
eMM

[XBert]

Normalerweise besteht der Unterschied in der Lese/Speicher-richtung.
D.h bei little Endian ist das erste Bit im Speicher das Least Significant Bit im Register. Bei big Endian ist es halt genau umgekehrt.
Weitere Informationen stehen auch auf wikipedia: http://en.wikipedia.org/wiki/Endianness
bzw.: http://www.avrfreaks.net/modules/FreaksFiles/files/271/DN_007.pdf

LG

[Mauro]

Ok, das erklärt die Reihenfolge, aber die Umrechnung ist mir jetzt noch nicht ganz klar...Also das MSB startet ja quasi nach 256 und geht dann bis 65k...komisch, jetzt weiß ich nichtmal mehr wie ich auf meinen Vorschlag gekommen bin :-o

[askazo]

Am einfachsten kombinierst Du MSB und LSB mithilfe einer Schiebeoperation. Und casten nicht vergessen...


((int16_t)(MSB) << 8) | (int16_t)(LSB)


Gruß,
askazo

[Mauro]

Hallo!

Das klingt logisch, damit kann ich was anfangen. ganz links den MSB Wert schreiben und rechts dahinter den LSB Wert.

Danke für den Hinweis!

[Achromat]

Hallo,

hat man große Datenmengen kann man das auch in Assembler abbilden



void CCpconS7::PcShort2SpsInt(short *pVal)
{
__asm
{
mov ebx,pVal
mov ax,[ebx]
xchg al,ah
ror al,8
mov [ebx],ax
}
}

void CCpconS7::SpsInt2PcShort(short *pVal)
{
__asm
{
mov ebx,pVal
mov ax,[ebx]
xchg al,ah
ror ah,8
mov [ebx],ax
}
}


Grüße K aus B

[Peter(TOO)]

Hallo askazo,

Am einfachsten kombinierst Du MSB und LSB mithilfe einer Schiebeoperation. Und casten nicht vergessen...


((int16_t)(MSB) << 8) | (int16_t)(LSB)

x <<8;
und
x * 256;
Sind mathematisch das Selbe. << ist aber oft schneller. Allerdings erzeugen viele optimierende Compiler in beiden Fällen den selben Code.
Wobei << 8 gerne auch nur durch das versetzte speichern eines Bytes erzeugt wird.

MfG Peter(TOO)

[BMS]

Man kann ohne Schiebeoperationen auskommen, indem man direkt in den RAM über Pointer schreibt:

#define SaveU16(u16,MSB,LSB) *(((uint8_t*)(&u16))+0)=LSB; *(((uint8_t*)(&u16))+1)=MSB;
Das sieht furchtbar aus, funktioniert aber ;)
Im Code verwenden mit

SaveU16(Ergebnis,MSByte,LSByte);

Das ist schön kompakt und ist im Hauptprogramm gut lesbar,
ABER: Das funktioniert nur auf 8-Bit Mikrocontrollern, die selber mit Little Endian arbeiten (bei Big Endian müssen +0, +1 getauscht werden), UND das ist nicht ohne weiteres portierbar.

Grüße,
Bernhard

[Peter(TOO)]

Hallo Bernhard,

Das ist schön kompakt und ist im Hauptprogramm gut lesbar,
ABER: Das funktioniert nur auf 8-Bit Mikrocontrollern, die selber mit Little Endian arbeiten (bei Big Endian müssen +0, +1 getauscht werden), UND das ist nicht ohne weiteres portierbar.
Es funktioniert auch auf 16-Bit, 32-Bit usw. CPUs, wichtig ist, dass die CPU 8-Bit Zugriffe auf den ganzen Speicher machen kann.

Eine andere, nicht portierbare Variante, ist über unions. Man legt zwei Bytes und den 16-Bit Wert einfach übereinander.

Wer einmal in der Verlegenheit war portierbaren Code zu schreiben wird nur noch die Variante mit <<8 verwenden. Zumal vernünftige optimierende Compiler Code erzeugen, welche deiner Pinter-Geschichte entspricht. Es werden also keine Shifts um 8 Bit erzeugt, sondern das Byte entsprechend versetzt abgespeichert :-)
Dies funktioniert auch bestens mit 32-Bit und es ist egal ob die CPU mit Little/Little, Big/Big, Big/Little oder Little/Big Endian arbeitet.

Bei manchen RISC-CPUs kommt noch hinzu, dass diese zwischen Big- und Little-Endian per Software umschalten können, da überlasse ich die Übersicht erst recht dem Compiler!

Ich habe viel portierbaren Code schreiben müssen, vor allem Übertragungsprotokolle zwischen µCs und PCs.
Die Portierbarkeit war vor allem ein Akt der Faulheit. Wird das Protokoll irgendwie erweitert, muss man nur einmal den Code ändern und 2x compilieren.

Meistens habe ich auch fopen(), fread() usw. im Code verwendet, wie das unter einem PC-Betriebssystem üblich ist.
Auf dem µC wurden dann diese Funktionen mit Macros ersetzt und auf die einzige vorhandene Schnittstelle umgelenkt.

MfG Peter(TOO)

[Klebwax]

x <<8;
und
x * 256;
Sind mathematisch das Selbe.

Das mag schon sein. Aber, worum geht es hier:

das LSB sind (wie der Name sagt) die unteren 8 Bit also kommen sie direkt in das Ergebniss. Das MSB sind die 8 obern Bit des Ergebnisses, also müssen sie um 8 binäre Stellen nach links geschoben werden. Das Zusammensetzen ist ein binäres Oder. So ist die Operation zu verstehen und so sollte man sie hinschreiben. Und da es hier um reine binäre Operationen (dem Zusammensetzen von 2 mal 8 Bit zu 16 Bit) sollte auf reine binäre Werte gecastet werden:


(uint16_t) MSB << 8) | (uint16_t) LSB

Den Rest sollte man dem Compiler überlassen. Wenn man sich daran gewöhnt, das als Programm hinzuschreiben was man wirklich erreichen will und nicht, wie es auch gehen könnte, macht man weniger Fehler. Auch sollte man es unterlassen, irgendwelche Annahmen darüber zu machen, wie der Prozessor eine Variable im RAM ablegt. Nicht umsonst versuchen moderne Sprachen Pointer ganz zu vermeiden.

MfG Klebwax

[Peter(TOO)]

Hallo Klebwax,

das LSB sind (wie der Name sagt) die unteren 8 Bit also kommen sie direkt in das Ergebniss. Das MSB sind die 8 obern Bit des Ergebnisses, also müssen sie um 8 binäre Stellen nach links geschoben werden. Das Zusammensetzen ist ein binäres Oder. So ist die Operation zu verstehen und so sollte man sie hinschreiben. Und da es hier um reine binäre Operationen (dem Zusammensetzen von 2 mal 8 Bit zu 16 Bit) sollte auf reine binäre Werte gecastet werden:


(uint16_t) MSB << 8) | (uint16_t) LSB
Die *256 stammen aus der Ausgangsfrage.

Wir sind hier zwar bei C/C++ aber nicht alle Programmiersprachen kennen einen Shift-Befehl.

In BASIC gab es früher nur die Möglichkeit mit 256 zu multiplizieren, weshalb diese Schreibweise auch sonst noch vorkommt oder verwendet wird.
Technisch ist es nun mal bei modernen Compilern egal, welche Variante man wählt. Welche Variante übersichtlicher ist, kommt auch noch auf den Kontext an.

Es gibt viele Anachronismen, welche heute noch vorhanden sind. Die IP-Adresse ist eigentlich ein 32-Bit Wert. Da in den 60er Jahren, die meisten Programmiersprachen nur dezimal anzeigen konnten, wurde sie in 4 8-Bit Werte geteilt und jedes Byte Dezimal dargestellt. Ein weiteres Problem aus den Anfängen bestand darin, dass oft nur Zahlen angezeigt werden konnten und keine Buchstaben vorhanden waren. Deshalb war damals auch Octal sehr beliebt.
Die Hex-Darstellung ist eigentlich erst in den 70er Jahren im Hobby-Bereich entstanden. Zwar nicht ganz elegant, konnte man mit einer 7-Segmant-Anzeige die Buchstaben A...F unterscheidbar anzeigen.
Die Industrie blieb aber noch lange bei Decimal und Octal. Generell dauerte es bis in die zweite Hälfte der 70er Jahre, bis sich binäre Schreibweisen durchgesetzt hatten (z.B. KByte als 1024). Bis dahin war die dezimale Denkweise noch zu sehr in den Köpfen verankert. Besonders bei den Speichermedien ist es bis heute erhalten geblieben. Und alte Festplatten hatten tatsächlich Sektorgrössen von 250 Byte und nicht 256.
Auch, dass heutige CPUs noch BCD beherrschen ist ein Relikt aus alten Tagen, binär war früher irgendwie Bäääh!

MfG Peter(TOO)