HMC5983 Output konvertieren

Mmh. Eigentlich ist es ja nur ein 12-Bit wert. Was ist wenn du sowas 
machst als wenn er left-aligned wäre:

1

int16_t z_value   = (( ((int16_t)recv_data[0]) <<8)+recv_data[1]) >> 4;

Thomas Schmidt schrieb:

> Ich verwende nun folgenenden Code um eine Variable zuerzeugen:
>

1

> // recv_data ist ein uint8_t Array, enthält an Stelle 0 das MSB und an 

2

> Stelle 1 das LSB

3

> int16_t z_value   = ( ((int16_t)recv_data[0]) <<8)+recv_data[1];

4

>

>
> Eigentlich erwarte ich jetzt einen Wert zwischen 0xF800–0x07FF
> (-2048–2047)
> Ich bekomme aber Werte von beispielsweise -20000 oder +500000.
> Was für einen Fehler mache ich?

Welchen Datentyp hat den recv_data[0].

Generell: Wenn du mit Bytes hantierst, dann willst du solange wie 
möglich auf der Unsigned Schiene bleiben, damit dir keine 
Fehlinterpretation des Most signifikant Bit unterkomme. Du willst 
schliesslich die Bytewerte genau so durch die Gegend schieben, wie du 
sie vom Sensor kriegst.

Und erst dann, wenn alles an seiner korrekten Position ist (für einen 16 
Bit Wert), dann willst du den Übergang auf signed und auf die in deinem 
System herrschende Byte-Breite für int machen. Wobei du zuerst auf 
16-Bit signed gehst und erst dann gegebenenfalls diesen 16-Bit signed 
Wert auf bspw. 32 Bit signed aufblasen lässt.

Das ist alles eine Frage der Reihenfolge der Operationen. Wenn die nicht 
stimmt, dann kommt es zu genau den von dir geschilderten Ergebnissen.

Wobei ein int16_t Wert natürlich nicht +50000 sein kann. Da hat holger 
absolut Recht. Da muss man auch mal die Ausgabe etwas genauer unter die 
Lupe nehmen.

Und auch immer berücksichtigen:
In C wird nicht kleiner als int gerechnet. nicht uint8_t, nicht int8_t, 
nicht int16_t oder uint16_t, sondern int! Was auch immer die Bytebreite 
von int auf deinem System ist.

holger schrieb:
>>Ich bekomme aber Werte von beispielsweise -20000 oder +500000.
>>Was für einen Fehler mache ich?
>
> Deine Ausgaberoutine baut scheisse.

Das war auch schon so eine Vermutung, ich werde dann alle variablen 
wieder als uint32_t deklarieren und nochmal testen.
Ausgabe erfolgt über ein Display, zuerst wird per snprintf die Variable 
in einen String geschrieben und dann ausgeben. Formatspecifier ist %d. 
Oder muss ich hier doch %u verwenden?

> Ich bekomme aber Werte von beispielsweise -20000 oder +500000.

mir fällt noch ein Fehler ein, bei dem es so aussieht, als ob derartige 
Werte entstehen würden. (zb auf einem LCD)

Dreh und Angelpunkt ist die Beobachtung, dass ein Überschreiben eines 
Textes mit einem anderen - kürzeren - Text selbstverständlich NICHT den 
überstehenden Textteil überschreibt.

Hab ich Display stehen

1

Hallo Welt

und schreibe ich da, beginnend mit dem Zeilenanfang, den Text "Juhu" 
drüber, dann entsteht logischerweise

1

Juhuo Welt

Bei Texten ist das völlig klar und von weitem zu sehen. Bei Zahlen 
hingegen kann es zb zu der Situation kommen, dass am LCD

1

100

steht. Und wenn ich die mit zb 99 überschreibe und nicht bedenke, dass 
100 aus 3 Stellen besteht, 99 aber nur aus 2, dann landet man bei der 
Anzeige bei

1

990

Ein Mensch liest dann neunhundert-neunzig, wo eigentlich 99 stehen 
sollte und auch steht. Nur steht eben auch noch die Einerstellen-0 von 
den 100, die vorher dort gestanden ist, dort.

printf bietet schöne Möglichkeiten, wie man dafür sorgen kann, dass 
Zahlenausgaben immer die gleiche Länge haben und gegebenenfalls links 
mit wahlweise führenden 0-en oder Leerzeichen aufgefüllt wird.

Wenn es das nicht ist, dann wird dir wohl nichts anderes übrig bleiben, 
als die Salamitaktik aufzugeben und endlich mal etwas kompletteren Code 
zu zeigen, damit man den Datentypfehler suchen kann, der dir irgendwo in 
den Weiten des Programms passiert ist.

Karl Heinz schrieb:
>> Ich bekomme aber Werte von beispielsweise -20000 oder +500000.
>
> mir fällt noch ein Fehler ein, bei dem es so aussieht, als ob derartige
> Werte entstehen würden. (zb auf einem LCD)
>
> Dreh und Angelpunkt ist die Beobachtung, dass ein Überschreiben eines
> Textes mit einem anderen - kürzeren - Text selbstverständlich NICHT den
> überstehenden Textteil überschreibt.


Vor jeder aktualisierung findet ein Display clear statt, die Werten 
können aber auch von 500000 auf 2000 springen.

Thomas Schmidt schrieb:

> Vor jeder aktualisierung findet ein Display clear statt, die Werten
> können aber auch von 500000 auf 2000 springen.

Aber nicht mit einem int16_t

Die größte Zahl, die mit einem int16_t darstellbar ist, ist +32767. Mehr 
geht nicht. Noch nicht mal wenn du unbedingt willst.

Wenn du also auf deinem Display 500000 stehen hast, dann müssen wir uns 
fragen, wo die vielen Stellen eigentlich herkommen. Aus dem int16_t 
können sie nicht stammen. Selbst dann nicht, wenn die Bytes vom Sensor 
vollkommen falsch miteinander verbunden wurden oder die Bits vollkommen 
falsch zusammengewürfelt worden wären.

Wie schon gesagt: Es wird Zeit für mehr Code.

Ich kann leider erst wieder Montag auf den gesamten Quellcode zugreifen.
Das mit den 500000 muss dann wohl unter uint32_t gewesen sein.
Ich habe mehrmals die variablendeklaration geändert.

Im Grunde kann man doch sagen dass:

1

uint32_t z_value = ( ((uint32_t) recv_data[0]) <<8 ) + recv_data[1];

die Werte korrekt formatieren sollte und ich die Ausgabe über Display 
ignorieren kann?

1

double heading = atan2( (double) y_value, (double) x_value) *180/3.1416

Sollte dann auch eigentlich die Richtung korrekt angeben?