Unsigned konvertierung 1..15Bit auf Short (16Bit)

[Tobias M. (toby-sx)]

Hallo,

ich steh seit ein paar Stunden auf dem Schlauch und komme nicht weiter.
Ich habe aus einer CAN-Nachricht ein Datum isoliert, das laut 
spezifikation als signed zu interpretieren ist. Es kann zwischen 1 und 
15 Bit lang sein und wird in einen signed short Datentyp rein 
geschrieben.

Das führt dazu, dass die führenden Stellen alle auf Null sind. Beispiel 
ich kopiere ein 8Bit 0xFF in den Short rein. Dann übergebe ich den 
Shortwert einer anderen Funktion (call by value auf signed variable), 
die mir das Ding richtig formatiert ausgeben soll. Leider ergibt sich 
nicht wie erhofft eine -1 sondern die 255.

Wie kann ich denn möglichst Ressourcenschonend meine signed Werte weiter 
verarbeiten? Ich komm einfach nicht auf die passende 
bitwise-Operationen...

Gruß und vielen Dank für Hilfe!
Toby

Anbei ein Auszug auf dem Code:


signed short s_val;

// hier stehen praktisch 1..15 bit als //signed kombination drinnen, 
aber die führende ziffer ist auf jeden fall //Null. fuer 16 bit 
nachrichten funktioniert der code schon :-)


dann der Aufruf: s_itoa(s_val,mob.signal.scaling,&s_erg);


void s_itoa(signed long l,signed int scaling, char *s)
{
  // hier will ich mir dem signed wert l weiterrechnen
}

[Oliver (Gast)]

Wie die Daten zu interpretieren sind, und woran man das führende 
Vorzeichen-bit erkennt, kann dir nur die Spezifikation des Datenformats 
sagen. Irgendwie musst du ja erkennen können, wie lang der übertragene 
Wert sein soll, und welches das Vorzeichenbit ist. Z.B. 0x03 kann +3 
oder -1 darstellen, je nachdem, ob man das als 3- oder 2-bit-signed 
interpretiert. Wenn du weisst, welches das Vorzeichenbit sein soll, 
kannst du einfach darauf testen, und entsprechend umrechnen.

Oliver
P.S. Der Wertebereich des 1-bit signed ist auch arg begrenzt.

[Karl H. (kbuchegg)]

Tobias Mueller wrote:
> Hallo,
>
> ich steh seit ein paar Stunden auf dem Schlauch und komme nicht weiter.
> Ich habe aus einer CAN-Nachricht ein Datum isoliert, das laut
> spezifikation als signed zu interpretieren ist. Es kann zwischen 1 und
> 15 Bit lang sein und wird in einen signed short Datentyp rein
> geschrieben.

Das kommt mir etwas komisch vor.
Bist du sicher, dass da eine variable Bitlänge benutzt wird.
Ist eher unüblich.

>
> Das führt dazu, dass die führenden Stellen alle auf Null sind. Beispiel
> ich kopiere ein 8Bit 0xFF in den Short rein. Dann übergebe ich den
> Shortwert einer anderen Funktion (call by value auf signed variable),
> die mir das Ding richtig formatiert ausgeben soll. Leider ergibt sich
> nicht wie erhofft eine -1 sondern die 255.

Logisch.
Ein short 0xFF ist nun mal 255. -1 wäre 0xFFFF

Irgendwie musst du ja aus dem Protokoll entnommen haben
mit welcher Bitlänge (1 bis 15) du es zu tun hast. Dann
nimmst du das am weiteste links stehende Bit und ergänzt
alle Bits bis zu Bit 15 mit diesem Wert.
Bsp. Du hast 8 Bit empfangen

    1111 1111

um daraus einen short zu machen, musst du auf 16 Bit ergänzen.
Jetzt betrachtest du von der 8 Bit Zahl das linkste Bit. Es
ist eine 1. Also müssen die zu ergänzenden Bits 9 bis 15
ebenfalls 1 sein. Die Erweiterung von 1111 1111 zu short
ergibt also
   1111 1111 1111 1111
oder 0xFFFF oder eben -1

[Tobias M. (toby-sx)]

Hallo!

vielen Dank für die Antworten bisher! Ich bin mir sicher dass ich diese 
variable bitzahl brauche. Das wird in der Praxis (automotive) ganz 
üblich angewendet! Ich habe hier unzählige Beispiele für Bitlängen 
1,2,3,4,5,6,7,8,910,12,15 & 16 Bit.

Allerdings ist mir gerade aufgefallen, dass signed Signale meist mit 8 
oder 16 Bit auftreten.

Ich werde daher Zweikomplementdarstellung für die Bytes ergänzen und die 
anderen "ungeraden" Signale nur im unsigned Bereich zulassen.

Ich hab mit dem Gerät auch schon über ein halbes Jahr gearbeitet, er 
gestern ist der Fehler aufgetreten als ich versucht habe eine 6-Bit Zahl 
als signed zu definieren.

Na gut! Vielen Dank soweit! Die kritische Rückfrage hat eigentlich den 
Job erledigt!

Gruß,
Toby