16-bit int in 2 8-bit int zerlegen

[opc]

Hallo Peter,
der letzte Post war von mir auf einen 6 Jahre alten Thread, aber mit neuer Ausgangslage (wie erwähnt)!

Bitte sieh dir meinen Post an.

[BMS]

Hallo,
ich würde in der Empfangs-Programm vor dem Zusammenbauen a=(b<<8 )|c das most significant byte erst als uint16 casten bevor es geshiftet wird.
Also a=( ((uint16_t)b) <<8 ) |c
Grüße,
Bernhard

[opc]

Grüß dich Bernhard,

erledigt (auch hier im Code im Forum).

Sieht nun so aus:

zahl = (((uint16_t) HByte) << 8 ) | LByte;

Leider immer noch dasselbe Problem.

Gruß
Markus

[Dirk]

... die high hab ich int8_t gemacht, sonst hab ich keine vorzeichen bei der int16_t.

Wenn du die Integer so sendest, wie oben weiter gezeigt, dürfte das nicht stimmen!
Beide 8-Bit-Variablen müssen uint8_t sein.

Gruß Dirk

[HaWe]

uint8_t   highbyte, lowbyte;
int16_t   intval;

// bytes zu int:
intval = lowbyte + (highbyte << 8);

//int zu bytes:
lowbyte  = intval & 0x00ff;
highbyte = (intval >> 8) & 0x00ff;

hoffe, das stimmt...! 8-)

[opc]

@HaWe: ja das ist schon richtig so, mein Fehler muss woanders liegen.

Hab dein Codeschnipsel auch testweise soeben mal eingebaut bzw. ersetzt -> führt leider zum selben Ergebnis.

Habe mal testweise ein delay (1s) nach der Zahlenausgabe aufs 7-Segment geschrieben, daran erkennt man deutlich, dass zwischen zwei völlig wirren Zahlenkombinationen hin- und hergewechselt wird, also scheint der Fehler weiterhin an der Umsetzung 16bit / 2*8bit und umgekehrt zu liegen.

Bin um jeden Tipp dankbar

[HaWe]

bevor nicht fertig gerechnet wurde, darfst du keine Werte ans Display senden...
... und auch natürlich nicht per UART senden!

nachdem das Int/Byte-Zerlege-Problem dann aber gelöst ist, würde ich empfehlen bei weiterhin bestehenden Problemen ein neues Topic zum Thema "UART" oder "Display" aufzumachen, je nachdem, wo das Problem jetzt liegt.

[opc]

wenn ich wüsste woran das Problem liegt^^

aber hast recht... ich eröffne ein neues der Übersichtlichkeit wegen....

[Christoph2]

Ja, stimmt, ich hab die ausgabevariable unsigned gemacht, hab ich übersehen.

Es kommt aber auf das selbe, weil das höchstwertige bit auf jeden fall ein vorzeichenbit ist.

lg
Christoph

[Dirk]

Hallo Christoph2,

Es kommt aber auf das selbe, weil das höchstwertige bit auf jeden fall ein vorzeichenbit ist.

Bei der ganzen Geschichte hier geht es ja nur um das Aufsplitten von einer 16-Bit-Variable (egal ob mit Vorzeichen oder ohne) in zwei 8-Bit-Variablen, um sie über I2C versenden zu können.

Dabei werden einfach die 16 Bits der Ausgangsvariable in 2x 8 Bit aufgeteilt, gesendet und dann beim Empfänger wieder zusammengesetzt.

Das Vorzeichen einer Integer spielt beim byteweisen Versenden gar keine Rolle, denn da werden einfach 2x 8 Bit übertragen. Da könnten auch z.B. Pixel eines Bildes drin sein oder eine Word-Variable, ganz egal.

So erklärt sich, dass auf der "Transportseite" (2 Bytes werden über I2C versendet) die beiden High-/Low-Bytes uint8_t sind:
Jedes Byte transportiert ja nur die 8 Bits und ist daher vorzeichenfrei.

Deutlicher würde das Ganze, wenn man den Vorschlag von Besserwessi mit der Union umsetzt:
Da würde man eine int16_t (oder uint16_t egal) definieren und an derselben Speicherstelle zwei Bytes (uint8_t). Man kann dann an dieser Stelle eine Integer ablegen und direkt als 2 Bytes weiterverarbeiten (z.B. senden).

Puh ...

Zum Schluß noch der Gag: Es funktioniert auch mit int8_t !

Gruß Dirk