Moin Zusammen,

Ich habe mir das IRMP Projekt angesehen und will damit ein bischen 
spielen.
Pollin Board mit ATMEGA32 als Testumgebung.

Irgendwie klappte das nicht mit meinem C Programmieren....

Am PortD hängen LED´s. PD2 PD4 und PD6
Ich will eigentlich nur, dass wenn ich Taste 1,2 oder 3 auf der 
Fernbedienung drücke, dass die jeweils eine LED angeht.

Ich schicke mir die Daten ebenfalls auf der RS232 raus...
Witziger weise Klappt das...

Ich habe es mit IF Anweisung und der Switch Anweisung probiert....
Irgendwie will ich doch lieber Assembler machen ;-)

Warum will dat nicht. Hier der Code:

 if (irmp_get_data (&irmp_data))
        {


      switch (irmp_data.command)
      {
        case 0x0001: PORTD = 0b00000100;break;
        case 0x0002: PORTD = 0b00010000;break;
        case 0x0003: PORTD = 0b01000000;break;

      }
      Sende(irmp_data.protocol);
      Sende(irmp_data.address);
      Sende(irmp_data.command);

           // ir signal decoded, do something here...
            // irmp_data.protocol is the protocol, see irmp.h
            // irmp_data.address is the address/manufacturer code of ir 
sender
            // irmp_data.command is the command code
            // irmp_protocol_names[irmp_data.protocol] is the protocol 
name (if enabled, see irmpconfig.h)
        }

Achso.... ja die LED´s gehen auch an...

Kurt Späinghaus schrieb:
> Am PortD hängen LED´s. PD2 PD4 und PD6
> Ich will eigentlich nur, dass wenn ich Taste 1,2 oder 3 auf der
> Fernbedienung drücke, dass die jeweils eine LED angeht.
>
> Ich schicke mir die Daten ebenfalls auf der RS232 raus...
> Witziger weise Klappt das...

> Achso.... ja die LED´s gehen auch an...

Und was klappt dann nicht?

Rolf Magnus schrieb:

> Und was klappt dann nicht?

Oh... habe ich mich aber blöde ausgedrückt.

Also die LED´s Funktionieren an sich schon. Wenn ich sie vor oder nach 
dem Switch Block im Quelltext ansteuere gehen sie.

Was nicht geht ist die eigentliche Verarbeitung der Switch Anweisung...

Das verstehe ich nicht...

Vorallem weil ich mir die Daten ja auf der RS232 rausschicke und ich im 
Terminal Programm sehe...

Habe gedacht es liegt am Datentyp... weil:

irmp_data.command ist uInt16_t

ich es mal mit : CASE (uInt16_t) 0x0001:.... probiert
klappt auch net.

Ratlos

Komisch:

switch ((unsigned char) irmp_data.command)
{
case 1: PORTD = 0b00000100;break;
case 2: PORTD = 0b00010000;break;
case 3: PORTD = 0b01000000;break;

}

So klappt es..... Aber wieso, vorher nicht ?

Kurt Späinghaus schrieb:
> Komisch:
>
> switch ((unsigned char) irmp_data.command)
> {
> case 1: PORTD = 0b00000100;break;
> case 2: PORTD = 0b00010000;break;
> case 3: PORTD = 0b01000000;break;
>
> }
>
> So klappt es..... Aber wieso, vorher nicht ?

Höchst wahrscheinlich, weil in irmp_data.command nicht das drinnen 
steht, was du denkst das drinnen stehen sollte. Durch das Niedercasten 
auf einen unsigned char verwirfst du das komplette High-Bytem und wenn 
das nicht 0 war, dann hast du genau den Effekt, den du gesehen hast.

Sende(irmp_data.command);

welchen Datentyp will die Funktion 'Senden'? Wenn die ebenfalls einen 
unsigned cha nimmt, dann hast du auch hier den uint16_t zu einem 
unsigned char gestrippt und siehst daher auch hier nicht, was im 
High-Byte des uint16_t war.

Kurt Späinghaus schrieb:
> switch ((unsigned char) irmp_data.command)
> [...]
> So klappt es..... Aber wieso, vorher nicht ?

Wie Karl Heinz schon sagte, Du testest hier nur das untere Byte von 
irmp_data.command auf 1, 2 oder 3. Tatsächlich scheint im oberen Byte 
auch noch was zu stecken.

Um beide Bytes von irmp_data.command zu "sehen", mache folgendes:

   Sende(irmp_data.command >> 8);    // oberes Byte senden
   Sende(irmp_data.command);         // unteres Byte senden

Das solltest Du für irmp_data.address ebenso machen.

Dann ist das Kommando = 256 x OberesByte + UnteresByte
Diesen errechneten Wert setzt Du dann in die 3 case-Zeilen und löschst 
den cast "(unsigned char)" aus dem switch wieder raus (wichtig!).


Gruß,

Frank