- MultiPlus Wechselrichter Insel und Nulleinspeisung Conrad         
Ergebnis 1 bis 10 von 11

Thema: Umrechnung MSB LSB zu INT

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    67
    Beiträge
    2.435
    Hallo askazo,
    Zitat Zitat von askazo Beitrag anzeigen
    Am einfachsten kombinierst Du MSB und LSB mithilfe einer Schiebeoperation. Und casten nicht vergessen...
    Code:
    ((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)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  2. #2
    Erfahrener Benutzer Roboter Genie Avatar von BMS
    Registriert seit
    21.06.2006
    Ort
    TT,KA
    Alter
    34
    Beiträge
    1.192
    Man kann ohne Schiebeoperationen auskommen, indem man direkt in den RAM über Pointer schreibt:
    Code:
    #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
    Code:
    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
    "Im Leben geht es nicht darum, gute Karten zu haben, sondern auch mit einem schlechten Blatt gut zu spielen." R.L. Stevenson

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    67
    Beiträge
    2.435
    Hallo Bernhard,
    Zitat Zitat von BMS Beitrag anzeigen
    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)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Peter(TOO) Beitrag anzeigen
    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:

    Code:
    (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
    Strom fließt auch durch krumme Drähte !

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    67
    Beiträge
    2.435
    Hallo Klebwax,
    Zitat Zitat von Klebwax Beitrag anzeigen
    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:

    Code:
    (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)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

Labornetzteil AliExpress