IRMP und NEC-Protokoll

ugly_micro schrieb:
> address: 0xFF00

Das sieht richtig aus. Wenn man 0xFF invertiert, ist es doch 0x00.
Es gehört zu den IRMP Konventionen, das Address und Command als uint16_t 
abgelegt werden, da die Datenstruktur ja auch für andere Protokolle 
passen soll.

Auzug aus

https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC

1

Daten NEC       8 Adress-Bits +

2

                8 invertierte Adress-Bits +

3

                8 Kommando-Bits +

4

                8 invertierte Kommando-Bits

Um einen Standard-NEC-Frame eindeutig festzulegen, braucht man lediglich 
2 Bytes, nämlich 8 Adress-Bits + 8 Kommando-Bits. Der Rest ist 
redundanterweise einfach invertiert, also Byte 2 und Byte 4.

Wenn ich aber im Artikel eine Zeile weiterlese, finde ich:

1

Daten ext. NEC  16 Adress-Bits

2

                8 Kommando-Bits +

3

                8 invertierte Kommando-Bits

Die Lösung dieses vermeintlichen Widerspruches ist einfach:

Irgendwann gingen den Herstellern die 256 maximal möglichen Adressen 
aus. Also hat man das Protokoll erweitert ("Extended NEC") und auf die 
Forderung, dass das zweite Byte im Frame die negierte 8-Bit-Adresse ist, 
verzichtet.

Damit hat man nun bis zu 65536 Adressen. In der Regel ist es aber 
trotzdem so, dass meist das zweite Byte das negierte erste Byte ist. 
Aber es ist nicht zwingend. Und damit sind nun Geräteadressen von 
0x000 bis 0xFFFF möglich.

Aus diesem Grund gibt IRMP eine vollständige 16 Bit-Adresse zurück und 
einen 8-Bit Kommando-Code. Letzterer geht also lediglich nur von 0x00 
bis 0xFF.

Mit 2 Byte Adressen und 1 Byte Kommando-Code sind nun sowohl NEC als 
auch Extended NEC eindeutig spezifiziert.

EDIT:

Okay, ich hätte im IRMP daraus auch zwei Protokolle machen können, wie 
z.B. NEC und EXT_NEC. Da die technischen Merkmale sich aber nur in 
diesem einen Punkt unterscheiden, behandle ich beide als "Extended NEC". 
Damit der Frame von der Identifikation her eindeutig ist und auch von 
IRSND eindeutig reproduziert werden kann, war die Erweiterung auf 16 Bit 
für die Geräteadresse die logische Konsequenz - so wie es auch die 
Hersteller gemacht haben.

IRMP behandelt also alle NEC-Frames als Extended-NEC-Protokoll. Denn das 
Extended-NEC-Protokoll ist einfach eine Obermenge von Standard-NEC.

Nachlesen kannst Du das im Detail auch auf:

https://www.sbprojects.net/knowledge/ir/nec.php

ugly_micro schrieb:
> Das heißt aber, wenn ich mit IRSND 0xF8 verschicke, bekomme ich 0x8F70
> zurück, oder?

Du meinst jetzt als Adresse? Nein.

Wenn Du 0xF8 als Geräteadresse im IRSND verwendest, dann ist das die 
16-Bit-Adresse 0x00F8. Und Du wirst auch exakt 0x00F8 im IRMP 
zurückbekommen.

Wenn Du jedoch als Kommando 0xF8 verschickst, dann ist Byte Nr. 3 = 0xF8 
und Byte nur 4 = 0x70. IRMP empfängt diese, prüft, ob das Byte Nr. 3 
gleich dem negierten Byte Nr. 4 ist und gibt dann als Kommando wieder 
0xF8 zurück.

Ergo: Du bekommst transparent genau das raus, was Du vorne reingesteckt 
hast. Alles andere wäre auch Unsinn. Also kümmere Dich nicht darum, wie 
der IR-Frame intern aussieht, sondern merke Dir einfach:

"Bei NEC ist die Geräteadresse 16-Bit breit, das Kommando nur 8 Bit. Ich 
bekomme vom IRMP exakt das zurück, was ich bei IRSND gesendet habe."