if( message>>16 == 0xF084 ) vergleichen ohne verändern?

Schalt mal alle Warnungen an (-Wall -Wextra), dann wird dir der
Compiler sagen, dass er im ersten Fall den Code innerhalb der
inneren if-Abfragen gar nicht erreichen kann.

Wenn Message nämlich 0x9FA0XXXX ist (also die oberen 16 Bit sind
0x9FA0), dann kann sie folglich nicht gleichzeitig bspw.
0x0000B748 sein.

wie ist den message deklariert?

Wird message vielleicht in einem Interrupt verändert?

Scherzkeks. Du hast q1 und q2 als 16 Bit Werte definiert. Damit wirfst 
du alle anderen Bits weg.

D.h. deine beiden letzten IF Abfragen sollten eigentlich auf

      if(q2==0x9FA0B748) puts("Mute\r\n");

      if(q2==0x9FA08778) puts("Power\r\n");

lauten, da du einen (vermutlich) 32 Bit Wert vergleichen willst und 
deine erste IF Abfrage sagt aus, dass die oberen 16 Bit dabei den Wert 
0x9FA0 haben sollten.

/EDIT: Zu langsam, Jörg Wunsch hat schon alles geschrieben...

Du guckst einfach immer noch auf die falsche Stelle.  Dein
“message >> 16” funktioniert prächtig.  Es ist der Rest, der nicht
funktioniert.

Nimm doch mal die Tomaten von den Augen. ;-)

Du musst in den „inneren“ if-Abfragen schreiben

1

  if ((message & 0xffff) == 0xB748) { ... }

oder, wie Thomas in Beitrag "Re: if( message>>16 == 0xF084 ) vergleichen ohne verändern?"
schreibt, den Vergleich sofort als 32-Bit-Zahl aufschreiben und es dem
Compiler überlassen, das ggf. bytweise zu optimieren.

Wobei ich bei dem Code in meinem Beitrag natürlich "message" anstatt 
"q2" in den IF Abfragen hätte schreiben müssen. Vllt. führt dies auch zu 
Verständnisschwierigkeiten.

Aber trotzdem hier mal der Code wie ihn Danny eigentlich wohl will:

1

  if ( message >> 16 == 0x9FA0 )

2

  {

3

    uint16_t lLowWord = message & 0xffff;

4

5

    if ( 0xB748 == lLowWord ) 

6

      puts("Mute\r\n");

7

8

    else if ( 0x8778 == lLowWord ) 

9

      puts("Power\r\n");

10

11

  }

(Das vertauschen der Vergleichswerte hat keinen Einfluß bei den letzten 
beiden IF Abfragen, aber den netten Nebeneffekt eines Compiler Errors, 
wenn man mal ein = vergißt)

Thomas K. schrieb:
> Das vertauschen der Vergleichswerte hat keinen Einfluß bei den letzten
> beiden IF Abfragen, aber den netten Nebeneffekt eines Compiler Errors,
> wenn man mal ein = vergißt

Dafür finde ich es scheußlich zu lesen, da es unseren gewohnten
Gedankenfluss stört.  Das fehlende Gleichheitszeichen warnen die
Compiler wiederum seit einigen Jahren an, sofern man sie lässt.

Kann ich mir vorstellen - ich für meinen Teil ist es egal vom Lesen. Ich 
erfasse den Termin als Ganzes. Und Warnungen werden oftmals ignoriert 
oder in den Projekteinstellungen/Makefiles ausgeschaltet und sind somit 
nicht zuverlässig. Bei Embarcadero muss man solche Zuweisungen explizit 
klammern um die Warnung zu beseitigen. Alles persönliche Vorlieben halt.

wie Jörg und ich schon geschrieben hatten: ausmaskieren

if ( message & 0xffff == 0x1234 )

oder wirklich casten, was in diesem Falle aber eigentlich verschleiert 
was du eigentlich willst. Im Normalfall würde man einen temporary 
anlegen, dort würde es dann zu einer Warnung kommen, weil Informationen 
verloren gehen:

if ( uint16_t(message) == 0x1234 )

Oder wirklich hart casten:

if ( (uint16_t)message == 0x1234 )

Aber wie gesagt, ist nicht unbedingt eine "nette" Art in Sachen 
Lesbarkeit, etc. Es wird einem Leser nicht sofort bewusst, dass dort 
Informationen verloren gehen bzw. Daten verändert werden.

DirkB schrieb:

> Nimm das
>

1

if ( message & 0xffff == 0x1234 )

Lieber nicht. ;-)

Nimm lieber das:

1

if ((message & 0xffff) == 0x1234)

Der ==-Operator bindet nämlich stärker als das bitweise Und (&).

Ach verdammt, wieder was vergessen. Ich klammere bitweise Operatoren 
(ausgenommen natürlich ~) immer...