C18 PIC18F2550 UnSigned ist SIGNED, wieso?

[Andreas B. (biosniper)]

Egal was ich mache (2 Versionen, sie unten, eine ist auskommentiert), 
der Debugger macht alles als SIGNED, obwohl es als UNsigned deklariert 
wurde.
Wenn ich im Watchfenster die Variable rechtsklicke und auf Properties 
gehe, dann ist auch der Haken bei signed vorhanden.

Der Debugger erkennt sonst auch keine Fehler. Ich hab keinen Plan mehr 
woran das liegen könnte.

//-------------------------------------------

typedef union __varSINUS {
 unsigned short long LH;
 struct {
   unsigned char L1;
   unsigned char H1H2;
   unsigned char L2;
 };
} _varSINUS;

//-------------------------------------------

#pragma udata buffer_big //Sonder-RAM.

_varSINUS varSINUS[168]; //<= 1. Version, mit obigem typedef.

/* 2. Version, ohne typedef:
static union _varSINUS {
 unsigned short long LH;
   struct {
     unsigned char L1;
     unsigned char H1H2;
     unsigned char L2;
   };
} varSINUS[168];
*/

#pragma udata

[Εrnst B. (ernst)]

Läuft das Programm sonst richtig? d.H. Rechnet der PIC anschliessend mit 
unsigned?
Wenn ja würde ich auf ein mehr oder weniger unbedeutendes 
Darstellungsproblem im Debugger oder unzureichende Debuginformationen im 
Binary tippen.

[Andreas B. (biosniper)]

Wenn ich in eine der Variablen ein 0x0F packe und 4x nach links shifte 
steht da -16 drin. Es müsste doch aber 0xF0 drin stehen.

var = 0x0F
var = var << 4
var = -16

Jedenfalls steht das dann im Watch-Fenster so.

[(prx) A. K. (prx)]

Das sieht eher nach einer etwas lässigen Interpretation des Datentyps 
durch den Debugger aus, als nach einem wirklichen Problem. 
Möglicherweise kann man im Debugger die Darstellung einstellen.

[Andreas B. (biosniper)]

Da kann man unter Properties den Haken bei "signed" wegmachen.

Soll das die Lösung sein ? Kommt mir etwas merkwürdig vor. Bei allen 
anderen Variablen machte er das bisher immer richtig.

[Andreas B. (biosniper)]

Also, wenn ich im Watch-Fenster, bei der Variablen den Haken bei 
"signed" wegmache, dann steht da nicht mehr -16 drin, sondern 240. Er 
rechnet also immer noch mit signed, nur interpretiert er nun das 
Vorzeichen als gesetztes Bit, also, als 128.

[Εrnst B. (ernst)]

Andreas Bayer schrieb:
> Wenn ich in eine der Variablen ein 0x0F packe und 4x nach links shifte
> steht da -16 drin. Es müsste doch aber 0xF0 drin stehen.

Erm. dir ist schon klar, dass das korrekt ist? -16 ist nunmal dasselbe 
0xF0 (meint: Wird durch dasselbe Bitmuster gespeichert).

Dem Byte selber ist es egal, ob es signed, unsigned, oder meinetwegen 
zwei Dezimalstellen einer BCD-Darstellung enthält.
Das ist Interpretationssache des Codes aussenrum oder eben des 
Debuggers.

[Andreas B. (biosniper)]

Also, dann habe ich an dieser Stelle keinen Fehler ?

Kommt mir aber etwas merkwürdig vor.

[Andreas B. (biosniper)]

Εrnst B✶ schrieb:
> Erm. dir ist schon klar, dass das korrekt ist? -16 ist nunmal dasselbe
> 0xF0 (meint: Wird durch dasselbe Bitmuster gespeichert).

Ich habe es mir mal als Binary anzeigen lassen im Watch, dann steht da
 "11110000". Scheint wohl alles korrekt zu sein, wie Du schon 
geschrieben hast.

[Michael (Gast)]

if(var < 0)
   writeUART("Compiler hat probleme mit den Datentypen");
else
   writeUART("Alles iO, Debugger hat Probleme mit dem Datentyp.");

alternativ kann man natürlich auch ein LED setzen. Oder noch lange 
rätselraten im Forum betreiben.

[Rufus Τ. F. (rufus)]

Michael schrieb:
> if(var < 0)
>    writeUART("Compiler hat probleme mit den Datentypen");

Sicher? Welchen Datentyp hat denn die Konstante 0?

[Andreas B. (biosniper)]

Habs nach Deinem Tipp getestet, und die if-Anweisung wird nicht 
ausgeführt, also, alles o.k.:

unsigned char dum;

dum = 0x0F;
varSINUS[0].H1H2 = dum << 4;
if (varSINUS[0].H1H2 < 0) {
 Nop();
 Nop();
}

Wenn ich mit der Maus über varSINUS gehe, dann steht im ToolTip auch 
240. Nur im Watchfenster steht -16.

Dan habe ich mir ja umsonst Sorgen gemacht. Hatte so einen Anzeigefehler 
noch nie.