Warum Funktioniert dieser Quelltext nicht

[Philipp (Gast)]

Hallo,
ich habe hier 3 Varianten eines Quelltextes:

Variante 1:

    unsigned char l, h;

    getValue(0x3E, &l, &h);
    unsigned short s = (h<<8) | l;
    ui->spinBoxTemp->setValue(s);

    getValue(0x42, &l, &h);
    s = (h<<8) | l;
    ui->spinBoxHumi->setValue(s);

    getValue(0x40, &l, &h);
    s = (h<<8) | l;
    ui->spinBoxPres->setValue(s);

void PTHS::getValue(char c, unsigned char *l, unsigned char *h)
{
    char Byte = 0;

    *l = 0;
    *h = 0;

    port->putChar(0x12);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(c);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(0x00);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(0x02);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);

    *l = Byte;

    port->putChar(Byte);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);

    *h = Byte;

    port->putChar(Byte);
}

Dieser Quelltext funktioniert problemlos. in den beiden folgenden 
Varianten, wo ich die beiden eingelesenen Bytes in der Methode zu einem 
Word zusammen setze, erhalte ich nicht immer die korrekten Daten. es 
kommt mir so vor, als ob sie nur in mehreren bestimmten Zahlenbereichen 
korrekt ausgegeben werden.

Variante 2:

    unsigned int s;

    getValue(0x3E, &s);
    ui->spinBoxTemp->setValue(s);

    getValue(0x42, &s);
    ui->spinBoxHumi->setValue(s);

    getValue(0x40, &s);
    ui->spinBoxPres->setValue(s);

void PTHS::getValue(char c, unsigned int *i)
{
    char Byte = 0, l = 0, h = 0;

    port->putChar(0x12);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(c);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(0x00);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(0x02);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);

    l = Byte;

    port->putChar(Byte);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);

    h = Byte;

    port->putChar(Byte);

    *i = (h<<8) | l;
}

Variante 3:

    unsigned int s;

    s = getValue(0x3E);
    ui->spinBoxTemp->setValue(s);

    s = getValue(0x42);
    ui->spinBoxHumi->setValue(s);

    s = getValue(0x40);
    ui->spinBoxPres->setValue(s);

unsigned int PTHS::getValue(char c)
{
    char Byte = 0, l = 0, h = 0;

    port->putChar(0x12);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(c);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(0x00);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    port->putChar(0x02);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);

    l = Byte;

    port->putChar(Byte);
    while(port->bytesAvailable() == 1);
    port->getChar(&Byte);

    h = Byte;

    port->putChar(Byte);

    return (h<<8) | l;
}

ich verwende den GCC 4.7.3 und bekomme so langsam das gefühl, dass der 
etwas verbuggt ist. Kann mir das Phänomen nähmlich absolut nicht 
erklären.

[mar IO (Gast)]

char Byte = 0, l = 0, h = 0;
...
return (h<<8) | l;

Bekommst Du vllt. immer als Ergebnis nur 'l'?
Was passiert mit 'h', das ein Byte groß ist und um 8 Stellen, ein Byte, 
verschoben wird?

[Philipp (Gast)]

>Bekommst Du vllt. immer als Ergebnis nur 'l'?

nein, zurzeit ist der erste messwert bei 226. erhalten tu ich 0.
der zweite liegt bei 553, welchen ich auch erhalte.
der dritte ist bei 10029, welchen ich auch erhalte.
beim zweiten messwert kann ich sagen, das er bei ca. 640 nich mehr 
korrekt ausgegeben wird, bei 770 dann aber wider schon.
der erste messwert wird meistens erst ab 256 korrekt ausgegeben.

>Was passiert mit 'h', das ein Byte groß ist und um 8 Stellen, ein Byte,
>verschoben wird?

Okay, habs mal so geändert, bringt im Programm aber keine Änderung.

return ((int)h<<8) | (int)l;

[mar IO (Gast)]

Okay, dann stimmt wohl meine Vermutung mit dem char-Shiften nicht. 
Schade eigentlich...

[Karl H. (kbuchegg)]

Philipp schrieb:

> [c]
> void PTHS::getValue(char c, unsigned char *l, unsigned char *h)
> {
>     char Byte = 0;
>
>     *l = 0;
>     *h = 0;
>
>     port->putChar(0x12);
>     while(port->bytesAvailable() == 1);
>     port->getChar(&Byte);

Aha.
Solange also am Port 1 Byte verfügbar ist, machst du nichts und 
wiederholst die Schleife wieder und immer wieder. Sondern erst dann, 
wenn nicht 1 Byte verfügbar ist, gehts aus der Schleife raus. Zum 
Beispiel auch dann, wenn gar kein Byte verfügbar ist (denn 0 verfügbare 
Bytes sind ja nicht 1 verfügbares Byte). Dieses nicht verfügbare Byte 
liest du dann aus.

Hmm. Was könnte wohl an dieser Logik nicht stimmen?

> ich verwende den GCC 4.7.3 und bekomme so langsam das gefühl,
> dass der etwas verbuggt ist.

Das der noch Bugs enthält ist sogar sehr wahrscheinlich. Allerdings sind 
das keine Bugs die du aufspüren könntest. Auf deinem Niveau kann man 
sagen, dass das Problem zu 99% vor dem Bildschirm sitzt.

[Karl H. (kbuchegg)]

>    char Byte = 0, l = 0, h = 0;


char ist eine gaaaaaanz schlechte Idee, solange du mit Bytes hantierst. 
Bytes immer als unsigned char machen!


   char             für alles was im weitesten Sinne Text ist.

   signed char      fürs rechnen mit kleinen Integer, die ein
                    Vorzeichen brauchen

   unsigned char    fürs rechnen mit kleinen Integern, die KEIN
                    Vorzeichen haben. Genau das ist das, was man
                    gemeinhin als 'Byte' bezeichnet.


Orientier dich bei der Wahl der Datentypen an dieser 'Tabelle' und du 
hast weniger Probleme. Insbesondere überlässt man dem Compiler niemals 
die Wahl, ob er einen char als 'signed' oder 'unsigned' auffassen will. 
Denn was bei Textverarbeitung noch keine Rolle spielt, kann sich beim 
rechnen auswirken!
Daher ist man an diesen Stellen immer explizit und überlässt sein 
Schicksal nicht dem Compilerbauer, wie er char implementiert hat.

Aber bring erst mal dein Empfangsfunktion in Ordnung.

[Philipp (Gast)]

@Karl Heinz Buchegger
Oh ha!! Ich saß heute wohl doch ein wenig zu lange davor.
Hab ich natürlich gleich geändert, auch wenn das seltsamerweise gar 
keine probleme verursacht hat.
Um das eigentlich Problem zu lösen, hab ich l und h jetzt als unsigned 
char definiert und nun läuft alles, wie es soll.