Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Armin J. (arminj)


Lesenswert?

Hi Frank,

bei mir tuts 17000 auch noch :-)
Wann sollen wir unsere Sourcen mal zusammenwerfen?
Ich hab jetzt die ESP Versionen fertig.

von Armin J. (arminj)


Lesenswert?

Boris S. schrieb:

> Hast du eine Idee ?

Ja klar :-)
Nimm die aktuellen Arduino Library Sourcen von 
https://github.com/ukw100/IRMP
Ich hab sie gerade fertig getestet.
Wenn Du auch damit klar kommst, sag bescheid, dann kann ich ja ein neues 
Arduino Release bauen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:
> bei mir tuts 17000 auch noch :-)

Es geht auch noch 18611 ;-)

> Wann sollen wir unsere Sourcen mal zusammenwerfen?
> Ich hab jetzt die ESP Versionen fertig.

Gute Frage. Kannst Du Deine Änderungen bei github reinstellen? Ich würde 
die dann auschecken, meine Änderungen einpflegen und diese dann wieder 
committen.

Oder hast Du einen anderen Vorschlag?

von Armin J. (arminj)


Lesenswert?

Frank M. schrieb:

> Es geht auch noch 18611 ;-)

na ja 18000 knallte bei mir im Compiler man hat ja den Faktor 1,1 bei 
PENTAX oder 1,2 bei GREE


> Gute Frage. Kannst Du Deine Änderungen bei github reinstellen? Ich würde
> die dann auschecken, meine Änderungen einpflegen und diese dann wieder
> committen.
>
> Oder hast Du einen anderen Vorschlag?

Sind soeben eingecheckt.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:
> na ja 18000 knallte bei mir im Compiler man hat ja den Faktor 1,1 bei
> PENTAX oder 1,2 bei GREE

Ja, bei 10% knallt es früher, stimmt. Ich hatte das mit 5% Toleranz 
durchgerechnet.

> Sind soeben eingecheckt.

Danke, schaue ich mir in den nächsten Tagen an.

von E. K. (eku)


Lesenswert?

Frank M. schrieb:
> Ich schlage folgendes vor:
>
> Ich führe ein neues Protokoll "ONKYO" ein, auf welches gewechselt wird,
> wenn die Regel verletzt wird. Dann bekommt man nicht nur 2 Bytes für die
> Adresse (Extended NEC), sondern auch 2 Byte (statt nur eins) für das
> Kommando.

Man wird mit ONKYO dann alle Codes per IRSEND senden können oder muss 
man für einige auf NEC zurückgreifen?

> Interessant ist bei dieser FB auch, dass nicht nur die BLUETOOTH-Taste
> eine abweichende Adresse benutzt, sondern auch die Taste BD/DVD. Kann es
> sein, dass man diese FB für verschiedene Onkyo-Geräte verwenden kann?

Das kann gut sein. Ich habe aber nur ein Gerät.

Beim Scannen aller Tasten ist mir aufgefallen, dass die Codes in das 
Schema Device XXD2 Command 00YY passen, also das MSB des Gerätes sich 
auch ändert.

: Bearbeitet durch User
von Boris S. (cool-man)


Lesenswert?

Armin J. schrieb:

> Ja klar :-)
> Nimm die aktuellen Arduino Library Sourcen von
> https://github.com/ukw100/IRMP
> Ich hab sie gerade fertig getestet.
> Wenn Du auch damit klar kommst, sag bescheid, dann kann ich ja ein neues
> Arduino Release bauen.

Hab die IRMP-Master.zip frisch heruntergeladen und eingebunden. Und 
SimpleReceiver auf Wemos D1 mini geladen. IR an D5 läuft ! SUPER danke 
für die Hilfe.

Im irmpconfigMain15.h hab ich 4x weiter Protokolle enabled, u.a. ACP24 
mit :
#define IRMP_SUPPORT_ACP24_PROTOCOL             1       // ACP24

Ausgabe über Seriellen Monitor :
z.B. TV Samsung (Taste1) wird erkannt : P=SAMSG32  A=0x707 C=0xFB04

Aber die KlimaFB wird nicht so gut erkannt, einmal gedrückt :
P=SIEMENS  A=0x2AA C=0x15A
P=SIEMENS  A=0x2AA C=0x15A R
P=SIEMENS  A=0x2AA C=0x15A R
P=SIEMENS  A=0x2AA C=0x15A R
Code bleibt gleich egal welche Taste.

Die Klimaanlage die ich steuern möchte ist eine Trotec PAC 3550 Pro die 
baugleich zu Stiebel Eltron ACP 35 ist.  Gut ist nicht ACP25 - dachte 
aber das wäre das gleiche Protokoll. Problem ist das sich der Code der 
origFB kaum lernen läßt, nur mit einer Pronto aber passt nicht so 
richtig mit der Beschreibung der ACP25.

Hab mal eine universal KlimaFB genommen und versucht die Trotec zu 
steuern und hab wenigstens per Suchlauf einen Code gefunden der die 
ein/aus schaltet (toggel) : P=NEC  A=0xE710 C=0x0   ein ganz anderer 
Code alles komisch...

Wenigstens läuft das Prog mit Wemos.  Allerdings nur der SimpleReceiver, 
die anderen werden kompliert und hochgeladen aber die Ausgabe ist nicht 
so wie am SimpleReceiver.
vielen Dank und Grüsse

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

E. K. schrieb:
> Man wird mit ONKYO dann alle Codes per IRSEND senden können oder muss
> man für einige auf NEC zurückgreifen?

Nein, Du musst dann für die NEC-Tasten auch NEC angeben, für die 
ONKYO-Taste dann ONKYO.

Du kannst natürlich NEC in ONKYO umrechnen, indem Du das negiert Byte 
beim Kommando zusätzlich angibst, aber das wäre zusätzlicher Aufwand 
ohne weiteren Nutzen.

Hattest Du mitbekommen, dass IRMP mit ONKYO bereits verfügbar ist? Den 
Empfang kannst Du also schon mal ausprobieren. ONKYO muss auch nicht 
zusätzlich aktiviert werden.

von E. K. (eku)


Lesenswert?

Frank M. schrieb:
> Hattest Du mitbekommen, dass IRMP mit ONKYO bereits verfügbar ist? Den
> Empfang kannst Du also schon mal ausprobieren. ONKYO muss auch nicht
> zusätzlich aktiviert werden.

Rev 189 "added ONKYO protocol"

Da ist aber vieles drinnen, was den Blick auf Onkyo versperrt. Trotzdem 
Danke.

von Armin J. (arminj)


Lesenswert?

Boris S. schrieb:
> Wenigstens läuft das Prog mit Wemos.  Allerdings nur der SimpleReceiver,
> die anderen werden kompliert und hochgeladen aber die Ausgabe ist nicht
> so wie am SimpleReceiver.

Hi Boris,
welches Beispiel hat denn welchen unerwarteten Output, kannst Du das 
präzisieren, dann kann ich mal forschen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

IRSND 3.1.5 ist online.

Änderungen:

* Neues Protokoll: ONKYO

von Boris S. (cool-man)


Lesenswert?

Armin J. schrieb:
> Hi Boris,
> welches Beispiel hat denn welchen unerwarteten Output, kannst Du das
> präzisieren, dann kann ich mal forschen.

Speziell das hier, hier hätte ich den APC24 Klima code erwartet.
 KlimaFB einmal gedrückt :
P=SIEMENS A=0x2AA C=0x15A
P=SIEMENS A=0x2AA C=0x15A R
P=SIEMENS A=0x2AA C=0x15A R
P=SIEMENS A=0x2AA C=0x15A R
Code bleibt gleich egal welche Taste.
Wenn alles gleich bleibt egal welch Taste der KlimaFB ich drücke, dann 
meine ich der code wird nicht richtig interpretiert.
Der output ist vom SimpleReceiver prog das Protokoll ACP24 hab ich 
aktiviert.

Grüße

von Armin J. (arminj)


Lesenswert?

Dann nimm mal den #include <irmpNone.h> und aktiviere danach nur dein 
Protokoll.
Oder nimm das neue Beispiel OneProtocol, dann musst Du aber auch die 
anderen Files abrufen, da wurde etwas umgebaut :-)

Good Luck

von Boris S. (cool-man)


Lesenswert?

Armin J. schrieb:
> Dann nimm mal den #include <irmpNone.h> und aktiviere danach nur
> dein
> Protokoll.
> Oder nimm das neue Beispiel OneProtocol, dann musst Du aber auch die
> anderen Files abrufen, da wurde etwas umgebaut :-)
>
> Good Luck

Hallo,
habs mit nur einem und mit allen Protokollen probiert, es kommt nur ein 
Output mit dem Siemens Protokoll, denke aber das ist immernoch eine 
falsche Interpretation, da es keinen Unterschied gibt egal welche Taste 
ich drücke.

P=SIEMENS A=0x2AA C=0x15A
P=SIEMENS A=0x2AA C=0x15A R
P=SIEMENS A=0x2AA C=0x15A R
P=SIEMENS A=0x2AA C=0x15A R

Mit der Pronto aufgezeichnet gibts Unterschiede :
In dem Code Telegramm sind alle Angaben enthalten ähnlich ACP24, also 
Temperatur, Modus (Kühlen, Enfeuchten, Auto..) aber wie genau?!

Das wäre Ein, 18°C Kühlen:
0000 006c 004a 0000 01ca 00c4 0015 0013 0018 004a 0015 0013 0018 004a 
0015 0013 0018 004a 0015 0013 0018 004a 0015 0013 0015 0013 0018 004a 
0018 004a 0015 0013 0015 0013 0018 004a 0015 0013 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0015 0013 0018 004a 0018 004a 0018 004a 
0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0015 0013 0018 004a 0015 0013 0015 0013 
0015 0013 0015 0013 0018 004a 0018 004a 0015 0013 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0018 004a 
0015 0013 0018 004a 0018 004a 0018 004a 0018 004a 0015 00c4

Das wäre Aus :
0000 006c 004a 0000 01ca 00c4 0015 0013 0018 004a 0015 0013 0018 004a 
0015 0013 0018 004a 0015 0013 0018 004a 0015 0013 0018 004a 0018 004a 
0015 0013 0015 0013 0015 0013 0018 004a 0018 004a 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0018 004a 0018 004a 0015 0013 0018 004a 
0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0015 0013 0018 004a 0015 0013 0015 0013 
0015 0013 0015 0013 0015 0013 0018 004a 0015 0013 0015 0013 0015 0013 
0018 004a 0015 0013 0015 0013 0015 0013 0015 0013 0018 004a 0018 004a 
0015 0013 0018 004a 0018 004a 0015 0013 0018 004a 0015 00c4

Aber leider verstehe ich die Logik nicht.

Grüsse

: Bearbeitet durch User
von Armin J. (arminj)


Lesenswert?

Hallo Boris,
da muss ich passen, da kann nur Frank helfen.
@Frank: Übernimmst Du?

von E. K. (eku)


Angehängte Dateien:

Lesenswert?

Hallo Frank,

ich schaffe es nicht, mit IRMP eine Thomson RC3000E02 einzulesen. Sowohl 
Thomson als RC80 und RC80EXT sind aktiviert. Ab und zu wird Ruwido 
ausgegeben, obwohl das Protokoll in IRMP nicht aktiviert ist. Ansonsten 
rein garnichts.

Scan mit 15kHz anbei. Danke vorab.

von E. K. (eku)


Lesenswert?

E. K. schrieb:
> ich schaffe es nicht, mit IRMP eine Thomson RC3000E02 einzulesen. Sowohl
> Thomson als RC80 und RC80EXT sind aktiviert.

Hätte ich ahnen können, dass Thomson das Matsushita-Protkoll für seine 
FB benutzt? Hat sich hiermit erledigt.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi eku,

sorry, bin bisher nicht dazu gekommen, mir Deine Scans anzuschauen.

E. K. schrieb:
> Hätte ich ahnen können, dass Thomson das Matsushita-Protkoll für seine
> FB benutzt?

Tja, die Wege sind manchmal sonderbar ;-)

> Hat sich hiermit erledigt.

Freut mich. Viel Spaß weiterhin.

von Jörg R. (jrie)


Angehängte Dateien:

Lesenswert?

Der angehängte Patch für IRMP fügt STM32F30x Support (für die SPL) 
hinzu.

von Vlad T. (vlad_tepesch)


Angehängte Dateien:

Lesenswert?

Hi Frank, ich hab mit der aktuellen SVN-Version probleme, sie unter 
Windows mit dem Visual Studio zu kompilieren:

1. Es ist eine Sonderbehandlung drin, die nicht mehr nötig sein sollte 
wegen der inttypes.h. In der Sonderbehandlung werden da nicht alle typen 
definiert, die auch benutzt werden
2. Hab ich Probleme mit IRMP_PACKED_STRUCT


Ich hab einen Patch angehangenen.

Außerdem wollte ich irmp als dll benutzen können
Deswegen habe ich ein paar funktionen hinzugefügt.
Für das Interface, was ich wollte, brauchte ich aber auch die nummer des 
Startsamples, weswegen ich oben auch noch was reinfummeln musste. kannst 
ja mal gucken, ob du das einbauen willst.

außerdem dafür einen c# wrapper

Grund war, dass ich es in den USBeeSuite CustomDecoder einbauen wollte.
Keine Ahnung, ob nochjemand dieses alte ding nutzt ^^.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Jörg R. schrieb:
> Der angehängte Patch für IRMP fügt STM32F30x Support (für die SPL)
> hinzu.

Danke für den Patch, kommt ins nächste Release.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Vlad,

Vlad T. schrieb:

> 1. Es ist eine Sonderbehandlung drin, die nicht mehr nötig sein sollte
> wegen der inttypes.h. In der Sonderbehandlung werden da nicht alle typen
> definiert, die auch benutzt werden

Geht das unter Windows auch mit stdint.h? Das würde ich heute lieber 
nutzen statt inttypes.h. Damals, als ich mit IRMP begann, gab es in 
Windows weder inttypes.h noch stdint.h. Deshalb die typedefs.

> 2. Hab ich Probleme mit IRMP_PACKED_STRUCT

Habe den Patch übernommen.

> Ich hab einen Patch angehangenen.

Danke, der ist aber so unbrauchbar, da sich mittlerweile durch andere 
Patches die Zeilennummern geändert haben. Kannst Du da einen 
Context-Diff erstellen?

> Außerdem wollte ich irmp als dll benutzen können
> Deswegen habe ich ein paar funktionen hinzugefügt.

Kann ich gerne übernehmen. Was ist mit den dazugehörenden 
extern-Deklarationen für irmp.h? Hast Du da noch was?

Viele Grüße,

Frank

von Vlad T. (vlad_tepesch)


Lesenswert?

Frank M. schrieb:
> Damals, als ich mit IRMP begann, gab es in
> Windows weder inttypes.h noch stdint.h. Deshalb die typedefs.

in den neueren VS-Versionen sind die drin.
ja, die stdint.h geht auch, in dem Patch wird die ja sogar verwendet.
ich hab oben nur die Sonderbehandlung rausgeschmissen.

Frank M. schrieb:
> Danke, der ist aber so unbrauchbar, da sich mittlerweile durch andere
> Patches die Zeilennummern geändert haben. Kannst Du da einen
> Context-Diff erstellen?

Ich dachte, ich hätte extra nochmal die neueste Version aus dem SVN 
gezogen, aber kann ich machen. Das im Artikel verlinkte git wird 
übrigens nicht mehr synchronisiert.


Ich seh gerade, dass da aber auch noch was drin gelandet ist, was der 
editor von allein geändert hatte, wegen der Sonderzeichen. Die geben bei 
mir auch Warnungen, sowohl im GCC als auch MSC. Da passen irgendwie die 
ganzen Inputencodings nicht.

Frank M. schrieb:
> Kann ich gerne übernehmen. Was ist mit den dazugehörenden
> extern-Deklarationen für irmp.h? Hast Du da noch was?

Da ich die Files sowieso in c# und python einbinden wollte, die keine 
Header verstehen, haben mir die exportierten Symbole in der exe/dll 
gereicht. Man muss ja die declspec deklaration geignet setzen. Ich kann 
das sauberer einbauen, aber ich wusste nicht, ob du es überhaupt 
drinhaben willst, deswegen hab ich mir die Mühe erstmal gespart.

Hab aber schon noch weitere kleinere Änderungen. Nachdem ich jetzt doch 
endlich Sigrok/Pulseview mit meinem LogicAnalyser-Klon zum Laufen 
gebracht habe, bin ich gerade dabei die IRMP als Sigrok-Decoder da 
einzubauen.

Daher würde ich warten, bis das läuft und dann die notwendigen 
Änderungen nochmal zusammenfassen.


Ein Problem ergibt sich beim bauen der Lib mit dem gcc. dieser 
exportiert sämtliche non-static functions standardmäßig. Das heißt, dass 
auch die internen Funktionen von außen aufrufbar sind. deswegen hatte 
ich einen anderen Präfix gewählt 'IRMP_', um die Funktionen nicht zu 
verwechseln. Vielleicht auch eine komplett unabhängige Header-Datei für 
die DLL erstellen (name?)



Nebenbei:
Hättest du was dagegen Analyzer-Programm-Teil aus der irmp.c-Datei 
rauszuziehen?
Also alles nach  "main functions - for Unix/Linux + Windows only!"
Eventuell auch die internen protocol/parameter definitionen.
Ich glaub, das würde die Übersichtlichkeit und Navigierbarkeit etwas 
erhöhen.

Mein Vorschlag wäre:
irmp.h/c wie gehabt (nur ohne die erwähnten Anteile).
irmpprotocols_intern.h die parameter defines/structuren (bis ca Zeile 
3000, ohne logging)
irmp-main-PC.c enthält exklusiven PC-Code includiert irmp.c (ab zeile 
~5500)

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Vlad T. schrieb:
> ja, die stdint.h geht auch, in dem Patch wird die ja sogar verwendet.

Dann passe ich das so an.

> Ich dachte, ich hätte extra nochmal die neueste Version aus dem SVN
> gezogen, aber kann ich machen.

Sorry, das ist aber nicht die neueste Version, die ich auf meinem 
Rechner habe ;-)

> Ich seh gerade, dass da aber auch noch was drin gelandet ist, was der
> editor von allein geändert hatte, wegen der Sonderzeichen.

Ist mir auch aufgefallen, das waren ISO8859-Zeichen, Dein Editor scheint 
im UTF-8-Format zu arbeiten. Macht aber nichts, ich habe nun alle 
8-Bit-Zeichen durch Hex-Werte ersetzt.

> Daher würde ich warten, bis das läuft und dann die notwendigen
> Änderungen nochmal zusammenfassen.

Alles klar.

> Ein Problem ergibt sich beim bauen der Lib mit dem gcc. dieser
> exportiert sämtliche non-static functions standardmäßig. Das heißt, dass
> auch die internen Funktionen von außen aufrufbar sind.

Welche sind das zum Beispiel? Eigentlich sollten alle internen 
Funktionen auch static sein.

> Nebenbei:
> Hättest du was dagegen Analyzer-Programm-Teil aus der irmp.c-Datei
> rauszuziehen?
> Also alles nach  "main functions - for Unix/Linux + Windows only!"

Ja, kann ich machen. Stört mich sowieso mittlerweile.

> Mein Vorschlag wäre:
> irmp.h/c wie gehabt (nur ohne die erwähnten Anteile).
> irmpprotocols_intern.h die parameter defines/structuren (bis ca Zeile
> 3000, ohne logging)
> irmp-main-PC.c enthält exklusiven PC-Code includiert irmp.c (ab zeile
> ~5500)

Ja, so ähnlich werde ich es wohl machen.

von Vlad T. (vlad_tepesch)


Lesenswert?

Frank M. schrieb:
> Welche sind das zum Beispiel? Eigentlich sollten alle internen
> Funktionen auch static sein.

Intern im Sinne von 'sollen nicht zum Interface der PC shared library 
gehören'. Zb die ISR

Frank M. schrieb:
> Ist mir auch aufgefallen, das waren ISO8859-Zeichen, Dein Editor scheint
> im UTF-8-Format zu arbeiten. Macht aber nichts, ich habe nun alle
> 8-Bit-Zeichen durch Hex-Werte ersetzt.

Ich hatte es auch versucht mir notepad++ nach ansi zu konvertieren, aber 
der GCC hatte trotzdem Warnungen ausgespuckt. Hatte das dann aber nicht 
weiter untersucht

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Vlad T. schrieb:
> aber der GCC hatte trotzdem Warnungen ausgespuckt.

Ja, dem GCC ist egal, in welchem Zeichensatz der Quelltext vorliegt. 
8-Bit-Zeichen sind ihm generell suspekt.

Ersetze einfach den Block durch folgendes:
1
    static uint8_t key_table[128] =
2
    {
3
     // 0     1      2    3    4     5    6    7    8     9     A     B     C     D     E     F
4
        0x00, '^',  '1', '2', '3',  '4', '5', '6', '7',  '8',  '9',  '0',  0xDF, 0xB4,  0x00, '\b',
5
        '\t', 'q',  'w', 'e', 'r',  't', 'z', 'u', 'i',  'o',  'p',  0xFC, '+',  0x00,  0x00, 'a',
6
        's',  'd',  'f', 'g', 'h',  'j', 'k', 'l', 0xF6, 0xE4, '#',  '\r', 0x00, '<',   'y',  'x',
7
        'c',  'v',  'b', 'n', 'm',  ',', '.', '-', 0x00, 0x00, 0x00, 0x00, 0x00,  ' ',  0x00, 0x00,
8
9
        0x00, 0xB0, '!', '"', 0xA7, '$', '%', '&', '/',  '(',  ')',  '=',  '?',  0x60,  0x00, '\b',
10
        '\t', 'Q',  'W', 'E', 'R',  'T', 'Z', 'U', 'I',  'O',  'P',  0xDC, '*',  0x00,  0x00, 'A',
11
        'S',  'D',  'F', 'G', 'H',  'J', 'K', 'L', 0xD6, 0xC4, '\'', '\r', 0x00, '>',   'Y',  'X',
12
        'C',  'V',  'B', 'N', 'M',  ';', ':', '_', 0x00, 0x00, 0x00, 0x00, 0x00, ' ',   0x00, 0x00
13
    };

Das ist dann reines 7-Bit.

: Bearbeitet durch Moderator
von Vlad T. (vlad_tepesch)



Lesenswert?

Vlad T. schrieb:
> Daher würde ich warten, bis das läuft und dann die notwendigen
> Änderungen nochmal zusammenfassen.

So, in Sigrok/Pulseview läufts (screenshot). Ich hab den Code für die 
DLL in eigene Dateien gezogen. Allerdings ist ein kleiner Patch (patch 
1) für die irmp.c trotzdem nötig.

Dem Compiler darf nur die irmp-main-SharedLib.c gegeben werden, da die 
irmp.c includiert wird.

Außerdem hab ich angehangen, was für die IRMP integration in Sigrok oder 
Pulseview nötig ist. Auch fertig gebaute dlls sind enthalten.


patch 2 fixt ein paar const issues.
Außerdem ist mir aufgefallen, dass an einigen stellen, Mikro und 
Milli-Sekunden durchander gebracht werden.
Bei den Timeout-defines und bei dieser Zeile:
1
   for (i = 0; i < (int) ((10000.0 * F_INTERRUPTS) / 10000); i++)               // newline: long pause of 10000 msec

Meiner meinung nach kommt da eine Sekunde raus, weile F_INTERUPTS genau 
einer Sekunde entspricht, was das komische rumgerechner überflüssig 
macht.

: Bearbeitet durch User
von Vlad T. (vlad_tepesch)


Angehängte Dateien:

Lesenswert?

hmpff - warum fällt einem sowas immer erst hinterher auf:
Hier eine korigierte Version des decoders, der in den höchsten 
zoomstufen auch die PRotokoll-Nummer anzeigt.

von Abraxa (Gast)


Lesenswert?

Hallo Vlad, wie du IRMP in libsigrokdecode eingebunden hast, zeugt von 
viel Willen, das zum Laufen zu bekommen. Hut ab! :)

Wir würden dir die Arbeit gerne einfacher machen, indem wir ctypes 
direkt bereitstellen und IRMP zusammen mit libsigrokdecode kompilieren. 
Somit würde IRMP dann Bestandteil von libsigrokdecode werden und die 
Benutzer müssten nichts weiter tun, um IRMP nutzen zu können. Hast du 
daran Interesse?

Falls ja würden wir uns freuen, wenn du uns bspw. in IRC besuchen 
würdest (Link auf sigrok.org), um das zu besprechen.

von Vlad T. (vlad_tepesch)


Lesenswert?

Abraxa schrieb:
> Somit würde IRMP dann Bestandteil von libsigrokdecode werden und die
> Benutzer müssten nichts weiter tun, um IRMP nutzen zu können. Hast du
> daran Interesse?

Davon würde ich aktuell abraten (dazu mehr weiter unten) Glaube auch, 
dass es nicht nötig ist.
Das Konzept mit den externen Dekodern ist ja an sich Recht hübsch. Da 
einzelne Dekoder mit einzukompilieren fühlt sich falsch an.
Das größte Problem, was ich beim einbinden hatte, war ja tatsächlich die 
fehlende ctypes DLL. Wenn das gelöst wäre, wäre es viel einfacher. 
(Andererseits entfällt natürlich dass erstellen der 
Plattformspezifischen irmp lib)

Zu dem anderen Problem:
Ich würde den aktuellen Stand der irmp nicht als so stabil betrachten, 
um ihn als festen Bestandteil auszuliefern. Nicht, weil die irmp buggy 
ist, sondern ihr Design ist aktuell nicht auf multithreading ausgelegt. 
Das kann auch die DLL oder der Python-Wrapper nicht ändern.

Hier könnte man Frank fragen, wie die weitere Planung für die irmp 
aussieht.
Er hatte geäußert, dass er selbst ein paar Restrukturierungen geplant 
hat. Danach könnte man schauen, ob man Den Zustand nicht vielleicht in 
einem Objekt, anstelle von globalen/statischen Variablen speichern kann 
(eventuell kriegt man das auch konfigurierbar hin, ohne den Code ins 
bodenlose mit ifdefs zuzupflastern)

Alternativ wäre natürlich ein branch denkbar.
Wenn möglich würde ich das allerdings vermeiden wollen.

von gsi (Gast)


Lesenswert?

[ Fuer die Eiligen: Find's gut, kein Blocker, bitte integrieren. :) ]

Dass IRMP im Kern nicht multithreading faehig ist sehe ich nicht als
Blocker an, fuer eine MCU Firmware ist das voellig normal und erwartbar.
Wenn daraus folgt dass man die DLL zusammen mit dem Decoder-Code nur
fuer exakt eine Decoder-Instanz zu jeweils einer Zeit einsetzen kann,
ist das eine Einschraenkung, die aber voellig in Ordnund sein kann (weil
bekannt und dokumentiert).  Vergleicht man das mit dem bisherigen 
Zustand
(nur wenige Decoder fuer Protokolle die "immer mehr aus der Mode kommen"
und keine(?) fuer aktuell gesprochene Protokolle), dann ist der Support
fuer viele und vor allem relevante Protokolle durch Einsatz von IRMP
eine klare Verbesserung und damit wuenschenswert.

Fuer die konkrete Anbindung von IRMP an sigrok sehe ich mehrere 
Varianten:
Die C-Library die IRMP "im Bauch" hat und statt Hardware-Timer und -Pin
ein API hat ueber das der PC die Daten anliefert.  Die Lizenz erlaubt
die Integration in und Auslieferung mit sigrok zusammen.  Den 
zusaetzlichen
Code mit libsigrokdecode zusammen zu uebersetzen muss auch machbar sein.

Ob's verrueckt klingt muss jeder fuer sich entscheiden.  Ich sehe noch
eine Alternative: IRMP auf der MCU laufen lassen wie bisher, ueber UART
ein Protokoll sprechen das: identifizieren laesst, unterstuetzte 
Protokolle
listet (Namen holen und cachen), Pin-Werte injiziert, Ergebnisse holt.
Dann kann der Python-Code in pd.py ueber das pyserial Modul mit der UART
sprechen, was plattform-unabhaengig ist.  Womit die C-Library auf dem PC
entfaellt, inclusive ctypes Wrapper, und Integration von IRMP-Code und
-Build in libsigrokdecode.  Man haette praktisch ein "Hardware-Dongle"
das sehr nahe am "traditionellen" Einsatz von IRMP auf MCUs ist, 
sozusagen
hardware-unterstuetztes Protokoll-Decoding. :)  Dass der COM-Port auch 
nur
einmal geoeffnet werden kann und damit nur eine Decoder-Instanz erlaubt,
ist keine Verschlechterung.  Siehe oben.

Meinungen?  Habe ich was uebersehen?

Die globalen Variablen im IRMP Kern in einen struct zu verschieben
und evtl mehrere Instanzen davon zu unterstuetzen (je nach Target,
also z.B. auch nur wenn fuer PC gebaut), sehe ich als unabhaengig
von oder zusaetzliche Moeglichkeit zur Integration mit sigrok an.  Je
nach Target kann das sogar eine Verbesserung sein die fuer MCU
wuenschenswert ist.  Fuer AVR macht es wohl weniger aus.  Fuer ARM
(Cortex-M3) koennte es ein wenig Performance und/oder reduzierten
Speicherverbrauch ergeben.  Ob der kosmetische Gewinn den Aufwand
wert ist -- Geschmackssache.  Fuer die Konfigurationen die mehrere
State-Instanzen unterstuetzen, muss man dann aber wohl die Referenz
darauf oder Index da rein ueberall durchreichen, was evtl keine
wuenschenswerte Aenderung am bestehenden Projekt ist, weil der
Einsatzzweck evtl zu obskur oder zu rar ist.

von Abraxa (Gast)


Lesenswert?

Hallo Vlad,

> Glaube auch, dass es nicht nötig ist.
Warum bist du dieser Meinung? Das ist mir leider nicht schlüssig.

> Da einzelne Dekoder mit einzukompilieren fühlt sich falsch an
Ob die Dekoder jetzt in python laufen oder in C ist für den Benutzer 
irrelevant und ctypes werden wir langfristig sowieso in Dekodern sehen, 
um noch ganz andere Features umsetzen zu können. Von daher wäre IRMP nur 
der Vorreiter :)

> ihr Design ist aktuell nicht auf multithreading ausgelegt
...dann erlaubt man eben nur eine Instanz des Dekoders, bis das gefixt 
ist. Das ist kein Problem.

von Vlad T. (vlad_tepesch)


Lesenswert?

Abraxa schrieb:
> ctypes werden wir langfristig sowieso in Dekodern sehen, um noch ganz
> andere Features umsetzen zu können. Von daher wäre IRMP nur der
> Vorreiter :)

Ctypes wird doch nur Verwendet, weil es in einer externen dynamischen 
lib ist. Wenn ihr das in Zukunft sowieso immer mitliefert, ist es nicht 
notwendig, wenn der komplette Decoder in der Decoder-lib als c(++) 
vorliegt, es sei denn der Python Decoder bleibt und zieht nur die irmp - 
Funktionen aus der Decoder-lib

gsi schrieb:
> Fuer die konkrete Anbindung von IRMP an sigrok sehe ich mehrere
> Varianten: Die C-Library die IRMP "im Bauch" hat und statt
> Hardware-Timer und -Pin ein API hat ueber das der PC die Daten anliefert

Genau so funktioniert es ja aktuell in meiner Lösung. Natürlich braucht 
man keine mcu.

gsi schrieb:
> Vergleicht man das mit dem bisherigen Zustand (nur wenige Decoder fuer
> Protokolle die "immer mehr aus der Mode kommen" und keine(?) fuer
> aktuell gesprochene Protokolle), dann ist der Support fuer viele und vor
> allem relevante Protokolle durch Einsatz von IRMP eine klare
> Verbesserung und damit wuenschenswert.

Jepp

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Zur libsigrokdecode-Diskussion:

Leider bin ich nicht früher dazu gekommen, mich hier eingehend dazu zu 
äußern... ich habe bisher einfach keine Zeit dazu gefunden.

Der jetzige IRMP-Code ist zwar für verschiedenste Umgebungen bzw. 
Plattformen geeignet, jedoch sind die neueren Features (Protokolle und 
Zielplattformen) seit 2009 immer wieder angeflanscht worden. Mit der 
Zeit entstand daher ein Gebilde, was ich heute so nicht mehr erstellen 
würde, wenn ich mit allen inzwischen gesammelten Anforderungen nochmals 
von vorne beginnen würde.

Von daher könnte man die sigrok-Geschichte als Anlass nehmen, IRMP 
komplett neu zu machen - mit identischen Anforderungen/Interfaces wie 
beim bisherigen IRMP. Man könnte die neue Version zum Beispiel IRMP2 
nennen.

Was mir schon lange ein Dorn im Auge ist:

1. 16 Bit Members in IRMP-Struct. Diese würde ich gern auf 32 Bit 
erhöhen.
2. Die riesengroße ISR, welche on-the-fly decodiert.
3. Viele globale (Zustands-)Variablen, welche immer mehr wurden.
4. Große irmp.c

zu 1)

Manche Prokolle bieten mehr Informationen als nur 16 + 16 Bits für 
Adresse und Kommando. Es war zum Beispiel gar nicht so einfach, das 
Kaseikyo-Protokoll mit 48 Bits da rein zu quetschen. Nach Abzug der 
redundanten Infos wie zum Beispiel CRCs blieben immer noch 4 Bit übrig, 
die irgendwo unterebracht werden müssen. Diese landeten daher im oberen 
Nibble der flag-Variablen. Dieses Nibble wurde kurzerhand als zum 
Kommando gehörendes Teilpaket erklärt, so dass hier dann 20 Bit fürs 
Kommando möglich waren. Eine Anpassung an IRSND sorgte dann auch dafür, 
dass diese 4 Bits (die meist 0 sind) auch wieder gesendet werden 
konnten.

Dann gibts da zum Beispiel auch noch das Merlin-Protokoll, welches in 
der Anzahl der möglichen Bits variabel ist und auf bis zu 32 Bits fürs 
Kommando anschwellen kann. Hier wurde die IRMP-Struct per 
Preprocessor-Define einfach auf 32 Bit  Werte aufgebohrt, sobald man 
Merlin decodieren wollte. Als Nachteil hat sich jetzt im nachhinein 
herausgestellt, dass zumindest die AVRs bei 32-Bit-Variablen innerhalb 
der ISR ins Schleudern kommen. Sobald man als Merlin als Protokoll 
hinzunimmt, kann es passieren, dass der Decoder dann überhaupt nicht 
mehr läuft - egal für welches Protokoll.

zu 2)

Die Größe der ISR ist erstmal nicht das Problem für den µC. Durch die 
Zustandsvariablen verbleibt der µC nur kurze Zeit in der ISR, weil immer 
nur ein kleiner Teil durchlaufen wird. Damit kann IRMP das 
identifizierte Protokoll schon inmerhalb der ISR on-the-fly decodieren. 
ohne Zeitprobleme zu bekommen.

Allerdings hat sich ein anderer Nachteil im Laufe der Zeit 
herausgestellt:

Es gibt nämlich Protokolle, die zueinander so ähnlich sind, dass sie in 
der ISR parallel decodiert werden müssen. Das macht IRMP nämlich 
zumindest bei einigen Protokollen so: Gibt es mehrere Möglichkeiten für 
ein Protokoll, verfährt IRMP parallel, bis eines der in Frage kommenden 
Protokolle verworfen werden kann. Das wird dann rausgekickt und dann nur 
noch der andere Zweig verfolgt. Ebenso kann IRMP über 
Plausibilitätsregeln (frühzeitiges Timout o.ä.) zwischen verschiedenen 
Protokollen dynamisch hin- und herschalten, bis am Ende nur noch eines 
übrig bleibt.

Im Laufe der Zeit sind aber so viele Protokolle hinzugekommen, dass 
diese Parallelverarbeitung immer komplizierter wird. Daher habe ich mich 
irgendwann dafür entschlossen, bei Verwendung von ganz bestimmten 
Protokoll-Kombinationen Teile von Protokollen per Preprocessor während 
der Compilezeit aus dem Code zu werfen: Man bekommt dann eine Warnung, 
dass wenn man X + Y verwenden will, das Protokoll Y ausgeschlossen wird.

Letzteres ist ein erheblicher Qualitätsverlust. Daher schwebt mir 
mittlerweile ein anderes Verfahren vor:

a) In der ISR wird der empfangene Frame nur noch aufgezeichnet 
("Recording") und möglichst kompakt gespeichert.

b) Außerhalb der ISR wird dann der aufgezeichnete Frame analysiert und 
decodiert. Das hat den Vorteil, dass man alle möglichen Protokolle 
nacheinander gemütlich durchgehen kann. Stress wegen 
Parallelverarbeitung entfällt dann.

Letzteres ist ein wesentlicher Vorteil, den man sich jedoch eventuell 
mit erhöhtem Speicherbedarf erkauft. Ich denke hier an den knappen RAM 
von ATTinys. Man gewinnt jedoch auch Speicher, weil dann viele der 
jetzigen Zustandsvariablen entfallen.

Ein weiterer Gewinn: Wenn sich die ISR auf Recording beschränkt, ist die 
Verwendung von 32-Bit-Variablen für Adresse und Kommando auch für AVRs 
kein Hindernis mehr. Auf diese wird dann nur noch außerhalb der ISR 
zugegriffen.

Zu 3)

Viele der Zustandsvariablen können entfallen, wenn Recording und 
Decoding zwei getrennt Vorgänge sind.

zu 4)

Das Decoding kann dann außerhalb der ISR auch außerhalb von irmp.c 
geschehen. Hier könnten zuminfdest die verschiedenen Kodierungen wie 
Pulse Distance, Pulse Width, Biphase (Manchester), usw. in einzelne 
C-Module wandern.

Im Zuge dessen könnte man den ganzen Code auch weiter modularisieren, 
d.h. in weitere C-Module aufsplitten.

Fazit:

Ich halte es für sinnvoll, IRMP neu zu machen. Dann aber nicht als 
One-Man-Show, sondern eher als Team-Projekt. Mit dem ganzen Wissen der 
letzten 10 Jahre dürfte ein Redesign nicht so lange dauern. Schließlich 
existiert ja ein Source, der lediglich neu strukturiert werden muss.

: Bearbeitet durch Moderator
von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Die Größe der ISR ist erstmal nicht das Problem. Durch die
> Zustandsvariablen verbleibt der µC nur kurze Zeit in der ISR, weil immer
> nur ein kleiner Teil durchlaufen wird. Damit kann IRMP das
> identifizierte Protokoll schon inmerhalb der ISR on-the-fly decodieren.
> ohne Zeitprobleme zu bekommen.

das hatte mir IMMER am Besten gefallen, damit hatte ich Tastenauswertung 
und IR Code zusammen fertig im loop und war in der Abarbeitung 
zeitunabhängig.

Klar verstehe ich deine Ausführungen, kann mir nur noch nicht vorstellen 
wie das läuft da innerhalb meiner loop die Zeiten ja variabel sind, je 
nach dem was anliegt!
Ich müsste noch mehr in Richtung state machine denken.

aber schaun mer mal....

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> das hatte mir IMMER am Besten gefallen, damit hatte ich Tastenauswertung
> und IR Code zusammen fertig im loop und war in der Abarbeitung
> zeitunabhängig.

Für Dich als Anwender würde sich gar nichts ändern.

Im Moment ist es so - stark vereinfacht:

A. ISR:

1. ISR prüft Start-Bit und legt sich auf Protokoll fest
2. ISR decodiert die Bits und füllt Adresse + Kommando
3. Wenn fertig, wird ein Flag gesetzt

B: irmp_get_data ()

1. Es wird geprüft, ob Flag von ISR gesetzt
2. Wenn nein, zurück mit FALSE
3. Wenn ja, werden Adresse + Kommando auf Plausibilität geprüft
4. Adresse + Kommando werden nach IRMP-Struct kopiert
5. Zurück mit TRUE

Zukünftig ginge das so:

A. ISR:

1. ISR füllt Recording-Buffer
2. ISR setzt Flag, wenn kein Pegelwechsel innerhalb von einem zu
   definierendem Timeout.

B: irmp_get_data ()

1. Es wird geprüft, ob Flag von ISR gesetzt
2. Wenn nein, zurück mit FALSE
3. Wenn ja, werden alle durch Start-Bit validierten Protokolle
   durchprobiert - nacheinander
4. Wenn Protokoll valide, werden die Zeiten im Recording-Buffer
   decodiert und als Adresse + Kommando in IRMP-Struct abgelegt
5. Zurück mit TRUE

Es wird also nur ein wenig Arbeit von der ISR in die Funktion 
irmp_get_data() verlagert.

Vorteile:

- Es entfallen jede Menge Zustandsvariablen.
- Der ISR-Code vereinfacht sich erheblich.
- Der Recording-Buffer kann auch direkt für IRMP_LOGGING genutzt werden.
- Es können 32-Bit-Members in der Struct verwendet werden.
- Es können alle Protokolle durchgetestet werden, d.h. es gibt
  keine Ausschlüsse von Protokollen mehr.
- Der Code für das Decoding von Manchester und den anderen
  Kodierungstypen kann getrennt werden, da komplett verschieden.
- Es können viele Teile des Codes in der ISR mehr modularisiert werden,
  weil diese nach irmp_get_data verschoben werden.
- Da die ISR sich nur noch auf das Recording beschränkt, wird die
  Durchlaufzeit noch weiter verkürzt. Dadurch wird das ganze System
  "echtzeitfähiger", da weniger Zeit in der ISR verweilt wird.

Nachteile:
- irmp_get_data() hat etwas mehr zu tun und braucht etwas länger,
  aber unmerklich. Vielleicht 1-2 msec auf AVR.
- Durch die Timeout-Erkennung in der ISR ergibt sich eine weitere
  Verzögerung.
- Eventuell etwas mehr RAM-Bedarf wegen Recording-Buffer.

Diskussion:

Der Mehrbedarf an RAM für den Recording-Buffer wird durch den Wegfall 
von vielen Zustandsvariablen teilweise kompensiert. Aufgabe ist hier, 
für den Recordingbuffer eine möglichst platzsparende Datenstruktur zu 
finden.

Da die ISR nun "dumm" ist und nichts mehr über IR-Protokolle weiss, muss 
das Ende eines empfangenen Frames über eine Timeout-Behandlung gemacht 
werden. Es gilt hier, diesen Timeout möglichst gering zu halten, damit 
die Verzögerung, wann irmp_get_data() mit der Decodierung loslegen kann, 
minimal ist. Dank den vielen gesammelten Daten der User (abgelegt im 
Verzeichnis IR-Data) kann man da aber schnell Erfahrungen sammeln und 
optimieren.

: Bearbeitet durch Moderator
von Jörg R. (jrie)


Lesenswert?

Würden dann auch Protokolle gehen, die jetzt nicht möglich sind, z.B. 
IMON?
Siehe 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Jörg R. schrieb:
> Würden dann auch Protokolle gehen, die jetzt nicht möglich sind, z.B.
> IMON?

Ja, das sollte damit wesentlich einfacher zu machen sein.

von Vlad T. (vlad_tepesch)


Lesenswert?

Frank M. schrieb:
> Jörg R. schrieb:
> Würden dann auch Protokolle gehen, die jetzt nicht möglich sind, z.B.
> IMON?
>
> Ja, das sollte damit wesentlich einfacher zu machen sein.

Wird nicht nicht aktuell schon eine Tastatur unterstützt, die auch quasi 
UART über IR ist?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Vlad T. schrieb:
> Wird nicht nicht aktuell schon eine Tastatur unterstützt, die auch quasi
> UART über IR ist?

Ja, meine ich mich auch zu erinnern - aber nicht mit 38 Bit ;-)

von 900ss D. (900ss)


Lesenswert?

Frank M. schrieb:
> - Durch die Timeout-Erkennung in der ISR ergibt sich eine weitere
>   Verzögerung.

Wie lang müsste der timeout denn sein? Hab mich mit den Protokollen nie 
beschäftigt.

Wenn man nur ein Protokoll aktiviert, dann könnte man diese Zeit sehr 
kurz halten, da ja der Frame mit der Dauer bekannt ist. Als Option 
vielleicht?

: Bearbeitet durch User
von 900ss D. (900ss)


Lesenswert?

Ich habe noch einen Vorschlag damit man IRMP leichter unter Linux 
verwenden könnte. Dort sind die Jitter der IRQs ja "recht groß" wenn man 
nicht im Kernel einen low Level Treiber baut.
Eine Option einbauen, die es erlaubt die Zeit aus einem Timer auszulesen 
anstatt die IRQ Frequenz als Zeitbasis zu nutzen. Damit darf die IRQ in 
gewissem Rahmen jittern und trotzdem könnte man die Zeit genau 
ermitteln.

Theoretisch könnte man dann die IRQ sogar wegfallen lassen und diese 
Funktion in einer sehr schnellen main-Loop aufrufen.

: Bearbeitet durch User
von Vlad T. (vlad_tepesch)


Lesenswert?

900ss D. schrieb:
> Ich habe noch einen Vorschlag damit man IRMP leichter unter Linux
> verwenden könnte. Dort sind die Jitter der IRQs ja "recht groß" wenn man
> nicht im Kernel einen low Level Treiber baut. Eine Option einbauen, die
> es erlaubt die Zeit aus einem Timer auszulesen anstatt die IRQ Frequenz
> als Zeitbasis zu nutzen. Damit darf die IRQ in gewissem Rahmen jittern
> und trotzdem könnte man die Zeit genau ermitteln.
>
> Theoretisch könnte man dann die IRQ sogar wegfallen lassen und diese
> Funktion in einer sehr schnellen main-Loop aufrufen.

Löst das wirklich das Problem? Zum einen braucht man hochgenaue 
Zeitstempel (Auflösung im 10μs Bereich - klassischer Weise kriegt man ja 
aber nur ms) und zum anderen weiß man dann nur, um wieviel man daneben 
liegt. Den Messwert zum eigentlich gewollten Zeitpunkt kriegt man auch 
nicht.


Gibt es unter Linux so eine Zeitbasis? Ich weiß, dass Qt eine Klasse zur 
Zeitmessung anbietet, und ich meine mich aus der Doku zu erinnern, dass 
die hochpräzise Messung mit unter Windows funktioniert. Da die Leute 
Ahnung von plattformunabhängigen Implementierungen haben, gehe ich davon 
aus, dass sie das implementiert hätten.

von 900ss D. (900ss)


Lesenswert?

Vlad T. schrieb:
> Gibt es unter Linux so eine Zeitbasis?

Du bekommst die absolute Zeit in Nanosekunden.
Damit hast du dann genau die Differenz zum vorherigen Ereignis.

Der Implementierungsaufwand für meinen Vorschlag dürfte sich auch sehr 
in Grenzen halten.

von gsi (Gast)


Lesenswert?

[ schnelles Fazit: Linux ist out of the box nicht echtzeitfaehig ]

Hab's nicht gemessen, ist eher ein Bauchgefuehl, aber:  Ich vermute
dass IRMP auf Linux weniger stabil funktionieren wuerde, wenn's im
User Space rennt (also nicht im Kernel in einem Treiber implementiert
ist).  Weil ein SoC keine MCU ist, und ein Desktop-OS kein RTOS.  Diese
Aussage bezieht sich ausdruecklich auf den Aufbau mit angeschlossener
Hardware, nicht die reine Software-"Simulation".

Mag sein dass man Zeitstempel kriegt die eine extrem hohe Aufloesung
suggerieren (besagte Nanosekunden).  Fraglich ist ob die entsprechende
Praezision auch gegeben waere und was die Granularitaet waere (hoch
aufloesen zu koennen aber selten und dann unscharf zu schedulen kann
ein Blocker sein).  Und egal ob man zuerst den Zeitstempel abgreift
und dann den aktuellen Level am Pin, oder umgekehrt: Dazwischen
kann beliebig viel Zeit vergehen und die Daten muessen nicht zu einander
passen.  Dem OS steht es frei dazwischen beliebige andere Aktivitaeten
auszufuehren.  Weiss nicht sicher ob der IRMP Kern gerne "aequidistante"
Samples haette, oder mit burst-artig angelieferten Daten beliebigen
Timings umgehen kann.  Aber ich waere nicht ueberrascht wenn so ein
Aufbau (Applikation im User Space die versucht Pins zu samplen und ein
IR Protokoll darin zu erkennen) nur zufaellig funktionieren wuerde, und
sporadische Fehler liefern bis wenig robust/zuverlaessig sein wuerde,
und dabei extrem schwer zu diagnostizieren weil das Verhalten sehr
individuell fuer verschiedene Maschinen sein wird.

Was sicher gut funktionert ist, die Pin-Werte per API in den Kern zu
liefern und dabei ein festes Timing anzunehmen.  So wie's der oben
diskutierte Ansatz des sigrok Decoders tut.  Darueber hinaus haette
ich aus den genannten Gruenden Bedenken.

Der richtige Ansatz unter Linux und Einbeziehung von Hardware waere
den Kernel um einen entsprechenden Treiber zu erweitern.  Da gibt es
schon einige, siehe drivers/media/pci/, drivers/media/rc/,
drivers/media/hid/, usw.  LIRC ist da und unterstuetzt aktuell
27 Protokolle soweit ich das sehe.  Andere Devices (spezielle Dongles
und IP Cores) werden auch unterstuetzt.  Im Zweifelsfall kann man
nach "infrared" unterhalb von Documentation/ oder drivers/ suchen,
sollte nur ein paar Dutzend bis wenige Hundert Treffer geben.

Uebrigens:  Selbst "ISR" sind im Linux-Kernel "kleine Tasks", die
scheduled werden und sich gegenseitig unterbrechen oder blockieren
koennen.  IRQ-Raten um die 100k/s fressen CPUs auf oder machen sie
tot (je nachdem wie viel man darin rechnet), mehrere 10k/s sind
je nach Maschine und Konfiguration gerade noch akzeptabel, oder schon
schmerzhaft bis grenzwertig, oder absolut nicht mehr ertraeglich.
Es hat seinen Grund warum manche Tasks besser in einem RTOS oder
bare metal auf einer MCU laufen. :)  Desktop-Systeme sind auf
Durchsatz getrimmt, was der genau vorher bestimmbaren Abarbeitung
im Weg steht und umgekehrt.  Man kann nicht beides gleichzeitig haben.

Wer's nicht glaubt, oder selbst sehen will:  Ausprobieren. :-]  Eine
Task schreiben die die ganze Zeit nichts anderes tut als an einem
Pin zu wackeln.  Und dann zusehen wie und ob der Takt gehalten wird.
Oder wie viele Denkpausen von welcher Laenge zu beobachten sind.  Ich
rate mal, und behaupte dass auch ein "unbeschaeftigter" Desktop-Rechner
nicht wie ein klassischer Microcontroller tickt.  Stabile Funktion
waere Zufall oder erfordert extra Klimmzuege.  Wenn's nur um zehn bis
hundert Zyklen je Sekunde geht und Aussetzer nichts machen, mag's gehen.
Wenn's wie bei IRMP um 20kHz Rate geht und nichts verpasst oder
verschliffen werden darf, koennte es ein Blocker sein.

von Stephan L. (kiffie)


Lesenswert?

Hallo Frank,

habe Anpassungen am Code gemacht, damit IRMP gut mit PIC32 tut, und zwar 
mit der PIC XC32 bzw ChipKIT toolchain. Hast du Interesse daran, das zu 
integrieren? Wäre auch bereit, ein Beispielprogramm, etwa 
irmp-main-pic32.c, zu schreiben.

Hier ein Link auf die Änderungen: 
https://github.com/kiffie/usb-spdif/commit/cb874246821425b9427c355e9f4f337935739dd3#diff-dd9e82c9e77c9de4a991b9b94f37ecec

Sind eigentlich nur ein paar wenige Zeilen.

Auf jeden Fall finde ich die IRMP lib super praktisch, weil man damit 
einfach sehr viele Fernbedienungsprotokolle unterstützen kann.

Viele Grüße

Stephan

von technikus (Gast)


Lesenswert?

Hallo Forum, Hallo ukw,

danke für das hervorragende Projekt!
Ich möchte gerne IRMP und IRSND für Apple Remotes in einem gemeinsamen 
Projekt nutzen.
Jetzt bin ich verwirrt. IRMP erkennt die Apple Remote. IRSND kann die 
angelernten Kommandos aber nicht übertragen.

Alle anderen Fernbedienungen die ich hier habe können empfangen und die 
empfangenen Daten können gesendet werden.

Laut Artikel IRSND Apple.

Hat jemand einen Ansatz wonach ich suchen könnte?

Danke
technikus

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Stephan L. schrieb:
> habe Anpassungen am Code gemacht, damit IRMP gut mit PIC32 tut, und zwar
> mit der PIC XC32 bzw ChipKIT toolchain. Hast du Interesse daran, das zu
> integrieren?

Vielen Dank, das übernehme ich.

> Wäre auch bereit, ein Beispielprogramm, etwa
> irmp-main-pic32.c, zu schreiben.

Sehr gern, würde mich freuen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

technikus schrieb:
> IRSND kann die angelernten Kommandos aber nicht übertragen.

Kannst Du die mit IRSND ausgesandten Codes denn mit IRMP wieder 
empfangen?

Zeige bitte einen Ausschnitt aus Deinem Source, mit welchen Codes Du den 
IRSND fütterst. Dann kann ich mir das ausgesandte Ergebnis im Simulator 
anschauen.

von technikus (Gast)


Lesenswert?

Hi,

ich empfange mit IRMP
z.B. Protokoll=11, Add=67, Cmd=10;

Das jage ich mit IRSND wieder raus.


Lernen
1
if (irmp_get_data(&irmpData))
2
{
3
if (!(irmpData.flags & IRMP_FLAG_REPETITION))
4
{
5
  System->irParameter.irmp[IRDATA_KEY1].protocol = irmpData.protocol;
6
  System->irParameter.irmp[IRDATA_KEY1].address = irmpData.address;
7
  System->irParameter.irmp[IRDATA_KEY1].command = irmpData.command;
8
  //nur die oberen 4 Bit speichern, da die unteren 4 Bit für diverse Flags reserviert sind
9
  System->irParameter.irmp[IRDATA_KEY1].flags = (irmpData.flags & 0xF0); 
10
          
11
  System-_LedBlink(1);
12
        
13
}
14
}



Senden
1
 irmpData.protocol = System->irParameter.irmp[IRDATA_KEY1].protocol;
2
 irmpData.address = System->irParameter.irmp[IRDATA_KEY1].address;
3
 irmpData.command = System->irParameter.irmp[IRDATA_KEY1].command;     
4
 irmpData.flags = RepVal;
5
      
6
 irsnd_send_data(&irmpData, 1);

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

technikus schrieb:
> ich empfange mit IRMP z.B. Protokoll=11, Add=67, Cmd=10;

Ich habe es gerade getestet und wohl den Fehler gefunden. IRSND sendet 
mit kontanter Apple-ID 0x8B (ergibt Adresse 0xD1) und ignoriert daher 
die von Dir übergebene Adresse 67. Das schien für alle mir übersandten 
Apple-Scans bisher zu stimmen.

Korrigiere bitte in irsnd.c die folgende Zeile:
1
irsnd_buffer[3] = 0x8B;
und ersetze sie durch
1
irsnd_buffer[3] = (command & 0x00FF);
(Ja, die Adresse landet hier im unteren Byte von command, das ist dem 
gemeinsamen Code von NEC und APPLE geschuldet)

Bitte sag dann Bescheid, ob es geklappt hat.

P.S.
Ausgabe im Simulator vor der Korrektur:
1
./irsnd-15kHz 11 67 10 | ./irmp-15kHz
2
01110111111000010000100010001011 p=11 (APPLE), a=0x00d1, c=0x0010, f=0x00
Die hier ermittelte Adresse 0x00d1 ist falsch.

Ausgabe im Simulator nach der Korrektur:
1
./irsnd-15kHz 11 67 10 | ./irmp-15kHz
2
01110111111000010000100011100110 p=11 (APPLE), a=0x0067, c=0x0010, f=0x00
Die hier ermittelte Adresse 0x0067 ist korrekt.

: Bearbeitet durch Moderator
von technikus (Gast)


Lesenswert?

Danke!!!

Wo in irsnd die Zeile?

von technikus (Gast)


Lesenswert?

Wenn ich mit IRSND gesendet hatte, habe ich mit IRMP auch sauber 
empfangen können.

Ich habe die Zeile gefunden und werde es nachstellen.
Leider komme ich erst nächste Woche wieder an die Hardware, gebe aber 
sofort Rückmeldung.

Danke vorab

von technikus (Gast)


Lesenswert?

Feedback: Positiv Getestet.
Die Änderung kannst du also übernehmen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Prima. Danke für die Rückmeldung.

von gsi (Gast)


Lesenswert?

[ Zusammenfassung: plane submission fuer sigrok, brauche Feedback ]

Habe mir endlich mal die Zeit genommen und was fuer libsigrokdecode
vorbereitet, um IRMP basiertes Dekodieren von IR in mainline zu 
bekommen.
Dabei gab es einige Stolpersteine.

Der https://www.mikrocontroller.net/articles/IRMP#Download Abschnitt
hat nicht gut funktioniert. Koennt Ihr bitte die Links einem Update
unterziehen? Das Subversion Repo kann man nur ansehen aber keine
Sandbox davon ziehen. Der git Mirror wird schon laenger nicht mehr
gespiegelt. Ein funktionierendes VCS Repo ist dem Download von ZIP
Archiven oder gar von Attachments in langen Forums-Threads vorzuziehen.
Wenn man externe Quellen weiter verfolgen und Updates einpflegen will,
ist Filetransfer einfach unguenstig.

Habe jetzt svn://mikrocontroller.net/irmp r191 als Basis verwendet. Wenn
ein anderes Repo besser geeignet ist und stattdessen verwendet werden
sollte, gebt bitte bescheid.

Auf diese r191 Version habe ich dann C und Python Anteile von Vlad drauf
gesetzt.  Start- und Ende-Marker, DLL-Verpackung, Python binding, und
sigrok Decoder.  Dieser Aufbau liefert gute Ergebnisse unter Linux, ein
Test mit Windows und Mac steht noch aus.

Am liebsten wuerde ich Euch angemessene Credits geben ("attribution"),
nur ist das schwer mit den bisher verwendeten Pseudonymen und ohne
Adressen, wie sie in git commits ueblich sind.  Bitte sagt ob und wie
Ihr genannt werden wollt, schliesslich habt Ihr die Arbeit geleistet.

Ich muss hier noch was aufraeumen, plane naechste Woche zu pushen (in
mein privates Repo, von wo aus andere sichten und testen koennen, bevor
es entweder weitere Runden mit Verbesserungen gibt, oder ins sigrok
Projekt eingeht).

von Jörg R. (jrie)


Lesenswert?


von Vlad T. (vlad_tepesch)


Lesenswert?

gsi schrieb:
> Habe mir endlich mal die Zeit genommen und was fuer libsigrokdecode
> vorbereitet, um IRMP basiertes Dekodieren von IR in mainline zu
> bekommen. Dabei gab es einige Stolpersteine

Was ist denn mit meinem pullrequest?
Da hatte ich auch alles noch Mal schön geordnet.

von gsi (Gast)


Lesenswert?

Vlad T. schrieb:
> Was ist denn mit meinem pullrequest?
> Da hatte ich auch alles noch Mal schön geordnet.

Kurz? Ist in der Form nicht im sigrok Projekt verwendbar. Gibt zwar fuer 
den Moment einen Satz von Code. Ist aber in der anschliessenden Wartung 
nicht mehr handhabbar. Wird verrotten wenn's nicht weiter gepflegt wird, 
ist aber unnoetig aufwaendig in der Wartung. Weshalb ich versuche zu 
helfen, und die verbleibende Arbeit noch zu machen, so dass das 
wuenschenswerte Feature integriert und den Nutzern verfuegbar gemacht 
werden kann. Ich glaube immer noch dass daran nichts Schlimmes ist.

Tip: Gib niemals Referenzen an, lass andere suchen. Macht mehr Spass.
https://github.com/sigrokproject/libsigrokdecode/pull/27
https://github.com/vladtepesch/libsigrokdecode 70038ea8803b

Stell Dir einfach vor ich wuerde nicht aus Langeweile fragen, sondern 
wuerde mir wirklich eine Antwort wuenschen, um danach mit der erhaltenen 
Information weiter zu arbeiten. Ist das so schwer zu glauben? Also noch 
ein Versuch, bei Desinteresse kann ich's auch gerne lassen und meine 
Zeit mit anderen Arbeiten verbringen.

Wo kann man die IRMP Version herkriegen, die als die Hauptversion 
gilt? In der die Entwicklung stattfindet, von der andere Varianten 
hergeleitet sind, in die externe Entwicklung wieder zurueck uebernommen 
wird. Von der man sich kuenftig Updates holt. Der Download Abschnitt in 
der IRMP Projektseite liefert diese Information leider nicht. Welche 
Version verwendet man von dort am sinnvollsten (falls es Branches oder 
Release-Tags oder aehnliches gibt). Wem soll man fuer die Anbindung an 
sigrok danken? Einer Figur aus der Literatur mit einer noreply Adresse? 
Oder einer realen Person, oder niemandem? Mir egal wie die Antwort 
heisst, aber antworte bitte damit ich's wissen kann.

Hier ist was ich aus Deiner Vorlage gemacht habe. Mangels Information 
habe ich halt raten muessen. Gib Bescheid wenn was falsch ist. Danke! 
(Zum Schmoekern empfehle ich die 'commitdiff' Links.) Test mit Mac und 
Windows steht immer noch aus.

https://repo.or.cz/libsigrokdecode/gsi.git/shortlog/refs/heads/wip/irmp-pd-v2

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

gsi schrieb:
> Wo kann man die IRMP Version herkriegen, die als die Hauptversion gilt?

svn://mikrocontroller.net/irmp

Tarball: http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar

von Vlad T. (vlad_tepesch)


Lesenswert?

Ich bin etwas verwirrt und ehrlich gesagt auch ein wenig angepisst.
Wir haben nen halben Abend im IRC darüber geschrieben, wie es erstmal 
integriert werden könnte, und wie ich euch dabei unterstützen kann.

Fazit war eine aufs nötige reduzierte IRMP-Version.

gsi schrieb:
> Kurz? Ist in der Form nicht im sigrok Projekt verwendbar. Gibt zwar fuer
> den Moment einen Satz von Code. Ist aber in der anschliessenden Wartung
> nicht mehr handhabbar. Wird verrotten wenn's nicht weiter gepflegt wird,
> ist aber unnoetig aufwaendig in der Wartung.

Wie wir bereits eigentlich besprochen hatte, ist der Code ja auch 
erstmal als Brücke gedacht, solange, bis eine redesignte IRMP verfügbar 
ist. Für diesen Zweck ist der Code alte IRMP-Code ausreichend stabil. 
Wie von euch gewünscht, hab ich die für die Integration nicht benötigten 
Teile auch grob entfernt.

gsi schrieb:
> Tip: Gib niemals Referenzen an, lass andere suchen. Macht mehr Spass.

Dass ich nen PR gegen das github repo stelle, hattet ihr euch explizit 
gewünscht und war doch auch abgesprochen. Soviele offene sinds ja auch 
nicht. Das nen Monat nix passiert ist, hat mich nochnicht mal gestört, 
aber das es quasi ignoriert wird und neu nachgefragt wird, finde ich 
etwas unhöflich.

gsi schrieb:
> Wo kann man die IRMP Version herkriegen, die als die Hauptversion
> gilt?

auch diese Frage wurde schon mehrmals beantwortet. Sowohl hatte ich sie 
euch im IRC chat beantwortet, als auch hat Frank sie hier bereits 
beantwortet.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Vlad T. schrieb:
> Ich bin etwas verwirrt und ehrlich gesagt auch ein wenig angepisst.

Kann ich verstehen.

Was ist mit dem geplanten github-Repo als zukünftige Hauptquelle? 
Erstmal auf Eis legen?

von Vlad T. (vlad_tepesch)


Lesenswert?

Frank M. schrieb:
> Was ist mit dem geplanten github-Repo als zukünftige Hauptquelle?
> Erstmal auf Eis legen?

wie du bestimmt gesehen hast, hatte ich angefangen ein wenig den Code 
aufzuteilen. allzuviel  hab ich aber tatsächlich noch nicht gemacht. In 
den letzten Wochen ist der Drive nach der Arbeit zu Coden nicht so 
stark.

Daher dauert es bis dahin noch ein weilchen, denke ich.

Eine Frage, die ich Dir noch stellen wollte:
pflegst du eine Exceltabelle mit den ganzen Konstanten der 
unterschiedlichen Protokolle oder so? Falls nicht erstelle ich 
vielleicht mal eine.
Wollte versuchen damit mal ein wenig experimentieren.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Vlad T. schrieb:
> pflegst du eine Exceltabelle mit den ganzen Konstanten der
> unterschiedlichen Protokolle oder so?

Nein. Ich pflege da nur die irmpprotocols.h ;-)

Außerdem findet man die Konstanten im IRMP-Artikel unter 
IRMP: Die IR-Protokolle im Detail

von gsi (Gast)


Lesenswert?

Kann ich ein ACK oder NAK bekommen zu dem Branch den ich angelegt habe, 
so dass IRMP basiertes Dekodieren in das sigrok Projekt integriert 
werden kann? Wie oben erwaehnt zeigen die 'commitdiff' Links die am 
besten lesbare Form, die ich empfehlen kann um zu sehen was passiert 
(und warum jenseits vom pull request noch Arbeit uebrig war die auch 
noch getan werden muss).

Basis:
https://github.com/sigrokproject/libsigrokdecode/pull/27

aufbereitet:
https://repo.or.cz/libsigrokdecode/gsi.git/shortlog/refs/heads/wip/irmp-pd-v2

Sind die Angaben korrekt? Falls nicht, wie waere es richtig? Bei 
Ausbleiben von Antworten muss ich zurueckdrehen dort wo ich geraten 
habe, und auf die bisher verfuegbare duerftige Information zurueck 
fallen weil nichts Besseres zu kriegen war. Was ich schade faende.

Waere schoen den Vorgang vom Tisch zu kriegen. Zum Vorteil der Nutzer 
beider Projekte. Danke fuer Eure Muehe beim Sichten.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

gsi schrieb:
> Bei Ausbleiben von Antworten muss ich zurueckdrehen dort wo ich geraten
> habe,

Ich hoffe, Du lässt mir auch zwei Wochen Zeit, mir das anzuschauen. IRMP 
ist ein Privatprojekt für mich, da kann ich nicht täglich reinschauen.

Und Druck kann ich bei Privatprojekten überhaupt nicht leiden.

von Vlad T. (vlad_tepesch)


Lesenswert?

gsi schrieb:
> Kann ich ein ACK oder NAK bekommen zu dem Branch den ich angelegt habe,

Ich bin mir nicht sicher, was du erwartest.
Wofür brauchst du das ACK? BzW welche Informationen?

In der ersten Datei, in die ich geschaut habe, ist das erste, was mir 
auffällt, ist dass du die DLLSPEC defines an die Definitionen 
geschrieben hast.

Das ist nicht erlaubt. Keine Ahnung, ob du das unter Windows kompiliert 
hast, und der verwendete Compiler das nicht checkt, aber laut Docu ist 
das nicht erlaubt:

https://docs.microsoft.com/de-de/cpp/cpp/definitions-and-declarations-cpp?view=vs-2019


Und warum es eine stilistische Verbesserung darstellt, geschweifte 
Klammern bei Conditions zu entfernen, scheint mir auch fragwürdig. 
Nahezu jede Best-Practice empfiehlt diese und jede Codier-Richtlinie, 
die ich bisher gelesen habe forcieren sie.

Berücksichtigt die Platform detection Änderung auch Win64? Da ist nur 
von Win32 die rede.

gsi schrieb:
> (und warum jenseits vom pull request noch Arbeit uebrig war die auch
> noch getan werden muss).

vieles davon war in meinen Augen für eine Erst-Integration überflüssig 
und hätte gerade gezogen werden können, wenn IRMP2 verfügbar ist.

zB: Umbenneung der Funktionen im irmp-shared-lib.
Bennenst du bei jeder Lib, die du inkludierst, die Funktionen um?

Die Reformatierung im Python und die Restrukturierung der 
Python-Struktur:
Die Trennung der Sample-Nummern und der eigentlichen Protokolldaten war 
zB Absicht. Die spätere Struktur wird eher so aussehen, wie die 
Python-Struktur. Wobei hier die gleiche Frage greift: der 
IRMP-Python-Wrapper ist imho als fremd-lib zu sehen. Da ändert man doch 
nicht dran rum, wenn man die ins eigene Projekt integriert.

Die Anpassungen im IRMP-Code ebenso. Ich weiß, der wirft Warnungen, 
allerdings wollte ich so wenige Diffs wie möglich zum Original-Code 
erzeugen. Ich hatte im Wesentlichen, glaub ich, aus der irmp.c nur code 
gelöscht, was sich einfach mergen lässt, falls man wirklich noch mal ein 
update machen möchte.


Edit:
> DLLSPEC defines an die Definitionen
> Das ist nicht erlaubt.

Korrektur: Okay wieder was gelernt: streng genommen ist nur "import" an 
Definitionen nicht erlaubt, was eigentlich nicht vorkommen sollte, wenn 
man die lib kompiliert.

Imho ist das aber rein eine Sache der Deklaration - mag aber 
Geschmacksache sein, weil man eventuell möchte, dass die Definition ganz 
genauso aussieht, wie die Deklaration.

: Bearbeitet durch User
von gsi (Gast)


Lesenswert?

Frank M. schrieb:
> gsi schrieb:
> > Bei Ausbleiben von Antworten muss ich zurueckdrehen dort wo ich geraten
> > habe,
>
> Ich hoffe, Du lässt mir auch zwei Wochen Zeit, mir das anzuschauen. IRMP
> ist ein Privatprojekt für mich, da kann ich nicht täglich reinschauen.
>
> Und Druck kann ich bei Privatprojekten überhaupt nicht leiden.

Nachdem die vorherigen Antworten so ziemlich anders klangen (war Euch 
moeglicherweise nur nicht bewusst), habe ich halt nach etwa zehn Tagen 
nochmal nachgefragt, um herauszufinden was der Status ist. Diese Antwort 
von Dir war uebrigens das erste Signal in Richtung "sehe ich mir an" 
(auch das war Dir vermutlich nur nicht bewusst). Danke dafuer! Mir ist 
sehr klar dass da Arbeit dran haengt, ich kenne beide Seiten von 
Submission und Review. Nur kann ich leider keine Gedanken lesen, und 
muss das nehmen was verfuegbar wird.

Nimm Dir die Zeit die Du brauchst, jetzt wo ich den Status erfahren 
konnte (war vorher einfach nur offen geblieben, daher die Nachfrage). 
Und danke fuer's Ansehen!

Das ist uebrigens unser aller Freizeit in der wir an diesen Projekten 
arbeiten, geht ja nicht nur Dir so. Und ich habe mich auch nicht 
darueber beschwert dass es ein paar Wochen dauert bevor mal jemand seine 
Freizeit aufbringt um anderer Leute Features zu unterstuetzen. Das kam 
aus einer anderen Richtung. :-P

von gsi (Gast)


Lesenswert?

@Vlad: IRMP basiertes Dekodieren in sigrok scheint ja vor allem Deine 
Baustelle zu sein. Danke auch Dir fuer's Ansehen! Die Fragen beantworte 
ich etwas spaeter. Waren viele, dauert einen Moment. :)

von Vlad T. (vlad_tepesch)


Lesenswert?

gsi schrieb:
> @Vlad: IRMP basiertes Dekodieren in sigrok scheint ja vor allem Deine
> Baustelle zu sein. Danke auch Dir fuer's Ansehen! Die Fragen beantworte
> ich etwas spaeter. Waren viele, dauert einen Moment. :)

wirkliche fragen waren es ja nicht. Der größte Knackpunkt, der sich ja 
geklärt hat war das __declspec (vielleicht noch der check , ob win64 
korrekt funktioniert. Ich habs nicht getestet)

Der Rest war im wesentlichen nur etwas geringfügige Verständnislosigkeit 
über ein paar Kleinigkeiten, mit denen du dir zum einen wahrscheinlich 
unnötig Arbeit gemacht hast, und zum anderen eventuell die Integration 
späterer Versionen erschwerst.

Wenn es für das sigrok-decode Projekt aber erstmal funktioniert, ist es 
doch prima. Später kann man immer noch mal weiter schauen

von gsi (Gast)


Lesenswert?

Vlad T. schrieb:
> [ ... ] Der größte Knackpunkt, der sich ja
> geklärt hat war das __declspec (vielleicht noch der check , ob win64
> korrekt funktioniert. Ich habs nicht getestet)

Zum Thema Plattform-Erkennung:

Die UNIX_OR_WINDOWS Logik ist originaler IRMP Code, den habe ich weder 
erfunden noch veraendert. Ich habe den Kern sogar ganz bewusst gelassen 
wie er ist, und lege "von aussen" im Wrapper etwas vor damit der Kern 
findet was er nach Eurer Logik erwartet. Dabei verwendet der Wrapper 
eine Kondition die auch sonst fuer den gleichen Zweck in sigrok Sourcen 
verwendet wird, die in 32 und 64 Bit Varianten auf verschiedenen 
Windows-Versionen rennen. Ist also nicht total falsch, und zumindest so 
gut wie der vorherige Zustand im Projekt war (in beiden Projekten, um 
genau zu sein).

Waere vielleicht noch interessant warum "isoliert" (direkter 
Compiler-Aufruf) die Erkennung der Plattform in der Kern-IRMP #ifdef 
Sequenz funktioniert, aber nicht wenn der gleiche Code unter libtool und 
autotools uebersetzt wird. Wollte ich aber nicht tiefer untersuchen, 
sondern habe einfach schon andernorts funktionierende Konditionen 
uebernommen.

Gleicher Grund fuer die Export Dekoration. Siehe SR_API und SRD_API im 
sigrok Projekt. Ist dort seit ewig ueblich das Attribut bei Deklaration 
und Definition konsistent durchzureichen. Funktioniert in existentem 
Code quer ueber eine Latte verschiedener Plattformen. Habe mir nur 
verkniffen den IRMP Wrapper auf SRD_API (und seine Dependencies) zu 
hieven, und bin beim IRMP_DLLEXPORT Namen geblieben.

> Der Rest war im wesentlichen nur etwas geringfügige Verständnislosigkeit
> über ein paar Kleinigkeiten, mit denen du dir zum einen wahrscheinlich
> unnötig Arbeit gemacht hast, und zum anderen eventuell die Integration
> späterer Versionen erschwerst.

Was die kuenftige Wartung angeht: Schaetze ich genau anders herum ein.

Der IRMP-Kern (irmp.c und daraus referenzierte Header) ist bewusst 
"original" (erster "Import"), darauf folgend nur wenige Modifikationen 
die alle sehr konservativ sind und vor allem alle klar erkennbar (VCS, 
separate Commits). So dass ein Update des Kerns absolut schmerzfrei ist 
wenn das irmp.c API gleich bleibt.

Sollte das irmp.c API sich aendern, erwarte ich dass alle Anpassungen im 
Wrapper bleiben. Der vom Umfang her absolut ueberschaubar ist. Die 
Trennung von Wrapper und Kern war mir sehr wichtig, weshalb ich die 
"amalgamated" Version nicht als Verbesserung empfinden konnte.

Das prinzipielle Vorgehen (Zustand zuruecksetzen, Samples rein fuettern, 
Ergebnisse abholen wenn verfuegbar) bleibt ja. Wenn's in kuenftigen 
Versionen noch mehr Details nach Dekodierung vom Input geben sollte, 
bleibt der Ablauf gleich und damit der Wrapper und das Binding, und nur 
die Ergebnis-Struktur hat ein paar mehr Felder (und die Annotation im 
sigrok PD wird detaillierter). (Boese) Ueberraschungen erwarte ich an 
der Stelle nicht.

Wenn's in kuenftigen IRMP Versionen Aenderungen gibt die ueber die oben 
skizzierten Szenarien hinaus gehen, muss man halt sehen. Prognosen sind 
immer schwierig, und ganz besonders wenn sie sich auf die Zukunft 
beziehen. :-P Aber wenn man betrachtet wie "duenn" die Schichten Wrapper 
und Binding und Decoder sind gegenueber dem maechtigen Kern, und dass 
der Kern absolut geradeaus mit Updates versehen werden kann, erwarte ich 
wie gesagt keine Probleme.

Falls ich's vorher ungluecklich ausgedrueckt habe: Dein Ansatz ist ja 
sehr in Ordnung, und Du hast auch viel Muehe in die Zusammenstellung des 
Pull Request gesteckt. Es ist weniger der Inhalt der die Aufnahme in 
das sigrok Projekt unwahrscheinlich aussehen laesst, sondern die Form 
des Pull Requests. Die ich deshalb massiert habe um die Integration ins 
andere Projekt zu erleichtern. Auch wenn ich IRMP erst vor ein paar 
Wochen kennengelernt habe (sehr interessantes Projekt uebrigens, habe 
ich das schon einmal gesagt?), Du darfst mir glauben dass ich die 
Arbeitsweise vom sigrok Projekt recht gut kenne. Der Maintainer hat mir 
in den letzten Jahren mehrere hundert Commits abgenommen. D.h. ich kann 
schon ungefaehr einschaetzen ob etwas mehr oder weniger gut zum 
Gesamtbild und zur existierenden Codebasis passt. :-] Dein Ansatz wird 
uebernommen, die notwendige Arbeit ist fast getan (Tests stehen noch 
aus), Dir wird dafuer oeffentlich gedankt, und alle sind gluecklich. Und 
kuenftige Versionen werden noch besser. Was will man mehr?

Andere Formen der Anbindung sind vorstellbar, aber bedeuten mehr Arbeit: 
Aus dem Wrapper ein eigenes Projekt machen, das als selbstaendige 
Komponente daherkommt (aehnlich ftdi oder zip oder hidapi Libraries, mit 
cmake bauen oder so, bleibt aber die enge Interaktion mit IRMP und die 
Abhaengigkeit von dessen Interna, Stichwort #include von .c Files). 
Aufnahme des Wrapper als integraler Bestandteil des IRMP Projektes 
selbst (uebrigens: die Stile vom Wrapper und vom Kern unterscheiden sich 
drastisch, der Wrapper ist fast sowas wie der Ausreisser verglichen mit 
beiden Projekten, sigrok und IRMP). Meine massierte Version Deiner 
Vorlage ist einfach ein Kompromiss den ich mit vertretbarem Aufwand 
hinkriegen konnte, der wohl in dieser Form aufgenommen werden kann, und 
der die kuenftige Wartung ermoeglicht oder erleichtert. Ihr seid frei in 
was immer in IRMP an Fixes oder Verbesserungen oder Umbauten stattfinden 
soll, sowohl im Umfang und in der Weise als auch in der Zeit. Und bis 
dahin haben sigrok Nutzer ein neues Feature (bessere Abdeckung von IR 
Protokollen) und das IRMP Projekt hat mehr Nutzer und Sichtbarkeit.

Was die offenen Fragen angeht:

Hast eine Kopie vom Code angesehen ("Schnappschuss", Datei-Inhalt)? Oder 
die commits? Weil genau um die letzteren ging's mir die ganze Zeit. Die 
Meta-Daten, die ueber die Zeilen Code hinaus gehen, aber mindestens 
genauso wichtig sind. Weshalb ich immer auf die 'commitdiff' Links 
verwiesen habe, und nicht nach ZIP Archiv sondern nach URL zum Repo 
frage. Uebrigens ist es auch gute Tradition, dass man in commit messages 
lesen kann warum etwas passiert. Weil dass Code veraendert wurde und 
wie das kann man dem Diff ansehen, das ist fast schon langweilig. Das 
Warum sieht man leider nicht, aber genau da steckt oft der Hirnschmalz 
drin. Und genau diese Informationen braucht man wenn man Fehler sucht 
oder Updates einarbeitet.

von tolero (Gast)


Lesenswert?

Hallo,
habe mal ein paar Fragen zu IRMP. Habe es in meinem Arduino eingebunden. 
Es funktioniert soweit gut. Es gibt aber noch ein paar Problemchen.

Das Ganze läuft per AttachInterrupt auf Pin 3. Wenn eine bestimmte Taste 
gedrückt wird, soll ein Motor laufen. Leider enthält die Variable 
irmp_Data immer den letzten Wert, auch wenn keine Taste gedrückt wird. 
Wie kann man abfragen, ob gerade eine Taste gedrückt wird bzw. keine 
Taste gedrückt wird?

Danke.

von tolero (Gast)


Lesenswert?

Ach so, gibt es eine Art Funktionsübersicht zu IRMP?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

tolero schrieb:
> Wie kann man abfragen, ob gerade eine Taste gedrückt wird bzw. keine
> Taste gedrückt wird?

Der Rückgabewert der Funktion irmp_get_data() gibt die Information, ob 
eine Taste gedrückt wurde oder nicht.

tolero schrieb:
> Ach so, gibt es eine Art Funktionsübersicht zu IRMP?

Siehe Artikel IRMP. <-- hier klicken

von tolero (Gast)


Lesenswert?

Danke für die schnelle Antwort. Habe deinen Artikel genau gelesen, die 
Funktion aber wohl übersehen.

Der folgende Code funktioniert, nur gibt es bei dem Schrittmotor keine 
flüssige Bewegung. Nach jeder "fahren" Routine ruckelt es kurz, bis der 
neue IR-Befehl verarbeitet wurde.
1
void loop() {
2
  fahren();
3
}
4
5
void fahren() {
6
  if (runallowed == true) {
7
    for (int i = 0; i <= 320; i++) {
8
      digitalWrite(DIR, ydir);
9
      digitalWrite(STP, HIGH);
10
      delayMicroseconds(20);
11
      digitalWrite(DIR, ydir);
12
      digitalWrite(STP, LOW);
13
      delayMicroseconds(mspeed);
14
      runallowed = false;
15
      interrupts(); // enable interrupts
16
    }
17
  }
18
}
19
20
void handleReceivedIRData() {
21
  irmp_get_data(&irmp_data[0]);
22
  switch (irmp_data[0].command) {
23
    case 360: //rechts
24
      runallowed = true; //allow running
25
      ydir = HIGH;
26
      break;
27
    case 872:  //links
28
      runallowed = true; //allow running
29
      ydir = LOW;
30
      break;
31
  }
32
}

von Armin J. (arminj)


Lesenswert?

Na ja, die IR Befehle kommen ja auch nicht beliebig schnell 
hintereinander.
Daran kann das schon liegen.
Gib mal nur die millis() in handleReceivedIRData() aus, dann siehst du 
es.
Dann muss ein IR Befehl bei Dir vieleicht für eine längere Fahrzeit 
reichen (z.B. 400 statt 320).

von tolero (Gast)


Lesenswert?

Danke, habe ich gemacht. Einmal drücken = losfahren, nochmal 
drücken=stoppen

Funktioniert leider noch nicht. Das repetition-flag funktioniert nicht 
zuverlässig. Zeigt immer eine 1, wenn die Taste bereits gedrückt wurde 
und keine andere in der Zwischenzeit gedrückt wurde. Liegt das am 
attachInterrupt oder ist das generell so?
1
void handleReceivedIRData() 
2
  {
3
  irmp_get_data(&irmp_data[0]);
4
5
  switch (irmp_data[0].command) {
6
    case 360: //rechts
7
      Serial.print("rechts flags->");
8
      Serial.println(irmp_data[0].flags); 
9
      if (! (irmp_data[0].flags & IRMP_FLAG_REPETITION)) {
10
        Serial.println("rechts Einmalig");
11
        if (runallowed == true) {
12
          runallowed = false;
13
        }
14
        else {
15
          runallowed = true; //allow running
16
          ydir = HIGH;
17
        }
18
      }
19
      break;
20
    case 872:  //links
21
      Serial.print("links flags->");
22
      Serial.println(irmp_data[0].flags); 
23
      if (! (irmp_data[0].flags & IRMP_FLAG_REPETITION)) {
24
        Serial.println("links Einmalig");
25
        if (runallowed == true) {
26
          runallowed = false;
27
        }
28
        else {
29
          runallowed = true; //allow running
30
          ydir = LOW;
31
        }
32
      }
33
      break;
34
  }
35
}

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

tolero schrieb:
> irmp_get_data(&irmp_data[0]);

Das solltest du etwas ändern:
1
 if (irmp_get_data (&irmp_data))
2
  {
3
   if ((irmp_data.protocol == 0x1C) && (irmp_data.address == 0x0113)) 
4
   {
5
    switch (irmp_data.command) {
6
    case    FB_VIDEOUP  :  if (DAC[0] < 63) DAC[0]++;                 
7
          break;
8
// usw.
irmp_get_data() gibt 0 zurück, wenn da nichts neues war und einen Wert 
<> 0, wenn was empfangen wurde. protocol und address sind spezifisch für 
meine FB und sind bei dir sicherlich anders.

: Bearbeitet durch User
von tolero (Gast)


Lesenswert?

Das steht im seriellen Monitor:
1
links flags->1
2
links flags->1
3
links flags->1
4
links flags->1
5
rechts flags->0
6
rechts Einmalig
7
rechts flags->1
8
rechts flags->1
9
rechts flags->1
10
rechts flags->1
11
rechts flags->1
12
rechts flags->1
13
rechts flags->1
14
rechts flags->1
15
rechts flags->1
16
rechts flags->1
17
rechts flags->1
18
rechts flags->1
19
rechts flags->1
20
rechts flags->1
21
rechts flags->1
22
rechts flags->1
23
rechts flags->1
24
rechts flags->1
25
rechts flags->1
26
rechts flags->1
27
rechts flags->1
28
rechts flags->1
29
rechts flags->1
30
links flags->0
31
links Einmalig
32
links flags->1
33
rechts flags->0
34
rechts Einmalig
35
rechts flags->1
36
rechts flags->1
37
rechts flags->1
38
rechts flags->1
39
rechts flags->1
40
rechts flags->1
41
rechts flags->1
42
rechts flags->1
43
rechts flags->1
44
rechts flags->1
45
rechts flags->1
46
rechts flags->1
47
rechts flags->1

von tolero (Gast)


Lesenswert?

Matthias S. schrieb:
> tolero schrieb:
>> irmp_get_data(&irmp_data[0]);
>
> Das solltest du etwas ändern: if (irmp_get_data (&irmp_data))
>   {
>    if ((irmp_data.protocol == 0x1C) && (irmp_data.address == 0x0113))
>    {
>     switch (irmp_data.command) {
>     case    FB_VIDEOUP  :  if (DAC[0] < 63) DAC[0]++;
>           break;
> // usw.
> irmp_get_data() gibt 0 zurück, wenn da nichts neues war und einen Wert
> <> 0, wenn was empfangen wurde. protocol und address sind spezifisch für
> meine FB und sind bei dir sicherlich anders.

auch wenn es über einen attachInterrupt läuft?

von Armin J. (arminj)


Lesenswert?

@tolero
Bei Interrupt ist das schon richtig, wie Du das machst.
Die Standard IRMP die man hier im Forum kennt, kann gar kein Interrupt, 
das ist eine experimentelle Arduino Erweiterung von mir.
Ich werd mal bei mir testen und meld mich dann. Kann sein, dass da noch 
ein Bug drin ist.

: Bearbeitet durch User
von Armin J. (arminj)


Lesenswert?

Also bei mir tuts das, ich bekomme bei dem Interrupt Example:
1
P=NEC  A=0xFF00 C=0x19
2
P=NEC  A=0xFF00 C=0x19 R
3
P=NEC  A=0xFF00 C=0x19 R
4
P=NEC  A=0xFF00 C=0x19 R
5
P=NEC  A=0xFF00 C=0x19  <- Taste sehr kurz gedrückt
6
P=NEC  A=0xFF00 C=0x19  <- Taste sehr kurz gedrückt
7
P=NEC  A=0xFF00 C=0x19
8
P=NEC  A=0xFF00 C=0x19 R
9
P=NEC  A=0xFF00 C=0x19 R
10
P=NEC  A=0xFF00 C=0x19   <- Taste kurz gedrückt, 1 repeat
11
P=NEC  A=0xFF00 C=0x19 R
12
P=NEC  A=0xFF00 C=0x19
13
P=NEC  A=0xFF00 C=0x19 R
Das Interrupt Example tuts aber nicht für alle Protokolle, das geht 
theoretisch auch gar nicht.

Läuft das Interrupt Example denn bei Dir?

: Bearbeitet durch User
von Joachim B. (jar)


Lesenswert?

Armin J. schrieb:
> Die Standard IRMP die man hier im Forum kennt, kann gar kein Interrupt,
> das ist eine experimentelle Arduino Erweiterung von mir.

ähm, das ist so nur halb richtig, ich nutze IRMP auf dem AVR und auch 
auf den Arduino in der IDE aus früheren Zeiten auch mit IRQ, mache ein 
IRQ von 15000/s rufe IRMP auf, zähle bis 150 (10ms) und wenn die 
erreicht sind hüpfe ich in die Tastaturroutine von Dannegger mit 
Entprellung, schicke meine WS Updates raus (3ms), lese noch ein DCF77 
Bit sowie die RTC ein und bin dann wieder raus.
Das läuft auf meiner wordclock12h seit 2015.

IR geht,
Tastenabfrage und Entprellung geht,
DCF77 Auswertung geht auch
114 WS2812B gehen auch

Nur für ESP32 habe ich das noch nicht umgesetzt.

: Bearbeitet durch User
von Armin J. (arminj)


Lesenswert?

Joachim B. schrieb:
> ähm, das ist so nur halb richtig,
Ja wenn Du meinst...

Meine experimentelle Erweiterung ruft irmp_ISR() NUR auf, wenn der IR 
Pin wackelt.
Wenn das schonmal gemacht wurde, toll. Ist mir aber bis jetzt nicht über 
den Weg gelaufen.

von Joachim B. (jar)


Lesenswert?

Armin J. schrieb:
> Ja wenn Du meinst...

meine ich nicht, ist so

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Armin J. schrieb:
> Die Standard IRMP die man hier im Forum kennt, kann gar kein Interrupt,
> das ist eine experimentelle Arduino Erweiterung von mir.

Ach du meine Nase - was macht ihr gerade mit IRMP? Das war ein gut 
funktionierendes Stück Software, problemlos zu implementieren und gut zu 
verstehen.
Bitte lasst es jetzt nicht in einen Dschungel von verschiedenen 
Versionen untergehen und auseinanderdriften.

von Müllheim (Gast)


Lesenswert?

Armin J. schrieb:

> Meine experimentelle Erweiterung ruft irmp_ISR() NUR auf, wenn der IR
> Pin wackelt.

Daran erkenne ich den Profi: " ... wenn der IR Pin wackelt."

von 900ss D. (900ss)


Lesenswert?

Matthias S. schrieb:
> Ach du meine Nase

Das ging mir auch durch den Kopf... :-/
Ich fürchte es wird jetzt ein undurchschaubares Gewurschtel.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:
> Meine experimentelle Erweiterung ruft irmp_ISR() NUR auf, wenn der IR
> Pin wackelt.

Das kann bei vielen Protokollen zu einem Problem werden. IRMP behandelt 
oft Timeouts, um bestimmte Protokolle auseinanderzuhalten, gerade, wenn 
sich ähnliche Protokolle nur durch die Anzahl der Bits unterscheiden. 
Wenn die ISR nur noch bei Flanken aufgerufen wird, dann greifen diese 
Timeouts nicht mehr. Damit schließt Du die Erkennung von mindestens 
einem Dutzend von Protokollen prinzipiell aus. Es kann sogar dann 
passieren, dass bei bestimmten Kombinationen von aktivierten Protokollen 
dann beide nicht mehr erkannt werden.

Einfachstes Beispiel, um das zu veranschaulichen:

Wenn NEC und NEC42 oder NEC16 und NEC aktiviert sind - oder gar alle 
drei, dann werden diese dadurch unterschieden, dass entweder nach 16 
oder 32 oder 42 Bits ein Timeout erkannt wird. Das geht bei reinen 
flankengetriggerten Interrupts voll in die Hose. Die Statemachine hängt 
sich dann auf und bleibt mitten in der Abarbeitung eines Protokolls 
hängen, weil sie nicht mehr aufgerufen wird.

Ich hatte schon öfters überlegt, IRMP auf flankengetriggerte Interrupts 
umzustellen, dies aber immer wieder deshalb verworfen, weil ich dann für 
die Timeouts doch wieder einen zusätzlichen Timer hätte verwenden 
müssen. Ergo wäre der Gewinn (weniger CPU-Zeit) dadurch wieder 
relativiert worden.

Deshalb: Vergiss das mit den flankengetriggerten Interrupts, dafür ist 
die Statemachine nicht ausgelegt.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Frank M. schrieb:
> Wenn NEC und NEC42 oder NEC16 und NEC aktiviert sind - oder gar alle
> drei, dann werden diese dadurch unterschieden, dass entweder nach 16
> oder 32 oder 42 Bits ein Timeout erkannt wird.

Und genau diese Protokolle gehören zu den meist verwendeten heute. Jedes 
kleine RGB Drückerchen nutzt NEC - diese Dinger hier:
https://www.ebay.de/c/1956075631
Ebay-Artikel Nr. 362928547894

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Matthias S. schrieb:
> Und genau diese Protokolle gehören zu den meist verwendeten heute.

So ist es. War aber nur ein Beispiel, weil es am anschaulichsten war. 
IRMP arbeitet bei geschätzt jedem zweiten Protokoll über Timeouts, bei 
Manchester zum Beispiel zu 100 Prozent.

Da ist auch noch ein anderes Problem, wenn nur noch Flanken-Trigger 
reinkommen:

Bei einer simplen Störung, wie sie tagtäglich bei IR auftritt, zum 
Beispiel bei einer Nicht-Erkennung einer einzelnen Flanke, verbleibt die 
Statemachine in der Decodierung und wartet ewig auf das verbleibende 
letzte Bit. Erst ein erneutes Drücken der FB holt sie dann da raus - 
unter der Gefahr, dass dann diese Taste auch nicht mehr zuverlässig 
erkannt werden kann, da das Start-Bit zur "Reparatur" des letzten Frames 
und nicht zur Erkennung des nächsten Frames genutzt werden kann. 
Resultat: man drückt sich dann dumm und dämlich auf der Tastatur, bis 
die Statemachine wieder "im Takt" ist.

: Bearbeitet durch Moderator
von Armin J. (arminj)


Lesenswert?

Hallo,
Danke für die vielen Anmerkungen, Ihr habt ja alle recht:
Armin J. schrieb:
> Das Interrupt Example tuts aber nicht für alle Protokolle, das geht
> theoretisch auch gar nicht.

Die Flankensteuerung ist auch nicht in IRMP eingebaut, sondern 
aufgesetzt mittels extra Funktionen, die irgendwann irmp_ISR() aufrufen.
Frank M. schrieb:
> Deshalb: Vergiss das mit den flankengetriggerten Interrupts, dafür ist
> die Statemachine nicht ausgelegt.
Das habe ich auch bei meiner Implementierung festgestellt, aber es läuft 
jetzt mit überschaubarem Aufwand für wichtige Protokolle (siehe unten), 
und spart einen Arduino Timer und jede Menge CPU und ISR Calls, die z.B. 
bei anderen Libraries wie Neopixel oder Servo doch sehr stören können, 
bzw gar nicht funktionieren würden.

Matthias S. schrieb:
> Und genau diese Protokolle gehören zu den meist verwendeten heute. Jedes
> kleine RGB Drückerchen nutzt NEC - diese Dinger hier:

Und genau diese Dinger tun es mit der Flankensteuerung hervorragend, 
siehe protokoll: 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Nehmt einfach 
https://github.com/ukw100/IRMP/tree/master/examples/Interrupt
und probiert es aus :-)

Tested for NEC, Kaseiko, Denon, RC6, Samsung + Samsg32.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:
> Tested for NEC, [...]

Dürfte aber dann nur noch funktionieren, wenn NEC42 ausgeschlossen ist. 
Kannst Du das bestätigen?

von Armin J. (arminj)


Lesenswert?

Frank M. schrieb:
> Armin J. schrieb:
>> Tested for NEC, [...]
>
> Dürfte aber dann nur noch funktionieren, wenn NEC42 ausgeschlossen ist.
> Kannst Du das bestätigen?

Steht so in dem Beispiel :-)
1
#include <irmpSelectMain15Protocols.h>  // This enables 15 main protocols
2
#undef IRMP_SUPPORT_NEC42_PROTOCOL // this protocols is incompatible to NEC in interrupt mode, since it is the same as NEC but has longer data sections
3
#define IRMP_SUPPORT_NEC42_PROTOCOL      0

von gsi (Gast)


Lesenswert?

Ist gerade wieder ein Monat ohne Antwort vergangen. :(

Koennt Ihr bitte einen funktionierenden Link zum versionsverwalteten 
Stand der Quellen auf die Projektseite packen? Sollte sich hoffentlich 
"zwischendurch" erledigen lassen, dauert vermutlich nicht so lange wie 
Code gegenzulesen, oder schwierige technische Sachverhalte zu 
durchdringen, oder mit Hardware bisher noch nicht betrachtete 
Randsituationen nachzustellen. Sollte man denken.

Wenn die Projektseite warnt dass in diesem Repo Zwischen-Versionen oder 
Test-Zustaende liegen, ist es dann wert einen Hinweis auf eine 
bevorzugte Version zu geben? Oder die letzte bekannte funktionierende 
Version zu nennen? Sonst muss der Nutzer raten worauf der Schnappschuss 
im ZIP sich beziehen mag. Oder kann gar keinen Zusammenhang zwischen dem 
ZIP-Inhalt und dem Code-Repo herstellen. (Und ich glaube immer noch dass 
ein ZIP kein Repo ersetzen kann.)

Im Moment ist es fuer externe Projekte wirklich schwierig, vom aktuellen 
Zustand zu erfahren, oder den Fortschritt zu verfolgen, oder (auf 
wartbare Weise) Euren Code zu integrieren und spaeter Updates zu 
uebernehmen. Und das leider ganz ohne Notwendigkeit fuer die 
Erschwernis. Modifizierte Kopien aufzustapeln von denen man nicht 
erfahren kann wie sie aus einander entstanden oder wodurch sie sich 
unterscheiden kann's doch bestimmt nicht sein was man als Entwickler 
will.

Falls meine Variante der Integration in libsigrokdecode umstaendlich 
oder eigenartig oder aus anderen Gruenden nicht akzeptabel erscheint: 
Gibt's Meinungen zu oder Arbeiten an einer der anderen Vorgehensweisen? 
Ein eigenstaendiges Projekt, oder der Wrapper als Teil von IRMP? Hier im 
Forum und auch im Subversion kann ich davon nichts erkennen (letzte 
Aktivitaet vom 2019-08-28, seitdem Stille).

@Vlad: Willst Du fuer Deinen Beitrag zum sigrok Projekt genannt werden, 
und wenn ja wie? Kann ich weder dem Chat noch dem Forum noch dem Pull 
Request entnehmen, habe inzwischen mehrmals gefragt und immer noch keine 
Antwort bekommen. Musste raten, und muss ohne ACK die unbestaetigte 
Annahme wieder entfernen wenn keine Bestaetigung moeglich ist.

Falls Ihr kein Interesse an der Kommunikation habt, dann gebt bitte 
wenigstens ein NAK statt gar nichts. Dann kann ich wenigstens damit 
arbeiten statt weiter zu warten oder zu raten. Die aktuelle Haengepartie 
macht jedenfalls keinen Spass.

Nochmal die Links:
- https://www.mikrocontroller.net/articles/IRMP#Download
- https://github.com/sigrokproject/libsigrokdecode/pull/27
- 
https://repo.or.cz/libsigrokdecode/gsi.git/shortlog/refs/heads/wip/irmp-pd-v2

von Jörg R. (jrie)


Lesenswert?

gsi schrieb:
> einen funktionierenden Link zum versionsverwalteten
> Stand der Quellen

Ich mach das seit Jahren so:
1
wget "http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar" -O irmp.tar.gz

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

gsi schrieb:
>
> Koennt Ihr bitte einen funktionierenden Link zum versionsverwalteten
> Stand der Quellen auf die Projektseite packen?

Ich habe soeben im Artikel IRMP den Text unter Download angepasst. 
Dort ist nun ein Link auf die Stable Version als zip-Archiv und ebenso 
ein Link für die Development-Version auf das SVN von µc.net.

Den Hinweis auf irgendein spiegelndes GitHub-Repository habe ich 
rausgenommen, da das Spiegeln wohl schon seit Jahren nicht mehr 
funktioniert. Keine Ahnung, wer das mal gemacht und den GitHub Link im 
Artikel plaziert hat.

> Wenn die Projektseite warnt dass in diesem Repo Zwischen-Versionen oder
> Test-Zustaende liegen, ist es dann wert einen Hinweis auf eine
> bevorzugte Version zu geben?

IRMP ist ein Projekt, was mittlerweile "betagter" ist, das heisst die 
wilde Zeit der Entwicklung ist vorbei. Bis dahin gab es halt eine 
Entwicklungs- und eine Stable-Version, die sich unter Umständen stark 
unterscheiden konnten. Die Warnung war für diejenigen End-User gedacht, 
die mit Entwicklung nichts am Hut haben und lediglich ein stabiles Tool 
anwenden wollen.

Da schon seit geraumer Zeit hier nichts mehr grundlegendes zu 
entwickleln ist und daher seitdem lediglich Bug-Fixes oder ein mal ein 
neues IR-Protokoll hinzukommen, halte ich die Entwickler- und 
Stable-Version in letzter Zeit meist synchron. Ich habe daher nun die 
Warnung rausgenommen.

Zur Stable-Version: Diese ist ausschließlich für den End-User und 
damit für Dich als Entwickler uninteressant. Diese wird auch nicht 
weiterentwickelt, sondern spiegelt lediglich einen gut getesteten Stand 
dar.

Die Development-Version ist also für Dich als Entwickler die einzig 
maßgebliche, also der Link svn://mikrocontroller.net/irmp/

> Oder die letzte bekannte funktionierende
> Version zu nennen? Sonst muss der Nutzer raten worauf der Schnappschuss
> im ZIP sich beziehen mag.

Keine Ahnung, wen Du hier als "Nutzer" siehst. Ich sehe einen Nutzer als 
jemanden an, der IRMP ausschließlich in seiner Applikation anwendet und 
nichts am IRMP-Quellcode anpassen oder erweitern möchte. Also den 
Endanwender.

> (Und ich glaube immer noch dass ein ZIP kein Repo ersetzen kann.)

Natürlich soll das ZIP kein Repo ersetzen. Das ZIP ist für den 
Endanwender, der mit Entwicklung von IRMP nichts am Hut hat.

> Im Moment ist es fuer externe Projekte wirklich schwierig, vom aktuellen
> Zustand zu erfahren, oder den Fortschritt zu verfolgen, oder (auf
> wartbare Weise) Euren Code zu integrieren und spaeter Updates zu
> uebernehmen.

Wie gesagt, da tut sich sowieso im Code nicht mehr viel. Der letze Stand 
ist vom August 2018, das sagt doch schon alles. IRMP ist ein gut 
getestetes Tool und der Großteil der Anwender ist sehr zufrieden damit. 
Ab und zu kommt mal ein neues Protokoll dazu... das ist also 
mittlerweile eine ziemlich langweilige Geschichte geworden - was die 
Entwicklung angeht.

> Falls meine Variante der Integration in libsigrokdecode umstaendlich
> oder eigenartig oder aus anderen Gruenden nicht akzeptabel erscheint:

Was ich aus Deinen Anpassungen entnehmen konnte, ist das so okay für 
mich.

> Gibt's Meinungen zu oder Arbeiten an einer der anderen Vorgehensweisen?
> Ein eigenstaendiges Projekt, oder der Wrapper als Teil von IRMP?

Das ist mir vollkommen egal. Hauptsache, die bisherige 
End-Anwender-Zielgruppe kann weiterhin so einfach wie bisher IRMP in 
sein µC-Projekt integrieren.

> Hier im
> Forum und auch im Subversion kann ich davon nichts erkennen (letzte
> Aktivitaet vom 2019-08-28, seitdem Stille).

Ja, seitdem Stille. Da gibt es auch keine "geheimen" neuere Versionen. 
Okay, ich habe auf meinem PC noch eine etwas neuere Version vom Februar. 
Da IRMP aber letztendlich eine One-Man-Show ist, kann ich es mir 
leisten, diese Version erst irgendwann einzuchecken und nicht morgen. 
Ich bin sowieso (bisher) der einzige, der ins SVN eincheckt.

> Nochmal die Links:

Der einzig für Dich relevante:

svn://mikrocontroller.net/irmp/

: Bearbeitet durch Moderator
von gsi (Gast)


Lesenswert?

@Frank
Danke fuer die schnelle Antwort, und fuer das Update der Projekt-Seite!

Was "Nutzer" angeht, gibt's vermutlich verschiedene Sorten. Auch wenn 
ich Software-Entwickler bin und an anderen Projekten mitarbeite, bin ich 
bzgl IRMP dennoch "nur" Nutzer, weil ich die Komponente verwenden (s.o. 
integrieren) will, aber nicht vorhabe an der Komponente selbst zu 
schrauben, so lange nicht notwendig. Vielleicht haette ich "von aussen 
neu zu IRMP dazu kommend" oder aehnliches verwenden sollen? Als Kontrast 
zu jemandem der die Interna auswendig kennt, oder schon laenger mit IRMP 
vertraut ist und ueber die Zeit "genug mitbekommen" hat.

Der Punkt war, dass neu hinzukommende Teilnehmer mache Informationen 
nicht selbst schon wissen koennen, und auch durch Lesen oder Suchen 
nicht selbst herausfinden koennen. Weshalb sie dann fragen, 
moeglicherweise begruendet. Es ist wert, diese Frage zur Kenntnis zu 
nehmen und zu durchdenken, statt sie "wegzubuegeln" oder abzutun. Die 
angefragte Information zu liefern, oder besser noch gleich dem 
Naechsten auch verfuegbar zu machen, koennte insgesamt am hilfreichsten 
sein. Ich fand schade dass es so zaeh war an den Punkt zu gelangen wo 
dann die Information selbst mal aufkam und damit die Frage hinfaellig 
wurde. Und noch bedauerlicher dass der naechste Nutzer die gleiche 
Situation wieder vorgefunden haette und fast zwangsweise den gleichen 
Schmerz wieder erleben muss. Und "kommuniziere deshalb so viel 
hinterher", weil ich hoffe dass es dem naechsten Nutzer besser geht, 
weil der Schmerz inzwischen "schon mal durchlitten" aber auch "die 
Lektion mitgenommen" war. Versucht bitte beim naechsten Mal zu verstehen 
warum jemand fragt und welche Antwort wirklich hilft. Danke!

von gsi (Gast)


Lesenswert?

Jörg R. (jrie) schrieb:
> gsi schrieb:
> > einen funktionierenden Link zum versionsverwalteten
> > Stand der Quellen
>
> Ich mach das seit Jahren so:
>
> wget "http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar"; -O irmp.tar.gz

Schoen fuer Dich dass Du Dir selbst helfen kannst. Nur war das 
ueberhaupt nicht die Frage! In dem Teil den Du zitierst steht 
versionsverwalteter Stand der Quellen, was ein Schnappschuss in einem 
ZIP nicht ist. Was ich seit Januar (Chat mit vlad) bzw Februar (hier 
im Forum) versuche zu kommunizieren. Inzwischen haben wir April und ich 
konnte noch nicht einmal uebermitteln was die Frage war. Da kommt man 
sich manchmal vergackeiert vor. (Frank hat's inzwischen gemerkt -- Danke 
dafuer!)

Wenn Dir die Antwort soooo offensichtlich und einfach erscheint, und die 
Frage sooo dumm oder gegenstandslos, erwaege beim naechsten Mal bitte ob 
Du die Frage richtig verstanden hast. Fuer wie beschraenkt musst Du 
einen anderen Teilnehmer halten, der mehrfach beschreibt "ich sehe ein 
ZIP und ein Webfrontend, aber suche denk Link zum Repo", und glaubst die 
Antwort heisst "das ZIP ist dort"? Als ob ein anderer 
Software-Entwickler nicht in der Lage waere ein ZIP zu saugen von einem 
Link den er kennt und auf den er verweist und von dem er mehrfach 
aussagt dass das nicht die gesuchte Information ist ...

Der groesste Teil meines Frusts kommt nicht vom Fehlen einzelner 
Detail-Information, oder der vergangenen Zeit. Sondern vom scheinbaren 
Mangel an Bewusstsein fuer die Position des anderen Teilnehmers. Bitte 
bedenkt einmal diesen Aspekt! Versetzt Euch selbst fuer einen Moment in 
die Situation des anderen Menschen. Ihr koenntet Euch wundern. Und 
danach hoffentlich weniger schroff agieren. Sollte einen Versuch wert 
sein ...

von eku (Gast)


Lesenswert?

Hallo Frank und wer noch helfen könnte,

ich versuche Interoperabilität zwischen IRMP auf einem AVR, 
IRremoteESP8266 (https://github.com/crankyoldgit/IRremoteESP826) auf 
einem ESP8266 mit Tasmota, einer lernbaren Universalfernbedienung und 
der FB meines Thomson TV herzustellen.

Die Universal-FB habe ich von der TV-FB angelernt. Mit beiden kann ich 
den TV steuern. Und jetzt kommen IRMP und IRremoteESP8266 ins Spiel. 
Beispielhaft hier der Power-Knopf der originalen FB.

IRMP: MATSUSHITA 04 0AB0 054F
IRremoteESP8266: "NIKAI","Bits":24,"Data": 
"0x0D5F2A","DataLSB":"0xB0FA54"

Laut IRMP-Artikel hier im Wiki stimmt das mit den 24 Bit. In welcher 
Beziehung MATSUSHITA und NIKAI stehen, kann ich nicht beurteilen.

Hier der Versuch, die Bits zwischen IRMP und IRremoteESP8266 zuzuordnen:

1011 0000 1111 1010 0101 0100 0xB0FA54
HHHH HHCC CCCC AAAA AAAA AAAA

0000 1101 0101 1111 0010 1010 0x0D5F2A
HHHH HHCC CCCC AAAA AAAA AAAA

H=Herseller, C=Kommando, A=Adresse

Betrachtet man 4 Bit und lässt ein wenig Fantasie walten, dann geht das 
schon irgendwie auf. Ich hätte aber gerne ein klares Verständnis, schon 
wegen der eingangs genannten Interoperabilität. Der IRMP-Wikiartikel 
schweigt sich bezüglich der Aufteilung der 24 Bits aus.

Nächster Test ist das Senden ebendieses Signals.

IRSND -> IRremoteESP8266
"Protocol":"UNKNOWN","Bits":132,"Hash":"0xCEBB54B5","Repeat":0

IRremoteESP8266 -> IRMP
04 0AB0 054F

Sendet IRSND unsauber, was das Timing anbetrifft, oder liegt es an 
IRremoteESP8266?

Und noch ein Test.

Universal-IR -> IRMP
04 0AB0 054F

Universal-IR -> IRremoteESP8266
"Protocol":"UNKNOWN","Bits":52,"Hash":"0x641EDF9D","Repeat":0

Dabei muss man der Universal-FB zu gute halten, dass diese das Protokoll 
beim Anlernen nicht dekodiert, sonder nur aufzeichent und dann 
wiedergibt.

Wer kann helfen?

von Jörg R. (jrie)


Lesenswert?

Funktioniert denn IRSND -> Thomson TV?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

eku schrieb:
> Hier der Versuch, die Bits zwischen IRMP und IRremoteESP8266 zuzuordnen:
>
> 1011 0000 1111 1010 0101 0100 0xB0FA54
> HHHH HHCC CCCC AAAA AAAA AAAA
>
> 0000 1101 0101 1111 0010 1010 0x0D5F2A
> HHHH HHCC CCCC AAAA AAAA AAAA

IRMP fasst den Frame mit LSB first auf. Ob das richtig ist, weiß ich 
nicht, darüber habe ich keine Infos im Netz gefunden, das war damals 
lediglich bei der Dekodierung des MATSUSHITA-Protokolls eine Vermutung 
von mir.

Deshalb steht unter 
https://www.mikrocontroller.net/articles/IRMP#MATSUSHITA :
1
Bit-Order       LSB first?

Wenn Du also jeweils 8 Bit rückwärts liest, wird aus:
1
1011 0000 -> 0000 1101
2
1111 1010 -> 1111 0101
3
0101 0100 -> 0010 1010

> Der IRMP-Wikiartikel
> schweigt sich bezüglich der Aufteilung der 24 Bits aus.

Im IRMP-Artikel wird die Aufteilung durchaus genannt, siehe 
https://www.mikrocontroller.net/articles/IRMP#MATSUSHITA :
1
Frame           1 Start-Bit + 24 Daten-Bits + 1 Stop-Bit
2
Daten           6 Hersteller-Bits + 6 Kommando-Bits + 12 Adress-Bits
3
Start-Bit       3488µs Puls, 3488µs Pause
4
0-Bit           872µs Puls, 872µs Pause
5
1-Bit           872µs Puls, 2616µs Pause
6
Stop-Bit        872µs Puls

> Sendet IRSND unsauber, was das Timing anbetrifft, oder liegt es an
> IRremoteESP8266?

Wenn ich unter Linux den Output von IRSND in den IRMP per Pipe 
"reinschicke", sieht das ganz korrekt aus:
1
./irsnd-15kHz 04 0AB0 054F | ./irmp-15kHz
2
3
111100101010000011010101 p= 4 (MATSUSH), a=0x0ab0, c=0x054f, f=0x00

Es kann natürlich sein, dass die Timings etwas abweichen. Ich persönlich 
habe die Timings damals vermutlich empirisch aus mir zugesandten 
IRMP-Scans per IRMP_LOGGING=1 gewonnen. Genau weiß ich es nicht mehr, 
ist zu lange her.

Wie Jörg bereits fragte: Funktioniert denn IRSND -> Thomson TV?

Außerdem könntest Du mir einen Scan Deiner Original-FB schicken. 
Genaueres findest Du unter IRMP_LOGGING im IRMP-Artikel.

: Bearbeitet durch Moderator
von Armin J. (arminj)


Lesenswert?

eku schrieb:
> ich versuche Interoperabilität zwischen IRMP auf einem AVR,
> IRremoteESP8266 (https://github.com/crankyoldgit/IRremoteESP826) auf
> einem ESP8266 mit Tasmota, einer lernbaren Universalfernbedienung und
> der FB meines Thomson TV herzustellen.
Ist das Zufall oder warum bekomme ich bei dem Link ein 404?

eku schrieb:
> Sendet IRSND unsauber, was das Timing anbetrifft, oder liegt es an
> IRremoteESP8266?
IRremote hat eine seeeeehr schlechte Dekodierung, die Issues sind voll 
davon.
Nimm einfach die Arduino IRMP https://github.com/ukw100/IRMP, die gibt 
es für avr,esp8266,esp32,STM32,stm32,stm32duino,samd,apollo3.

von Jörg R. (jrie)


Lesenswert?

Armin J. schrieb:
> warum bekomme ich bei dem Link ein 404?

Da fehlt die zweite 6 am Ende.

von eku (Gast)


Lesenswert?

Armin J. schrieb:
> IRremote hat eine seeeeehr schlechte Dekodierung, die Issues sind voll
> davon.
> Nimm einfach die Arduino IRMP https://github.com/ukw100/IRMP, die gibt
> es für avr,esp8266,esp32,STM32,stm32,stm32duino,samd,apollo3.

Gut gemeinter Rat. Ich verwende, wie geschrieben, Tasmota. Freilich 
könnte ich versuchen, das Projekt zu einem Umstieg zu bewegen oder einen 
PR dafür einzureichen. Allerdings bin ich bei Tasmota nur Anwender und 
habe kein weiteres Wissen der Struktur und Arduino ist nicht meine 
Domäne.

von Armin J. (arminj)


Lesenswert?

eku schrieb:
> Allerdings bin ich bei Tasmota nur Anwender und
> habe kein weiteres Wissen der Struktur und Arduino ist nicht meine
> Domäne.
Danke, der Zusammenhang zwischen Tasmota und IRremote war mir gar nicht 
klar.

Und auf dem AVR machst du IRMP nativ? Das ist mutig, ich hab mir das 
nicht angetan.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Hi, gibt's irgendwo nen Link auf die aktuellen IRMP-Quellen? AVR, 
non-Arduino?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Hi, gibt's irgendwo nen Link auf die aktuellen IRMP-Quellen? AVR,
> non-Arduino?

IRMP: Download

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

hmmm... Danke ersma

Ich dachte es wäre ein Projekt for AVRs?  Das Makefile baut aber nur 
Programme für den Host / PC?

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Ich dachte es wäre ein Projekt for AVRs?  Das Makefile baut aber nur
> Programme für den Host / PC?

Das Makefile ist für den Analyzer unter LINUX.

IRMP läuft auf AVR, XMega, PIC, STM32, STM8, TI, ESP und diversen 
ARM Cortex.

Um das Projekt für AVR zu bauen, müsstest Du schon ein paar Blicke in 
den Artikel IRMP werfen, insbesondere in das Kapitel 
IRMP: Source-Code.

Zitat:
------------------------- Schnipp -----------------------
Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man 
unter Windows die Projekt-Datei irmp.aps in das AVR Studio 4 lädt.

Für andere Entwicklungsumgebungen ist leicht ein Projekt bzw. Makefile 
angelegt. Zum Source gehören:

    irmp.c - Der eigentliche IR-Decoder
    irmpprotocols.h - Sämtliche Definitionen zu den IR-Protokollen
    irmpsystem.h - Vom Zielsystem abhängige Definitionen für 
AVR/PIC/STM32
    irmp.h - Include-Datei für die Applikation
    irmpconfig.h - Anzupassende Konfigurationsdatei
------------------------- Schnapp -----------------------

Beachte auch bitte die Hinweise zu den Konfigurationsparametern: 
IRMP: Konfiguration

: Bearbeitet durch Moderator
von eku (Gast)


Lesenswert?

Armin J. schrieb:
> Und auf dem AVR machst du IRMP nativ? Das ist mutig, ich hab mir das
> nicht angetan.

Von mir stammt sogar die Integration in Ethersex (www.ethersex.de, 
https://github.com/ethersex/ethersex).

von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Armin J. schrieb:
> Und auf dem AVR machst du IRMP nativ? Das ist mutig, ich hab mir das
> nicht angetan.

das war easy, vielleicht einfacher als ich meinen ersten nativen AVR 
Timer zur Camauslösung gebaut hatte irgendwann um 2007

achnee das war noch mit
/*                      RC5 Remote Receiver 
*/
/*              Author: Peter Dannegger 
*/

IRMP erst mit Timer2 2011
nachdem das Display 2x zu früh aufgab nie fertig gebaut

IRMP also erst in wordclock12h eingesetzt 2015

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Wie deaktiviert man denn ANALYZE, d.h. Anzeige der 01-Darstellung ohne 
die Anzeige der Protokoll-Parameter zu deaktivieren?

-UANALYZE hat keinen Effekt, und -DANALYZE=0 führt zu Fehlern...

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Die Version 3.2.0 ist online.

Neuerungen:

- 22.06.2020: Unterstützung von 433MHz Funkprotokollen (RF)
- 22.06.2020: "Neues Protokoll:" RF_GEN24
- 22.06.2020: "Neues Protokoll:" RF_X10

Das generische Protokoll RF_GEN24 wird von vielen Handfernbedienungen 
für Funsteckdosen und Garagentoröffnern verwendet, z.B. Pollin 550666. 
Ich habe da noch mindestens drei andere Fernbedienungen gefunden, die 
dasselbe Protokoll verwenden.

Das Protokoll RF_X10 wird von einer PC-Funkfernbedienung verwendet, die 
ebenso bei Pollin unter der Bestellnr. 721815 erhältlich ist und 
ursprünglich von Medion stammt. Mit über 40 Tasten und sogar einem 
Rollrad ist sie vielseitig einsetzbar, z.B. um damit Funkbrücken zu 
IRSND (in einem anderen Raum) zu bauen - oder ähnliches. Kosten: 
Schlappe 75 Cent.

Da die 433 MHz Funkempfänger im Gegensatz zu den IR-TSOPs mit aktivem 
High-Pegel arbeiten, gibt es in irmpconfig.h dafür eine neue 
Konfigurationsvariable:
1
#define IRMP_HIGH_ACTIVE 0

Diese ist für Funkempfänger auf 1 zu ändern. Für IR-Anwendungen ändert 
sich nichts.

Die Software wurde im Artikel aktualisiert, die entsprechenden Stellen 
bzgl. Funktionsumfang und Konfiguration wurde angepasst. Im Laufe dieser 
Woche werde ich noch ein paar Bilder von diversen Funkfernbedienungen 
einstellen und auch noch ein neues Kapitel zu geeigneten Empfängern 
hinzufügen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Wie deaktiviert man denn ANALYZE, d.h. Anzeige der 01-Darstellung
> ohne die Anzeige der Protokoll-Parameter zu deaktivieren?
>
> -UANALYZE hat keinen Effekt, und -DANALYZE=0 führt zu Fehlern...

Redest Du jetzt von der Host-Version oder von der AVR-Version?

AVR: ANALYZE-Ausgaben überhaupt nicht sinnvoll, schon gar nicht in einer 
ISR. Hier könnte man addr, cmd, flags aber nach irmp_get_data() in der 
main-Funktion ausgeben - auch den Protokollnamen, wenn gewünscht.

Host: ANALYZE wird hier in irmpsystem.h gesetzt, nämlich für Windows und 
Linux.

Wenn ich es richtig verstehe, möchtest Du die 01-Ausgaben unterdrücken, 
die Protokoll-Daten (addr, cmd, flags) aber ausgeben? Da wird im Code 
jedoch nicht unterschieden. Man könnte noch ein ANALYZE-Level oder eine 
Maske implementieren, um bestimmte ANALYZE-Ausgaben auszumaskieren.

Bisher bin ich allerdings der Einzige, der irmp überhaupt auf einem Host 
nutzt. Von daher habe ich mir über solche Ideen überhaupt keine Gedanken 
gemacht.

Was hast Du denn vor?

P.S.
Workaround:
1
./irmp-10kHz <IR-Data/nec.txt | sed 's/.*\(p=\)/\1/g'

: Bearbeitet durch Moderator
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Von der AVR-Variante.  Da sieht die Ausgabe z.B. aus wie unten; mit 
würde ersma die Ausgabe der oberen Zeile genügen.

Momentan stellt sich die Ausgabe auf einem Terminal so dar:
1
protocol: 0x02   NEC   address: 0xEF00   command: 0x0003   flags: 0x01
2
00000000000000000000000000000000000000000000000000000000000000000000000000000000
3
00000000000000000000000000000000000000000000000000000000111111111111111111111111
4
11111111111111111111111111111111111111111000000000011111110000000000111111100000
5
00001111111000000000011111110000000000111111100000000001111110000000000111111100
6
00000000111111100000000001111111111111111111111110000000001111111111111111111111
7
11000000000011111111111111111111111000000000011111111111111111111111100000000001
8
11111000000000011111111111111111111111110000000001111111111111111111111110000000
9
00111111111111111111111111000000000011111111111111111111111100000000011111111111
10
11111111111110000000000111111100000000011111110000000000111111100000000001111111
11
00000000001111110000000000111111100000000001111111000000000011111110000000000111
12
11111111111111111111100000000011111111111111111111111100000000001111111111111111
13
11111110000000000111111111111111111111111000000000111111111111111111111111000000
14
00001111111111111111111111100000000001111111111111111111111111111111111111111111
15
11111111111111111111111111111111111111111111111111111111111111111111111111111111
16
11111111111111111111111111111111111111111111111111111111111111111111111111111111
17
11111111111111111111111111111111111111111111111111111111111111111111111111111111
18
11111111111111111111111111111111111111111111111111111111111111111111111111111111
19
11111111111111111111111111111111111111111111111111111111111111111111111111111111
20
11111111111111111111111111111111111111111111111111111111111111111111111111111111
21
11111111111111111111111111111111111111111111111111111111111111111111111111111111
22
11111110000000000000000000000000000000000000000000000000000000000000000000000000
23
00000000000000000000000000000000000000000000000000000000000000111111111111111111
24
11111111111111000000000011111111111111111111
25
                                            00011111111111111111111
26
                                                                   0000111111111
27
11111111111
28
           0000011111111111111111111
29
                                    00011111111111111111111
30
                                                           000111111111111111111
31
11
32
  00011111111111111111111
33
                         00011111111111111111111
34
                                                00011111111111111111111
35
                                                                       000111111
36
11111111111111
37
              00011111111111111111111
38
                                     00011111111111111111111
39
                                                            00001111111111111111
40
1111
41
    00011111111111111111111

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> - 22.06.2020: Unterstützung von 433MHz Funkprotokollen (RF)

das ist hochinteressant, hat du Kenntnis über die Marmitek IR 
Transmitter?
https://www.reichelt.de/marmitek-ir-funkuebertragungssystem-marmitek-08900-p50081.html

Ich habe davon einige im Einsatz, auch eine alte Marmitek FB die sendet 
aber mittlerweile zu wenig Platz für Codes hat.

Ein Sendemodul in eine FB zu integrieren wäre klasse.

Ich weiss aber immer noch nicht ob die auf 433 MHz senden oder 866/868 
MHz

Die Stabantenne ist bei einem RF Empfänger 17 cm also sieht nach 433MHz 
aus und beim anderen 30cm keine Ahnung.

Natürlich kann eine Stabantenne Lambda/4 oder abweichend haben, entweder 
mit Verlängerungsspule oder Verkürzungskondensator, ich habe die noch 
nicht zerlegt.

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> AVR: ANALYZE-Ausgaben überhaupt nicht sinnvoll, schon gar nicht in einer
> ISR.

Keine Ahnung wo Du das ausgibst, ich hab's aktiviert um rauszufinden, 
welches Protokoll überhaupt verwendet wird von dem Bleil-Schrott den ich 
mir da gekauft habe...

Compiliert hab ich mit
1
-DIRMP_LOGGING -DIRMP_PROTOCOL_NAMES -DF_CPU=22118400UL -DBAUD=19200UL

Übrigens wird BAUD im Code 2× hart codiert; ich musste das 
auskommentieren um die Baudrate von Kommandozeile aus setzen zu können.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Von der AVR-Variante.

Lösung: Auf AVR die lediglich für Debugging-Zwecke gedachte Konstante 
ANALYZE nicht verwenden, sondern einfach in main() schreiben:
1
   IRMP_DATA irmp_data;
2
3
   while (1)
4
   {
5
       if (irmp_get_data (&irmp_data))
6
       {
7
            printf ("p=%2d a=0x%04x c=0x%04x f=0x%x\n",
8
                    irmp_data.protocol,
9
                    irmp_data.address,
10
                    irmp_data.command,
11
                    irmp_data.flags);
12
       }
13
    }

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Keine Ahnung wo Du das ausgibst, ich hab's aktiviert um rauszufinden,
> welches Protokoll überhaupt verwendet wird von dem Bleil-Schrott den ich
> mir da gekauft habe...

Siehe Beispiel aus meinem Beitrag obendrüber.

> Compiliert hab ich mit -DIRMP_LOGGING -DIRMP_PROTOCOL_NAMES
> -DF_CPU=22118400UL -DBAUD=19200UL

Wenn Du den Protokollnamen auch noch ausgeben möchtest, dann ändert sich 
das obige printf() zu:
1
            printf ("p=%2d n=%s a=0x%04x c=0x%04x f=0x%x\n",
2
                    irmp_data.protocol,
3
                    irmp_protocol_names[irmp_data.protocol],
4
                    irmp_data.address,
5
                    irmp_data.command,
6
                    irmp_data.flags);

> Übrigens wird BAUD im Code 2× hart codiert; ich musste das
> auskommentieren um die Baudrate von Kommandozeile aus setzen zu können.

Danke, schaue ich mir an.

: Bearbeitet durch Moderator
Beitrag #6312104 wurde vom Autor gelöscht.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Compiliert hab ich mit -DIRMP_LOGGING -DIRMP_PROTOCOL_NAMES
> -DF_CPU=22118400UL -DBAUD=19200UL

Wirf -DIRMP_LOGGING noch raus, das protokolliert jeden Pegelwechsel. 
Brauchst Du aber nicht. Die LOGGING-Routinen sind dafür da, um aus den 
IR-Frames Samples auf der Console zu erstellen.

Jetzt weiß ich auch, warum bei Dir 2x BAUD definiert ist. Du benutzt 
sowohl die UART-LOGGING-Routinen aus irmp.c als auch die aus 
irmp-main-avr-uart.c. Das passt natürlich nicht.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Bleil-Schrott

Habs jetzt im Artikel gelesen. ;-)

Ja, das sind billigste Fernbedienungen, die man für 50 Cent beim 
Chinesen um die Ecke nachkaufen kann. Die verwenden alle durch die Bank 
das NEC-Protokoll mit derselben Adresse 0xFE00. Suchst Du da nach einer 
Alternative oder möchtest da selber eine bauen?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> das ist hochinteressant, hat du Kenntnis über die Marmitek IR
> Transmitter?

Nein.

> Ich habe davon einige im Einsatz, auch eine alte Marmitek FB die sendet
> aber mittlerweile zu wenig Platz für Codes hat.

Was heisst das? Ist das eine IR-FB oder eine RF-FB? Wieviele Codes 
brauchst Du denn bzw. was machst Du damit? IR empfangen, RF übertragen 
und dann wieder als IR ausgeben?

> Ein Sendemodul in eine FB zu integrieren wäre klasse.

Ein RF-Sendemodul? Ich habe mittlerweile auch IRSND prototypisch mit 
einem RF-Sender ausgestattet, die Veröffentlichung eines neuen 
IRSND-Releases dauert aber noch etwas. Vorher muss ich noch die 
Abschaltung der IR-Modulation parametrisieren, damit man das allgemein 
verwenden kann.

> Ich weiss aber immer noch nicht ob die auf 433 MHz senden oder 866/868
> MHz

Steht im Datenblatt bei Reichelt: Frequency  433.92 MHz.

Schau Dir mal https://www.pollin.de/p/pc-funkfernbedienung-x10-721815 
an. Diese Funkfernbedienung hat über 40 Tasten und kann von IRMP 
dekodiert werden. Per IRSND könntest Du dann wieder IR-Signale für das 
Endgerät (TV o.ä.) generieren.

: Bearbeitet durch Moderator
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Johann L. schrieb:
>> Bleil-Schrott
>
> Habs jetzt im Artikel gelesen. ;-)
>
> Ja, das sind billigste Fernbedienungen, die man für 50 Cent beim
> Chinesen um die Ecke nachkaufen kann. Die verwenden alle durch die Bank
> das NEC-Protokoll mit derselben Adresse 0xFE00. Suchst Du da nach einer
> Alternative oder möchtest da selber eine bauen?

Nach ca. 2 Wochen hat das Ding rumgesponnen um nur noch grell türkis zu 
leuchten no matter what.  Erneuerung der Betterie der Fernbedienung 
brachte nix, und als ich das Steuermodul aufgeschraut hatte sah ich dass 
ein Transistor offenbar einen auf Geysir gemacht hatte.

Ergo: Die Fernbedienung will ich weiter verwenden aber ein neues 
Steuermodul bauen, mit richtig dimensionierten FETs und mit höherer 
PWM-Frequenz so dass die LED-Streifen nicht mehr (merklich) flackern, 
also > 200 Hz oder so.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Die Fernbedienung will ich weiter verwenden aber ein neues Steuermodul
> bauen

Danke für die Info. Läuft der IRMP denn nun bei Dir wunschgemäß? Sollten 
noch Probleme auftreten, melde Dich einfach.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Johann L. schrieb:
>> Die Fernbedienung will ich weiter verwenden aber ein neues Steuermodul
>> bauen
>
> Danke für die Info. Läuft der IRMP denn nun bei Dir wunschgemäß? Sollten
> noch Probleme auftreten, melde Dich einfach.

War easy zum Laufen zu bringen, und NEC-Protokoll (0x2) wird auch 
erkannt; RC5 allerdings nicht, z.B.
1
00000000000000011111111111100000000000000111111111111000000000000000000000000000
2
00111111111111000000000000001111111111110000000000000001111111111110000000000000
3
00111111111110000000000000001111111111110000000000000001111111111110000000000000
4
01111111111110000000000000001111111111110000000000000001111111111110000000000000
5
0111111111111111111111111100000000000000011111111111111111111

ATmega168 @ 22.1184 MHz

...und was etwas nervig ist sind die überlangen Code-Zeilen in den 
Quellen.

: Bearbeitet durch User
von Joachim B. (jar)


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Nein.

schade

Frank M. schrieb:
> Was heisst das? Ist das eine IR-FB oder eine RF-FB? Wieviele Codes
> brauchst Du denn bzw. was machst Du damit? IR empfangen, RF übertragen
> und dann wieder als IR ausgeben?

genaugenommen habe ich 2

1.
https://cdn-reichelt.de/documents/datenblatt/X600/Powermid_XL.pdf

die konnte eh zu wenig Code lernen und speichern, schon nach der Hälfte 
der angelernten Tasten war der Speicher voll.

2. dito
https://www.bedienungsanleitu.ng/thumbs/products/l/84244-marmitek-easy-icon-10-rf.jpg
Trotz toller Multiauswahl mit Display, nach nur einer FB mit halben 
Tastencodes war Schluß.

Beide lernen IR und senden IR und RF, die Empfänger im Wohnzimmer senden 
dann IR an die Video/DVD Recorder, || Pause, > Play, << fast rewind, >> 
fast wind, STOP.

Frank M. schrieb:
> Steht im Datenblatt bei Reichelt: Frequency  433.92 MHz.

wozu dann 30cm Antenne, ach egal!

Frank M. schrieb:
> Schau Dir mal https://www.pollin.de/p/pc-funkfernbedienung-x10-721815
> an.

gerne, nur wie hoch ist deren Speicher?
Ich bin ja was Speichertiefe bei beiden Marmitek reingefallen, wenn die 
nicht mal Platz für alle eigenen Tasten Codes aufnehmen?
Ich verlange ja nicht mal das mehr Tasten etwa soviel wie die 
angelernten FB benutzt werden können als die RF FB besitzt, aber 
mindestens die sollten doch belegt werden können.

Bis jetzt habe ich mir den Bau eines IRSND sparen können, weil ich 
daheim gerne die Pyramiden nutze, soll ja nicht eine never ending 
Bastelstunde werden ohne Gehäuse wie meine 433 MHz Rolladen 
Fernbedienungen vom nano.

v1 2015
https://www.mikrocontroller.net/attachment/276364/rolladen.jpg

v2 2017 Anhang Bild

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> Frank M. schrieb:
>> Schau Dir mal https://www.pollin.de/p/pc-funkfernbedienung-x10-721815
>> an.
>
> gerne, nur wie hoch ist deren Speicher?

Die hat gar keinen, sie ist nicht anlernbar. Die Intelligenz müsstest Du 
schon in IRMP (empfangen der Funksignale) und anschließendem Senden per 
IRSND reinstecken. Gewiss sollte da der Speicher eines entsprechenden 
AVR-µCs ausreichen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> War easy zum Laufen zu bringen, und NEC-Protokoll (0x2) wird auch
> erkannt; RC5 allerdings nicht,

Das wundert mich aber, das ist eines der bestgetesteten Protokolle. Du 
hast RC5 auch in irmpconfig.h freigeschaltet?

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Die hat gar keinen,

also nur ein FB Gehäuse?
Das verstehe ich gerade nicht!

der Link funktioniert nicht
 Verfügbare Downloads:
    Download Beschreibung

am raspi ging es!

egal aber heftig
2,25 € 3 Stk
5,95 € Versandkosten
----
8,20€

bestellt, nun erst mal lesen!

"Ist der Funkkanal des Empfängers bekannt, stellen Sie die Fernbedienung 
wie unten beschrieben auf den entsprechenden
Funkkanal ein.
1. SELECT-Taste drücken bis die LED erlischt (ca. 5 Sekunden).
2. Die Häufigkeit des LED-Blinkens entspricht dem eingestellten Kanal 
(1...16)
3. Die LED leuchtet nach dem Blinken dauerhaft - ein neuer Kanal kann 
jetzt vergeben werden
4. Zum Ändern des Kanals die gewünschte Kanalnummer mit der 
Fernbedienungstastatur eingeben (1...16)
und mit der SELECT-Taste bestätigen.
5. Die LED blinkt erneut in der Häufigkeit des neu eingestellten Kanals
6. Der gewünschte Kanal ist jetzt aktiv - die Fernbedienung kann 
verwendet werden

Ich verstehe immer noch Bahnhof....
Ein AVR mit IRSND hat keinen Funkempfänger, ein Nano keinen Port für USB
Kanäle muss ich in der FB vergeben?

Wie soll denn mit IRSND eine RF IR Brücke werden?

: Bearbeitet durch User
von Klaus R. (klaus2)


Lesenswert?

Joachim B. schrieb:
> also nur ein FB Gehäuse?
> Das verstehe ich gerade nicht!

Nein. Eine FB die statt IR 433MHz nutzt. Das Protokoll kennt irmp und 
das wars. Den 433MHz Empfänger brauchste noch...

Klaus.

von Klaus R. (klaus2)


Lesenswert?

Joachim B. schrieb:
> Wie soll denn mit IRSND eine RF IR Brücke werden?

Ich denke schon länger eher über einen BT -> IR / RF Hub 
nach...allerdings sind die Protokolle meiner Funksteckdose eher komplex 
und ne SCHÖNE BT app braucht auch Zeit. Dann wär endlich alles übers 
smartphone Bedienbar und die FB immer "dabei".

Gibts da schon ein Projekt?

Klaus.

von Joachim B. (jar)


Lesenswert?

Klaus R. schrieb:
> Den 433MHz Empfänger brauchste noch...
>
> Klaus.

also sowas:
https://www.ebay.de/i/173291278318
die einzigen Empfänger die was taugen, jedenfalls bei mir.
Mit den Sendern:
Ebay-Artikel Nr. 232682854622
kann man ja arbeiten, die nutze ich selber, die dazugehörigen Empfänger 
sind für den Elektronik Schrott!

Ebay-Artikel Nr. 253065971465
gerade bestellt, meine anderen liegen in der Werkstatt!

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> Frank M. schrieb:
> Die hat gar keinen,
>
> also nur ein FB Gehäuse?
> Das verstehe ich gerade nicht!

Ich meinte: Die FB hat keine Möglichkeit, etwas anzulernen. Die Codes, 
die sie absendet, sind fix.

> "Ist der Funkkanal des Empfängers bekannt, stellen Sie die Fernbedienung
> wie unten beschrieben auf den entsprechenden
> Funkkanal ein.

Brauchst Du nicht zu machen, die Dinger funktionieren out-of-the-box. 
Einfach Batterien rein und fertig.

> Wie soll denn mit IRSND eine RF IR Brücke werden?

RF-Sender -----> RF-Empfänger -----> IR-Sender -------> TV

Den RF-Empfänger und IR-Sender packst Du mittels IRMP/IRSND auf einen 
µC.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:

> also sowas:
> https://www.ebay.de/i/173291278318

Jepp, die RXB6-Module (Stichwort Superheterodyne) sind ganz gut, vor 
allem sind sie trennschärfer als die Pendelaudion-Empfänger, welche auch 
den ganzen Müll mit aufsaugen. Allerdings haben sie einen kleinen 
Nachteil: Sie verschlucken meist die ersten ein bis zwei Bits vom ersten 
gesandten Frame. Es dauert wohl ein wenig, bis sie sich eingeschossen 
haben. Macht aber nichts: Alle RF-Sender, die ich kenne, wiederholen die 
Daten ständig, solange Du den Finger auf dem Knopf hältst. Der zweite 
Frame wird dann von IRMP einwandfrei erkannt.

> Mit den Sendern:
> Ebay-Artikel Nr. 232682854622
> kann man ja arbeiten, die nutze ich selber, die dazugehörigen Empfänger
> sind für den Elektronik Schrott!

Ja, das sind die Pendelaudion-Empfänger, die sehr störanfällig sind. 
Allerdings verschlucken sie keine Daten wie die RXB6. IRMP wird durch 
die vielen Störimpulse zwar etwas mehr beschäftigt, kann aber bereits 
den ersten Frame sauber erkennen. Die Decodierung ist hier also ein 
wenig schneller.

Insgesamt plädiere ich auch für die Superheterodyne-Empfänger. Muss aber 
nicht unbedingt ein RXB6 sein, die RXB8-Module sollen ähnlich gut sein, 
sind aber von mir noch ungetestet.

Ein Stück Draht von 17 cm Länge als Antenne hilft ungemein, wenn man 
mehr als nur 1-2 Meter überbrücken möchte.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> RC5 allerdings nicht,
> z.B.00000000000000011111111111100000000000000111111111111000000000000000 
000000000000
> 001111111111110000000000000011111111111100000000000000011111111111100000 
00000000
> 001111111111100000000000000011111111111100000000000000011111111111100000 
00000000
> 011111111111100000000000000011111111111100000000000000011111111111100000 
00000000
> 0111111111111111111111111100000000000000011111111111111111111
>

Ich habe gerade mal die obigen Daten in einer Text-Datei "d.txt" 
gespeichert und irmp drüber laufen lassen:
1
./irmp-15kHz < d.txt
2
1100000000001 p= 7 (RC5), a=0x0000, c=0x0001, f=0x00

Dein RC5-Frame wird also einwandfrei erkannt. Ich kann mir da nur zwei 
Konstellationen vorstellen:

1. RC5 ist nicht freigeschaltet in irmpconfig.h

2. Du hast noch weitere Protokolle freigeschaltet, wobei eines der 
anderen bzgl. Startbit als Kriterium zur Protokollauswahl in Konflikt 
mit RC5 steht.

Mir ist allerdings kein anderes Protokoll aus dem Kopf bekannt, welches 
mit RC5 bzgl. Startbit kollidiert. Hier wäre interessant zu wissen, 
welche IR-Protokolle Du in irmpconfig.h freigeschaltet hast.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Klaus R. schrieb:
> Ich denke schon länger eher über einen BT -> IR / RF Hub
> nach...allerdings sind die Protokolle meiner Funksteckdose eher komplex
> und ne SCHÖNE BT app braucht auch Zeit. Dann wär endlich alles übers
> smartphone Bedienbar und die FB immer "dabei".
>
> Gibts da schon ein Projekt?

Ich habe so etwas mal gemacht vor 5 Jahren:

https://www.mikrocontroller.net/articles/Remote_IRMP

Das Projekt könnte man nochmal aufleben lassen.

Zu den "komplexen RF-Protokollen" Deiner Funksteckdose: Du könntest mit 
dem aktuellen IRMP mal Samples erstellen.

Einen RF-Empfänger an den aktuellen IRMP und
1
#define IRMP_LOGGING     1
2
#define IRMP_HIGH_ACTIVE 1

einstellen und dann die gesampelten Frames per Terminalemulation (PuTTY) 
kopieren.

: Bearbeitet durch Moderator
von Johann L. (gjlayde) Benutzerseite


Angehängte Dateien:

Lesenswert?

Frank M. schrieb:
> Johann L. schrieb:
>> RC5 allerdings nicht,
>>
> z.B.00000000000000011111111111100000000000000111111111111000000000000000 
000000000000
>> 001111111111110000000000000011111111111100000000000000011111111111100000 
00000000
>> 001111111111100000000000000011111111111100000000000000011111111111100000 
00000000
>> 011111111111100000000000000011111111111100000000000000011111111111100000 
00000000
>> 0111111111111111111111111100000000000000011111111111111111111
>>
>
> Ich habe gerade mal die obigen Daten in einer Text-Datei "d.txt"
> gespeichert und irmp drüber laufen lassen:
1
> ./irmp-15kHz < d.txt
2
> 1100000000001 p= 7 (RC5), a=0x0000, c=0x0001, f=0x00
> Dein RC5-Frame wird also einwandfrei erkannt. Ich kann mir da nur zwei
> Konstellationen vorstellen:
>
> 1. RC5 ist nicht freigeschaltet in irmpconfig.h

Ich hab den default verwendet (bis auf BAUD), und da ist RC5 wohl nicht 
daber...

Nochwas zum Coding:

Die Variablen im Static Storage sind meist frei flottierende 8-Bit, 
16-Bit oder 32-Bit Werte.  Fasst man dieser zu einer Struktur zusammen 
und greift indirekt darauf zu, kann man einiges an Code(größe) sparen 
ohne den Code langsamer zu machen.

Beispiel für AVR ATmega168 mit allen Protokollen aktiviert (und Warings 
ignoriert):

Direkter Zugriff: 8256 Bytes
Indirekt Zugriff: 6964 Bytes (85% Codegröße)

Aktiviere ich nur NEC, das Protokoll auf das ich's abgesehen hab, dann:

Direkter Zugriff: 1978 Bytes
Indirekt Zugriff: 1656 Bytes (84% Codegröße)

Compiliert mit avr-gcc-v8 -Os (ohne LTO).

Anbei ein Delta, welches das Prinzip zeigt.

Zugriff ist:
1
    irmp_t *ir = &irmp;
2
    __asm ("" : "+r" (ir));
3
4
    if (ir->ir_detected)
5
    {
6
        switch (ir->protocol)
7
        ...
etc. anstatt auf irmp_protocol im Original

Das __asm dient dazu, die Adresse von irmp vor GCC zu verstecken. 
Kommentiert man das __asm aus, etwa per
1
#define __asm(...) (void) 0
so steigt die Codegröße auf den Wert für (direkter Zugriff) weil GCC 
trotz indirekter Adressierung die Adresse kenn (bzw. Offset auf Symbol 
irmp ).

_______________

Und es gibt ganz viele Codestellen ähnlich der folgenden:
1
#ifdef ANALYZE
2
                    ANALYZE_PRINTF("Info IR60: got start instruction frame\n");
3
#endif // ANALYZE
wobei
1
#ifdef ANALYZE
2
...
3
#  define ANALYZE_PRINTF(...)                   { if (verbose)              { printf (__VA_ARGS__); } }
4
...
5
#else
6
...
7
#  define ANALYZE_PRINTF(...)
8
...
9
#endif

Man könnte den Code alse etwas kompakter schreiben, indem man das #ifdef 
ANALYZE einfach rauswirft.

Je nach Code kann das Warnings geben, etwa wenn die einzige Verwendung 
einer (lokalen) Variablen als Argument von ANALYZE_PRINTF ist.  In dem 
Fall kann man folgendes machen:
1
#ifdef ANALYZE
2
static const bool analyze = true;
3
#else
4
static const bool analyze = false;
5
#endif
6
7
#define ANALYZE_PRINTF(...) \
8
    do { \
9
       if (analyze) if (verbose) printf (__VA_ARGS__); } \
10
    while (0)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Zugriff ist:    irmp_t *ir = &irmp;

Danke erstmal für den Tipp.

> Das __asm dient dazu, die Adresse von irmp vor GCC zu verstecken.
> Kommentiert man das __asm aus, etwa per#define __asm(...) (void) 0
> so steigt die Codegröße auf den Wert für (direkter Zugriff) weil GCC
> trotz indirekter Adressierung die Adresse kenn (bzw. Offset auf Symbol
> irmp ).

Das klappt dann aber nur für avr-gcc. Für die anderen µCs lasse ich dann 
das asm-Statement weg - wobei dann für diese µCs nichts gewonnen ist, 
richtig?

> Man könnte den Code alse etwas kompakter schreiben, indem man das #ifdef
> ANALYZE einfach rauswirft.

Genau das_ hatte ich vorher genau _so gemacht, nämlich so:
1
#else
2
#  define ANALYZE_PUTCHAR(a)
3
#  define ANALYZE_ONLY_NORMAL_PUTCHAR(a)
4
#  define ANALYZE_PRINTF(...)
5
#  define ANALYZE_ONLY_NORMAL_PRINTF(...)
6
#  define ANALYZE_NEWLINE()

Dann konnte man einfach schreiben:
1
   ...
2
   analyze_printf (foo, bar);
3
   ...

Du findest diese leeren Macros sogar noch in irmp.c, aber nur nur noch 
in auskommentierter Form:
1
/*******************************                not every C compiler knows variadic macros :-(
2
#else
3
#  define ANALYZE_PUTCHAR(a)
4
#  define ANALYZE_ONLY_NORMAL_PUTCHAR(a)
5
#  define ANALYZE_PRINTF(...)
6
#  define ANALYZE_ONLY_NORMAL_PRINTF(...)
7
#  endif
8
#  define ANALYZE_NEWLINE()
9
*********************************/
10
#endif

Das Problem: Nicht jeder Compiler kennt Variadic Macros, z.B. der 
PIC-Compiler. Aus diesem Grund hatte ich dann nachträglich alle Aufrufe 
von irgendwelchen analyze_printf() nochmal durch diese wirklich 
unschönen Blöcke
1
#ifdef ANALYZE
2
   analyze_printf (foo, bar);
3
#endif // ANALYZE
zusätzlich gekapselt, was den Source dann richtig hässlich macht.

Sag mir, wie ich das durch einen NON-gcc in der Variante, dass ANALYZE 
"#undefed" ist, bekomme und ich machs - sogar sehr gern.

P.S.
Beispiel: Der PIC-Compiler XC8 kann "nur" C89, Variadic Macros gibt es 
erst ab C99.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Ich habe hier

  https://stackoverflow.com/questions/27663053/variadic-macros-alternative-in-ansi-c

eine Alternative zu Variadic Macros gefunden, die auch mit C89-Dialekt 
funktioniert:
1
#ifdef ANALYZE
2
#define analyze_printf(args)        printf args
3
#else
4
#define analyze_printf(args)        (void) args
5
#endif

Der Aufruf eines solchen Makros müsste dann immer mit Doppelklammern 
erfolgen, also:
1
    analyze_printf ((foo, bar));

Das wäre aber nicht dramatisch.

Wer hat einen XC8-Compiler für PIC und möchte das mal mit mir zusammen 
testen? Ich würde dann eine modifizierte Variante von irmp.c zur 
Verfügung stellten.

Ziel ist es, diese analyze_printf() -Aufrufe samt Evaluierung aller 
Argumente vom Compiler komplett eliminieren zu lassen. Ich hoffe, dass 
der nicht gerade durch "Intelligenz" bestechende XC8 das packt. Nicht, 
dass er die Parameter noch ausrechnet oder gar Stringkonstanten im Flash 
hinterlegt, obwohl sie dann gar nicht genutzt werden.

EDIT:
Alternative wäre, in die Steinzeit zurückzugehen, und für jede 
verschiedene Anzahl von Argumenten ein eigenes analyze_printf() zu 
bauen, also
1
#define analyze_printf1(fmt)     printf(fmt)
2
#define analyze_printf2(fmt,a)   printf(fmt,a)
3
#define analyze_printf3(fmt,a,b) printf(fmt,a,b)
4
usw.

Aber schön ist das nicht, zumindest auf dem Host (Linux, Windows) könnte 
man die Variadic Macros bzw. die oben skizzierte Alternative durchaus 
nutzen.

: Bearbeitet durch Moderator
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Johann L. schrieb:
>> Zugriff ist:    irmp_t *ir = &irmp;
>
> Danke erstmal für den Tipp.
>
>> Das __asm dient dazu, die Adresse von irmp vor GCC zu verstecken.
>> Kommentiert man das __asm aus, etwa per#define __asm(...) (void) 0
>> so steigt die Codegröße auf den Wert für (direkter Zugriff) weil GCC
>> trotz indirekter Adressierung die Adresse kenn (bzw. Offset auf Symbol
>> irmp ).
>
> Das klappt dann aber nur für avr-gcc. Für die anderen µCs lasse ich dann
> das asm-Statement weg - wobei dann für diese µCs nichts gewonnen ist,
> richtig?

Ich glaub nicht dass das für andere µCs was bringt.  Je nachdem wie 
schlecht der Compiler optimiert könnte es sogar kontraproduktiv sein.

>> Man könnte den Code also etwas kompakter schreiben, indem man das #ifdef
>> ANALYZE einfach rauswirft.
> [...]
> Das Problem: Nicht jeder Compiler kennt Variadic Macros, z.B. der
> PIC-Compiler.

> Sag mir, wie ich das durch einen NON-gcc in der Variante, dass ANALYZE
> "#undefed" ist, bekomme und ich machs - sogar sehr gern.

Evtl. so? Braucht dann auch keine 2fach-Klammerung, ist allerdings nur 
ein "normales" Makro, kein function-like:
1
#ifdef ANALYZE
2
#define analyze_printf printf
3
#else
4
#define analyze_printf (void)
5
#endif // ANALYZE

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Nochwas: Kann man irgendwie Platz sparen, wenn nur 1 Protokoll genbaucht 
wird und dieses zur Compilezeit bekannt ist? In irmp_ISR() gibt's ja 
folgendes:
1
    if (ir->isr.start_bit_detected)
2
    {
3
        memcpy_P (&irmp.param, irmp_param_p, sizeof (IRMP_PARAMETER));

Der Inhalt von irmp.param ändert sich also nicht (mehr) und ist zur 
Compilezeit bekannt weil irmp_param_p zur Compilezeit bekannt ist?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Ich glaub nicht dass das für andere µCs was bringt.  Je nachdem wie
> schlecht der Compiler optimiert könnte es sogar kontraproduktiv sein.

Hm, dann ist es wohl nicht sinnvoll, wenn ich allgemein auf
1
    irmp_t *ir = &irmp;

umstelle. Zwei unterschiedliche Schreibweisen im gleichen Source machen 
den Code dann noch unansehlicher. Ich könnte mir da höchstens einen 
Trick per Preprocessor-Makro vorstellen. Irgendwann besteht der Code aus 
mehr Preprocessor-Makros als aus C-Code ;-)

> Evtl. so? [...]
> #define analyze_printf (void)

Danke, das ist schön einfach und ohne Ecken und Kanten. Gefällt mir!

Ich habe es nun so gemacht:
1
#ifdef ANALYZE
2
#  define ANALYZE_PUTCHAR(a)               { if (! silent)             { putchar (a);          } }
3
#  define ANALYZE_ONLY_NORMAL_PUTCHAR(a)   { if (! silent && !verbose) { putchar (a);          } }
4
#  define ANALYZE_PRINTF(...)              { if (verbose)              { printf (__VA_ARGS__); } }
5
#  define ANALYZE_ONLY_NORMAL_PRINTF(...)  { if (! silent && !verbose) { printf (__VA_ARGS__); } }
6
#  define ANALYZE_NEWLINE()                { if (verbose)              { putchar ('\n');       } }
7
static int                                 silent;
8
static int                                 time_counter;
9
static int                                 verbose;
10
#else
11
#  define ANALYZE_PUTCHAR(a)
12
#  define ANALYZE_ONLY_NORMAL_PUTCHAR(a)
13
#if defined (__XC8)                        // XC8 does not support variadic macros
14
#  define ANALYZE_PRINTF                   (void)
15
#  define ANALYZE_ONLY_NORMAL_PRINTF       (void)
16
#else
17
#  define ANALYZE_PRINTF(...)
18
#  define ANALYZE_ONLY_NORMAL_PRINTF(...)
19
#endif
20
#  define ANALYZE_NEWLINE()
21
#endif

Meines Wissens nach ist XC8 der einzige Compiler, der "nur" C89. Sollten 
doch noch andere betroffen sein, kann man die ja noch anfügen.

Damit sind die Blöcke
1
#ifdef ANALYZE
2
...
3
#endif // ANALYZE
weggefallen und es konnten ca. 350 Zeilen eingespart werden :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Kann man irgendwie Platz sparen, wenn nur 1 Protokoll genbaucht wird und
> dieses zur Compilezeit bekannt ist?

Puh, um festzustellen, ob genau ein Protokoll aktiviert ist, müsste man 
alle IRMP_SUPPORT_XXX-Konstanten zusammenaddieren, also:
1
#if IRMP_SUPPORT_SIRCS_PROTOCOL     + \
2
    IRMP_SUPPORT_NEC_PROTOCOL       + \
3
    ...                             + \
4
    IRMP_SUPPORT_RF_X10_PROTOCOL == 1
5
#define IRMP_ONLY_ONE_PROTOCOL_USED 1
6
#else
7
#define IRMP_ONLY_ONE_PROTOCOL_USED 0
8
#endif
Heftig!

> In irmp_ISR() gibt's ja folgendes:
> if (ir->isr.start_bit_detected)
>     {
>         memcpy_P (&irmp.param, irmp_param_p, sizeof (IRMP_PARAMETER));
>
> Der Inhalt von irmp.param ändert sich also nicht (mehr) und ist zur
> Compilezeit bekannt weil irmp_param_p zur Compilezeit bekannt ist?

Ich mache übrigens den memcpy()-Call, um die anschließenden Zugriffe auf 
die Daten zu beschleunigen, da meiner Erfahrung nach ein Pointerzugriff 
im allgemeinen langsamer ist. Ich hätte nämlich hier auch einfach einen 
Pointer setzen können.

Meinst Du, der Aufwand rechtfertigt so etwas? Da kann man alternativ 
auch einen IRMP-Codegenerator schreiben, der einem den IRMP-Source aus 
der Konfiguration generiert. Der könnte dann auch µC-spezifisch 
optimiert werden, wie zum Beispiel Dein ir-Pointer für AVR. Auf die 
Preprocessor-Schlacht könnte man dann größtenteils verzichten.

: Bearbeitet durch Moderator
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Johann L. schrieb:
>> Kann man irgendwie Platz sparen, wenn nur 1 Protokoll gebraucht wird und
>> dieses zur Compilezeit bekannt ist?
>
> Puh, um festzustellen, ob genau ein Protokoll aktiviert ist, müsste man
> alle IRMP_SUPPORT_XXX-Konstanten zusammenaddieren, also:

Ich dachte eher an sowas: Ich weiß dass ich nur 1 Protokoll verwende 
und wollte fragen, was ich lokal bei mir ändern muss um (noch mehr) 
Platz zu sparen.

Wprd gerne nen ATtiny24 verwenden.  Der Code passt da zwar locker rein, 
aber es soll ja mehr auf den µC als IR-Auswertung...

>> In irmp_ISR() gibt's ja folgendes:
>> if (ir->isr.start_bit_detected)
>>     {
>>         memcpy_P (&irmp.param, irmp_param_p, sizeof (IRMP_PARAMETER));
>>
>> Der Inhalt von irmp.param ändert sich also nicht (mehr) und ist zur
>> Compilezeit bekannt weil irmp_param_p zur Compilezeit bekannt ist?
>
> Ich mache übrigens den memcpy()-Call, um die anschließenden Zugriffe auf
> die Daten zu beschleunigen, da meiner Erfahrung nach ein Pointerzugriff
> im allgemeinen langsamer ist. Ich hätte nämlich hier auch einfach einen
> Pointer setzen können.

irmp.param const zu machen funktioniert nicht, bzw. da werden wohl 
einige Werte gepatcht :-(

Verwenden würde ich __flash.  Das ist im Gegensatz zu pgm_read_xxx 
nämlich transparent: Zum Beispiel compiliert
1
typedef struct { int a, b, c; } abc_t;
2
3
const __flash abc_t abc = { 1234, 5678, 9012 }; 
4
5
int add (int x)
6
{
7
    const __flash abc_t *p = &abc;
8
    return x + p->b + 1;
9
}
zu:
1
add:
2
  subi r24,-47
3
  sbci r25,-23
4
  ret
d.h. der Wert muss zu Laufzeit garnicht mehr aus dem Flash geladen 
werden und kann in Immediates versacken wie hier.

> Meinst Du, der Aufwand rechtfertigt so etwas? Da kann man alternativ
> auch einen IRMP-Codegenerator schreiben, der einem den IRMP-Source aus
> der Konfiguration generiert.

Was dann freilich ein komplett neues Projekt wäre... Und nicht unbedingt 
übersichtlicher? Unterschiedliche Protokolle, unterschiedliche 
Controller / Hosts, unterschiedliche Compiler, ...

> Der könnte dann auch µC-spezifisch
> optimiert werden, wie zum Beispiel Dein ir-Pointer für AVR. Auf die
> Preprocessor-Schlacht könnte man dann größtenteils verzichten.

Ja, das würe es auf jeden Fall übersichtlicher machen. Und in welcher 
Sprache? Python?

von Joachim B. (jar)


Lesenswert?

Johann L. schrieb:
> Python?

ich bekomme Angst, wenn ich an die unterschiedliche Einrückung denke 
TABS SPACES, mal mehr mal weniger Python v2 v3?

neee Python NEVER

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Aktiviere ich nur NEC, das Protokoll auf das ich's abgesehen hab, dann:
>
> Direkter Zugriff: 1978 Bytes
> Indirekt Zugriff: 1656 Bytes (84% Codegröße)

Ich komme mit avr-gcc V4.7.2 für ATtiny24 und nur NEC mit dem 
Original-Source aus dem SVN auf:
1
avr-size irmp.elf
2
   text    data     bss     dec     hex filename
3
   1284       4      39    1327     52f irmp.elf
(LTO eingeschaltet)

Das sind 64% Codegröße. Mit Deiner Optimierung über den direkten Zugriff 
dürfte das noch besser ausfallen.

Sind die neueren avr-gcc sooo viel schlechter geworden?

Protokoll:
1
avr-gcc  -mmcu=attiny24 -Wall -gdwarf-2 -std=gnu99        -flto   -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT irmp.o -MF dep/irmp.o.d  -c  ../irmp.c
2
avr-gcc -mmcu=attiny24 -Os -flto  -Wl,-Map=irmp.map irmp.o irmp-main-avr.o     -o irmp.elf
3
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  irmp.elf irmp.hex
4
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex irmp.elf irmp.eep || exit 0
5
avr-objdump -h -S irmp.elf > irmp.lss

Johann L. schrieb:
> Wprd gerne nen ATtiny24 verwenden.  Der Code passt da zwar locker rein,
> aber es soll ja mehr auf den µC als IR-Auswertung...

Immer diese Selbstquälerei, nimm einfach einen ATtiny44 ;-)

Okay, ich schaue noch, was sich machen ließe. Ich habe mal testweise den 
memcpy_P() auskommentiert, um zu sehen, was man maximal rausholen 
könnte. Brachte 60 Bytes Ersparnis, also nicht die Welt.

Ich persönlich halte den avr-gcc 4.7.2 immer noch für den besten. Alle 
neuere Versionen erzeugen größeren Code.

: Bearbeitet durch Moderator
von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Ich persönlich halte den avr-gcc 4.7.2 immer noch für den besten. Alle
> neuere Versionen erzeugen größeren Code.

ist mir auch aufgefallen, ich hatte gerade mal die Versionnummer 
ausgeben lassen, der Alte macht das schon gut!

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> Johann L. schrieb:
>> Python?
>
> ich bekomme Angst, wenn ich an die unterschiedliche Einrückung denke
> TABS SPACES, mal mehr mal weniger

Mit einem vernünftigen Editior wie z.B. Emacs merkst du davon überhaupt 
nix.  Emacs etwa erkennt automatisch wie eingerückt wurde und verwendet 
dieses Einrück-Schema.

Einrückung als Teil der Semantik ist vielleicht keine Sternstunde des 
eines Sprachdesigns, aber immerhin vermeidet es Flame-Wars was denn die 
richtige Einrückung sei und wo { oder } zu klatzieren seien.

Emacs fügt bei TAB auch kein Tab ein, sondern geht zu der entsprechenden 
Einrückung (auch in C / C++ etc.).  Falls die Syntax mehrere 
Möglichkeiten bietet, iteriert Emacs sie bei TAB durch.

Alles easy und transparent.  Vielleicht etwas ungewohnt, aber deshalb 
schreiend vor einer Spache wegrennen...?

> Python v2 v3?

Schreib den Code einfach so, dass er für Python v2.7 und v3 passt.  Bei 
> 95% der Anwendungen genügt dafür als erste Zeile (nach einem evtl. 
Shebang)
1
from __future__ import print_function
so dass print in v3-Syntax zu stehen hat.

> neee Python NEVER

Während man in VillalC++ noch in Spezifikation, cppreference.com und 
cplusplus.com wühlt und sich die Haare rauft, ist man in VillaPython 
schon am feiern :-)

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Johann L. schrieb:
>> Aktiviere ich nur NEC, das Protokoll auf das ich's abgesehen hab, dann:
>>
>> Direkter Zugriff: 1978 Bytes
>> Indirekt Zugriff: 1656 Bytes (84% Codegröße)
>
> Ich komme mit avr-gcc V4.7.2 für ATtiny24 und nur NEC mit dem
> Original-Source aus dem SVN auf:
>
1
> avr-size irmp.elf
2
>    text    data     bss     dec     hex filename
3
>    1284       4      39    1327     52f irmp.elf
4
>
> (LTO eingeschaltet)
>
> Das sind 64% Codegröße. Mit Deiner Optimierung über den direkten Zugriff
> dürfte das noch besser ausfallen.
>
> Sind die neueren avr-gcc sooo viel schlechter geworden?

Hier mal meine Codegrößen (in Byte), mit den indirekten Zugriffen wie 
oben:
1
v4.7: 1618
2
v4.9: 1576
3
v7:   1558
4
v8:   1552
Der kleinste Code ist also mit v8, und v4.7 liefert den größten.

Übersetzt für einen ATmege168 weil sich irmp-main-avr-uart.c nicht ohne 
weiters für einen ATtiny24/44/84 übersetzen lässt, vermutlich wegen USI.

Optimierungsoptionen:
1
-Os -flto -ffunction-sections -fdata-sections -mrelax -Wl,--gc-sections
für irmp.c und irmp-main-avr-uart.c.

> Okay, ich schaue noch, was sich machen ließe. Ich habe mal testweise den
> memcpy_P() auskommentiert, um zu sehen, was man maximal rausholen
> könnte.

Das problem ist nicht das memcpy_p, das brauch ja ein paar 
Instruktionen.

Der Haken ist wie gesagt, dass pgm_read_xxx nicht transparent ist, d.h. 
Flash-Zugriffe auf bekannte Adressen im Gegensatz zu __flash nicht 
wegoptimiert werden (können).

> Brachte 60 Bytes Ersparnis, also nicht die Welt.

> Ich persönlich halte den avr-gcc 4.7.2 immer noch für den besten. Alle
> neuere Versionen erzeugen größeren Code.

Siehe oben.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Johann L. schrieb:
>> Würd gerne nen ATtiny24 verwenden.  Der Code passt da zwar locker rein,
>> aber es soll ja mehr auf den µC als IR-Auswertung...
>
> Immer diese Selbstquälerei, nimm einfach einen ATtiny44 ;-)

Hab hier noch nen ATtiny24 und 'nen LED-Streifen anzusteuern ist ja 
keine Rocket-Science...

Wird ausgenutzt, dass nur 1 Protokoll (NEC) verwendet wird, schrumpft 
der Code um 150 Bytes, und ohne UART wird er um weitere 300 Byte 
kleiner.

Das memcpy_P ist dabei noch nicht aufgelöst; "Problem" von NEC ist, dass 
es eigentlich 2 Protokolle sind: eines für "normale" Codes und eines für 
Widerholungen.  Löse ich die Gemainsamkeiten von nec_param und 
nec_rep_param auch noch auf, komme ich auf unter 1000 Bytes Code.  Wird 
also lockerst in einen ATtiny24 passen :-)

von Lorand U. (Gast)


Lesenswert?

Schönes Projekt!

Nur aus Interesse:
Gibt es einen bestimmten Grund warum der Receiver Pin so oft abgefragt 
wird (10-20kHz), anstatt die Pegeländerungen mit einem Interrupt zu 
detektieren und in der Interrupt Routine die Zeit zwischen den Aufrufen 
zu messen?
Könnte man sich da nicht einiges an Prozessorlast sparen?

von Armin J. (arminj)


Lesenswert?

Lorand U. schrieb:
> Gibt es einen bestimmten Grund warum der Receiver Pin so oft abgefragt
> wird (10-20kHz), anstatt die Pegeländerungen mit einem Interrupt zu
> detektieren und in der Interrupt Routine die Zeit zwischen den Aufrufen
> zu messen?
> Könnte man sich da nicht einiges an Prozessorlast sparen?

1. Nicht alle Protokolle lassen sich mit der Interrupt Methode erkennen, 
das Problem ist die Erkennung wann das Protokoll zu Ende ist.
2. Die Arduino Library Version von IRMP https://github.com/ukw100/IRMP 
hat die Interrupt Methode eingebaut!

von Lorand U. (Gast)


Lesenswert?

Armin J. schrieb:
> 1. Nicht alle Protokolle lassen sich mit der Interrupt Methode erkennen,
> das Problem ist die Erkennung wann das Protokoll zu Ende ist.

Das versteh ich nicht.
Wenn eine gewisse Zeit lang kein Pinchange mehr passiert, weiß ich dass 
das Signal zuende ist.
Genauso ist es aber auch wenn ich alle 50µs (20kHz) den Pin abfrage. 
Erst wenn eine gewisse Zeit der Pin nicht mehr auf LOW geht, weiß ich 
dass das Signal zuende ist.
Außer ich hab das Protokoll schon so weit analysiert, dass ich schon 
weiß, dass nichts mehr kommen wird. Aber das ist auch bei beiden 
Methoden gleich.

Überseh ich da irgendwas?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Lorand U. schrieb:
> Wenn eine gewisse Zeit lang kein Pinchange mehr passiert, weiß ich dass
> das Signal zuende ist.

Das ist korrekt:

Mit einer Kombination aus Pinchange-Interrupt und zusätzlichem Timer 
als Timeout-Detector kann man die Prozessor-Last durchaus reduzieren. 
Ohne Timer geht es aber nicht, weil sonst diverse Timeouts (z.B. bei 
gleichzeitigem Verfolgen von verschiedenen Protokollen bzw. 
Frame-Längen) nicht erkannt werden können und die Statemachine dann 
"steckenbleiben" kann.

Das IRMP-Projekt ist allerdings vor mehr als 10 Jahren entstanden, da 
hatten noch längst nicht alle AVRs beliebig viele Pins, die man für 
Pinchange-Detektion einsetzen konnte. Da gab es beispielsweise nur INT0 
(und INT1), z.B. für den damals doch recht beliebten ATmega8.

So habe ich mich damals für die alleinige Timer-Nutzung entschieden, 
damit IRMP möglichst breit einsetzbar ist. Das betrifft nicht nur eine 
Prozessorfamilie (z.B. AVRs), sondern auch die Portierung auf andere µC 
Architekturen. Der Code würde heute durch zusätzliche Verwendung von 
Pinchange-Interrupts noch komplizierter werden, als er schon ist: Für 
jede Prozessorfamilie kämen dann nochmal die Interrupt-Handler hinzu.

Die Prozessorlast ist auch tatsächlich niedriger, als die Programmgröße 
es vermuten lässt. Es werden pro Timeraufruf jeweils nur kleine 
Bruchstücke der recht umfangreichen Statemachine durchlaufen. So hält 
sich die Prozessorlast doch sehr in Grenzen.

Du kannst natürlich gern die entsprechenden Interrupt-Handler für die 
aktuell unterstützten µCs beisteuern und den dazugehörenden 
Timer-Interrupt neu erstellen. Ich freue mich dann auf Deinen Code :-)

von Armin J. (arminj)


Lesenswert?

Frank M. schrieb:
> Die Version 3.2.0 ist online.
> - 22.06.2020: Unterstützung von 433MHz Funkprotokollen (RF)

Ich habe mal die Medion PC Fernbedienung 20018071, die man schon ab 3€ 
bei Ebay(Kleinanzeigen) bekommt, analysiert.
Mit den folgenden Werten läuft es gut, ich habe dafür einach mal die 
Telefunken Definition missbraucht. Es läuft übrigens mit allen 40 
anderen IR Protokollen aus dem AllProtocol Example gleichzeitig, man 
muss sie nicht disablen.
1
#define TELEFUNKEN_START_BIT_PULSE_TIME         3960.0e-6                       // 4 ms usec pulse
2
#define TELEFUNKEN_START_BIT_PAUSE_TIME         610.0e-6                        // 610 usec pause
3
#define TELEFUNKEN_PULSE_TIME                   570.0e-6                        //  560 usec pulse
4
#define TELEFUNKEN_1_PAUSE_TIME                 1700.0e-6                       // 1700 usec pause
5
#define TELEFUNKEN_0_PAUSE_TIME                 560.0e-6                        //  560 usec pause
6
#define TELEFUNKEN_FRAME_REPEAT_PAUSE_TIME      5000.0e-6                       // frame repeat after 5 ms
7
#define TELEFUNKEN_ADDRESS_OFFSET               8                               // skip 0 bits
8
#define TELEFUNKEN_ADDRESS_LEN                  12                              // read 12 address bits
9
#define TELEFUNKEN_COMMAND_OFFSET               0                               // skip 8 bits
10
#define TELEFUNKEN_COMMAND_LEN                  8                               // read 8 bits
11
#define TELEFUNKEN_COMPLETE_DATA_LEN            20                              // complete length
12
#define TELEFUNKEN_STOP_BIT                     1                               // has stop bit
13
#define TELEFUNKEN_LSB                          0                               // LSB...MSB
14
#define TELEFUNKEN_FLAGS                        0                               // flags
Die Daten müssen aber anders als oben spezifiziert interpretiert werden:
Die oberen 8 Bit der Adresse sind die Command + 0x2B also Checksum oder 
Plausi und die letzten 4 Bit der Adresse sind immer 0.
Command sind die ersten Bits, da sind die oberste Taste dann 01, 02 und 
die Zahlen Tasten sind (Zahl + E1).
Wie kann mas das in IRMP aufnehmen, und sollte man das überhaupt?
Gruß
Armin

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:

> Ich habe mal die Medion PC Fernbedienung 20018071, die man schon ab 3€
> bei Ebay(Kleinanzeigen) bekommt, analysiert.

Ist das die X10 von Pollin für 75 Cent oder ein ähnliches Modell? Nach 
den Anleitungen/Bildern, die ich für Deine PC Fernbedienung gefunden 
habe, scheint sie sehr ähnlich zu arbeiten, nur mit anderen Timings.

Die Beschreibung, wie der Funkkanal geändert werden kann, entspricht der 
X10 von Pollin, welches übrigens auch ein Medion-Modell ist.

> Die Daten müssen aber anders als oben spezifiziert interpretiert werden:
> Die oberen 8 Bit der Adresse sind die Command + 0x2B also Checksum oder
> Plausi und die letzten 4 Bit der Adresse sind immer 0.

Das passt zwar besser als meine erste Beschreibung, stimmt aber trotzdem 
nicht ganz. ;-)

Mittlerweile habe ich die X10 mittlerweile vollständig entschlüsselt, 
nachdem ich mal testweise die Funkkanäle gewechselt habe. Wie das geht, 
steht in der Anleitung von Pollin.

Heraus kommt der folgende Aufbau:

 - 1 toggle bit
 - 7 checksum bits
 - 1 toggle bit
 - 7 command bits
 - 4 channel bits

Die letzten 4 Bits sind nur dann 0, wenn Funkkanal 1 eingestellt ist. 
Für die Funkkanäle 1-16 findest Du in den letzten 4 Bits nämlich die 
entsprechenden Werte 0-15, wenn Du mal den Funkkanal wechselst.

Dabei gilt für die Checksum:
1
checksum = (command + 0x0055 + (channel << 4)) & 0x7F

Anhand des Ausprobierens verschiederner Funkkanäle konnte ich 
feststellen, dass das Kommando beileibe nicht vorne im Frame steckt, 
sondern erst die Checksum kommt, dann das Kommando und am Ende der 
Funkkanal.

Zweite wichtige Erkenntnis: Der Wert der Checksum ist abhängig vom 
gewähltem Funkkanal! (siehe auch "Formel" oben)

> Wie kann mas das in IRMP aufnehmen, und sollte man das überhaupt?

Ich habe es in der neuen Fassung für die X10 folgendermaßen gemacht:
1
In der ISR:
2
1. Checksum in irmp_address gespeichert
3
2. Kommando inkl. 4 Funkkanal-Bits in irmp_command gespeichert
4
5
In irmp_get_data():
6
1. Checksum nach obiger Regel geprüft.
7
2. 4 Funkkanal-Bits nach irmp_address kopiert
8
3. Kommando um 4 Bits nach rechts geschoben

Damit wird in irmp_addr der Funkkanal gespeichert. Diesen bekommt man 
dann per irmp_get_data() frei Haus mitgeliefert.

Ich kann meine Änderungen dafür mal heute abend einchecken, dann kannst 
Du das entsprechend für Deine FB machen, die ja offenbar nur ein 
abweichendes Timing hat und die Formel für die Checksum eventuell eine 
andere ist.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:
> Es läuft übrigens mit allen 40 anderen IR Protokollen aus dem
> AllProtocol Example gleichzeitig, man muss sie nicht disablen.

Es macht aber keinen Sinn, RF- und IR-Signale gleichzeitig zuzulassen. 
Es gibt im irmp nur einen Input-Pin. Daran schließt Du entweder einen 
RF-Empfänger (active high) oder einen IR-TSOP (active low) an.

Okay, man könnte nun durch entsprechende Vorkehrungen (Transistor am 
RF-Empfänger-Ausgang) dafür sorgen, dass das RF-Signal active low wird 
und gleichzeitig über dieselbe Open-Collector-Eigenschaft wie ein TSOP 
verfügt. Dann könnte man sogar beide Signale an demselben µC-Eingangspin 
anschließen.

Aber diese Konstruktion sehe ich schon als sehr "exotisch" an.

von Armin J. (arminj)


Angehängte Dateien:

Lesenswert?

Hier ein Bild des IC's.
Eine Select Taste für den Funkkanal gibt es nicht, oder ist nicht 
verdrahtet.

: Bearbeitet durch User
von Lorand U. (Gast)


Lesenswert?

Danke für die ausführliche Antwort zum Pinchange-Interrupt :)
Das macht Sinn!

von Armin J. (arminj)


Lesenswert?

Und noch was zur Medion PC Fernbedienung 20018071.
Der Code wird mindestens 5 mal gesendet, auch wenn man nur kurz auf die 
Taste drückt.
Kann man das irgendwo spezifizieren?

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Es macht aber keinen Sinn, RF- und IR-Signale gleichzeitig zuzulassen.
> Es gibt im irmp nur einen Input-Pin.

OK, in einem Post erwähntest du das IRMP nun x10 dekodieren kann, ich 
wollte es gerade mal aufbauen und stolpere schon (ich nutze ja am 
Arduino immer noch deine Version von 2015 weil ich sie besser kenne und 
sie am mega328p und am mega1284p unter Arduino gut läuft.

Nun habe ich in der Arduino IDE 1.8.9 unter Bib. Verwalter 
nachinstalliert und bekomme nur die 3.0.0 aber es heisst ja im Artikel
Ab Version 3.2 kann IRMP auch RF-Funkprotokolle (433 MHz) dekodieren.

Erste Hürde!
Dann heisst es auch für den ESP32, der ist im Beispiel der 3.0.0 nicht 
mal wählbar?

Also muss ich die LIB für den ESP32 nun händisch einbinden? und wo?
Normalerweise ja in Sketchverzeichnis aber unter Hardware wird ja dort 
verzweigt nach tools, bin leicht verwirrt.

Eines fiel mir schon auf im Beispiel der v3.0.0:
1
void setup()
2
{   Serial.begin(115200);
3
#if defined(__AVR_ATmega32U4__)
4
    while (!Serial); //delay for Leonardo, but this loops forever for Maple Serial
5
#endif
6
#if defined(SERIAL_USB) || defined(SERIAL_PORT_USBVIRTUAL)
7
    delay(2000); // To be able to connect Serial monitor after reset and before first printout
8
#endif
9
#if defined(__ESP8266__)
10
    Serial.println(); // to separate it from the internal boot output
11
#endif

ESP32 nicht wählbar?

Serial.begin(115200); mit brutalen 115k OK wer kann, bei mir klemmts an 
wUSB und USB Server LAN100/400 von sharkoon, ich mag da lieber das es 
funktioniert mit 19k2

Dann fiel mir auf das der alte Müll in der Schnitte nicht entsorgt wird 
nach Serial.begin....

finde das so etwas geschmeidiger
1
  Serial.begin(19200);
2
  Serial.flush();
3
  /*while(Serial.available()) // alternativ
4
    Serial.read();*/

würde mich nun über Antworten freuen wie ich weiter vorgehen kann.

LG jar

: Bearbeitet durch User
von Armin J. (arminj)


Lesenswert?

Joachim B. schrieb:
> Erste Hürde!
> Dann heisst es auch für den ESP32, der ist im Beispiel der 3.0.0 nicht
> mal wählbar?

Wie möchtest Du ihn denn auswählen?
LG Armin

von Joachim B. (jar)


Lesenswert?

Armin J. schrieb:
> Wie möchtest Du ihn denn auswählen?

nun darfst du raten warum ich frage, im ersten Moment dachte ich an

Joachim B. schrieb:
> #if defined(ESP32)

aber da die LIB erst 3.0.0 ist und Frank schrieb ab 3.2.0 ist der ESP32 
drin.....

Warum fragst du? hilft mir das?

Vielleicht gibt der Autor eine Antwort, eilt ja nicht ich dachte ich 
probiere es mal aber wenn ich über den Bib. Verwalter nicht rankomme 
scheint es ja nicht so wichtig zu sein.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Joachim B. schrieb:
> aber da die LIB erst 3.0.0 ist und Frank schrieb ab 3.2.0 ist der ESP32
> drin.....

Es könnte sein, dass die Versionsnummerierung des Arduino-Ports von der 
Nummerierung der Original-Version abweicht. Auskunft könnte Dir Armin 
geben, den Du gerade abgeschmettert hast. Er ist maßgeblicher Supporter 
des Arduino-Ports von IRMP.

Ich persönlich kann überhaupt keine Auskunft geben, wenn es konkret um 
den Arduino-Port geht. Da stecke ich zuwenig drin.

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Auskunft könnte Dir Armin
> geben, den Du gerade abgeschmettert hast. Er ist maßgeblicher Supporter
> des Arduino-Ports von IRMP.

und wie half dann?

Armin J. schrieb:
> Wie möchtest Du ihn denn auswählen?
> LG Armin

ich kann das doch nicht riechen und wenn er der Supporter ist hätte er 
doch richtig antworten können, warum 3.0.0 genannt wird und 3.2.0 
aktuell ist.

Du weisst ja selbst wie hier ständig mit Gegenfragen vom Thema 
abgewichen wird!
Gegenfragen sind nun mal keine Antworten!

von Jörg R. (jrie)


Lesenswert?


von Joachim B. (jar)


Lesenswert?

Jörg R. schrieb:
> Guck mal da:

ich habe schon überall geschaut,

für Arduino wurde einiges stark geändert, aus *.c wurde *.c.h

Ich tippe mal ins Blaue die C-Sourcen wurden als Header eingebunden 
(traurigerweise was mir hier mal als VÖLLIGE Ahnungslosigkeit 
unterstellt wurde!)

Es scheint so als wenn nur die Anzeige noch auf version 3.0.0 steht, 
möglicherweise ist der Code sogar aktuell, aber ich kann jetzt nicht 
anfangen jede Zeile zu prüfen, dazu bin ich aus dem Source Code seit 
2015 zu lange raus.

von Joachim B. (jar)


Lesenswert?

Frank M. schrieb:
> Auskunft könnte Dir Armin
> geben, den Du gerade abgeschmettert hast. Er ist maßgeblicher Supporter
> des Arduino-Ports von IRMP.

muss ich nun auf die Knie fallen und um Vergebung bitten?

Du hattest ja die Version 3.2.0 erwähnt die ich unter der Arduino IDE 
eben nicht einbinden konnte!
Ich verstehe auch nicht warum die Arduino IDE nur die Version 3.0.0 
anbietet und nennt!

Meine Frage wurde nicht beantwortet und warum ein mir bis dahin 
unbekannter Armin auf meine Frage eine Gegenfrage stellt bleibt auch 
unklar.

Aber danke dafür!
Das sagt viel aus!

IRMP ist schon irgendwie genial, aber wie heisst es doch Genie und 
Wahnsinn liegen dicht beieinander!

: Bearbeitet durch User
von 900ss D. (900ss)


Lesenswert?

Joachim B. schrieb:
> muss ich nun auf die Knie fallen und um Vergebung bitten?

Du hast schon eine sonderbare Art um Hilfe zu bitten zumal du hier schon 
etwas geschenkt bekommen hast. Rumpöbeln und sich beschweren wenn keine 
(wenig) Hilfe kommt.
Ja sicher, es ist nicht vollkommen, das Geschenk für dich, aber du nutzt 
es doch freiwillig.

: Bearbeitet durch User
Beitrag #6358263 wurde vom Autor gelöscht.
von Joachim B. (jar)


Lesenswert?

900ss D. schrieb:
> Du hast schon eine sonderbare Art um Hilfe zu bitten zumal du hier schon
> etwas geschenkt bekommen hast.

ja ich bin ein Mensch mit Fehler, aber ich gestehe das auch Autoren zu 
die auf eine Frage mit einer Gegenfrage antworten!

Selbst Moderatoren gestehe ich Fehler zu (auch dem Frank, er wird sich 
erinnern RTC3231 Ladeschaltung & CR, da hat er mich auch 
irrtümlicherweise rund gemacht) das sie in der Arduino IDE nicht 
involviert sind, aber das kann kein Grund sein nun nicht zu antworten 
ausser sie wollen halt nicht.

OK habe ich öfter erlebt und scheint oft der Grund zu sein warum Arduino 
in gewissen Kreisen verpönt ist.
Ich mag Arduino sehr, habe das öfter geschrieben aber so kann ich auch 
mittlerweile Arduino Hasser verstehen!

Wollen die Arduino LIB Ersteller echt helfen oder nur ihrem EGO frönen?

min 2 Möglichkeiten, Neustart meinen "Tonfall" abhaken und eine 
verständliche Antwort geben:

wie kann ich in der Arduino IDE die Version 3.2.0 einbinden?

oder mich weiter ignorieren, das sagt auch was aus!

von Armin J. (arminj)


Lesenswert?

Frank M. schrieb:
> Ich kann meine Änderungen dafür mal heute abend einchecken, dann kannst
> Du das entsprechend für Deine FB machen, die ja offenbar nur ein
> abweichendes Timing hat und die Formel für die Checksum eventuell eine
> andere ist.

Hallo Frank, bin erst jetzt dazu gekommen das mal zu testen.
mit dem Timing
1
#define RF_X10_START_BIT_PULSE_TIME             3960.0e-6    // 2850 usec pulse
2
#define RF_X10_START_BIT_PAUSE_TIME              610.0e-6    // 1710 usec pulse
3
#define RF_X10_0_PULSE_TIME                      570.0e-6    //  570 usec pulse
4
#define RF_X10_0_PAUSE_TIME                      570.0e-6    // 1000 usec pause
5
#define RF_X10_1_PULSE_TIME                      570.0e-6    // 1000 usec pulse
6
#define RF_X10_1_PAUSE_TIME                     1710.0e-6    //  500 usec pause
7
8
#define RF_X10_FRAME_REPEAT_PAUSE_TIME          5000.0e-6    // frame repeat after 4460 usec
tuts das auf Anhieb, die Checksum Funktion brauchte ich nicht zu ändern.
Willst Du das jetzt als RF_MEDION aufnehmen?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hallo Armin,

Armin J. schrieb:
> Willst Du das jetzt als RF_MEDION aufnehmen?

Ja, mache ich noch heute.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Neue IRMP-Version 3.2.3:

Änderung: Neues RF-Protokoll: RF_MEDION

Viel Spaß!

von Armin J. (arminj)


Lesenswert?

Hallo Frank,
gibt es einen Grund, warum irmp_get_data() uint_fast8_t und nicht bool 
ist?
Ist das noch historisch?
Ich versuche das gerade zu dokumentieren:
https://github.com/ukw100/IRMP#api
1
// Main check for result function used in loop() - returns TRUE or FALSE
2
uint_fast8_t irmp_get_data (IRMP_DATA *)

Und das wäre einfacher zu verstehen, wenn der Returnwert bool wär.
Ich weiss, dass das denselben Assembler Code gibt, aber verwirrend ist 
es erstmal.

Könnte man das eventuell nur für #ifdef ARDUINO auf bool setzen?

von Lê Q. (l_q)


Lesenswert?

Hello everyone,
I am try to make IR learning remote by using microcontroller ( my item
is EFR32 of Silicon labs)
I used to refer IRMP_English and IRSND to decoder and encoder IR signal
and I was successful with protocols which are available in the IRMP
Protocols.
but it will not work with strange protocols.
Do we need to decode it to be able to save it and emit it?
Is there any way we could capture the infrared signal, then save it and
emit it without encoding end decoding it? because if encoding and
recording will not work if there is a strange protocol.
I searched a lot of information on various forums but couldn't find it.

von Armin J. (arminj)


Lesenswert?

For just recording and replay you should consider to use the IRremote 
library.
See example 
https://github.com/z3t0/Arduino-IRremote/blob/master/examples/IRrecord/IRrecord.ino

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Hi Armin,

Armin J. schrieb:
> gibt es einen Grund, warum irmp_get_data() uint_fast8_t und nicht bool
> ist?
> Ist das noch historisch?

Ja, das ist historisch und ich würde es für C auch nicht ohne zwingende 
Not ändern wollen. In C ist "stdbool.h" zwar mittlerweile Standard, aber 
ich weiß nicht, welchen (älteren) C-Compiler ich damit ausschließen 
würde. Daher habe ich das auch nie geändert. Die Verwendung von "bool" 
ergibt (in C) auch keinen verwertbaren Vorteil. Und wer weiß? Vielleicht 
gibt ja irmp_get_data() irgendwann aus irgendwelchen Gründen auch andere 
Werte als 0 und 1 zurück?!? ;-)

In C++ (wie Arduino) ist die Verwendung von bool natürlich überhaupt 
kein Problem. Daher könnte man das durchaus für Arduino oder besser noch 
mittels
1
#ifdef __cplusplus
2
...
3
#endif
so einstellen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Armin J. schrieb:
> For just recording and replay you should consider to use the IRremote
> library.

I already had contact with l_q by mail in the last days. He wants to 
decode the Daikin protocol (air conditioning) with IRMP. But as I 
learned on https://github.com/blafois/Daikin-IR-Reverse meanwhile, this 
protocol consists of at least 15 bytes, not bits! Therefore it is 
impossible to handle the protocol with IRMP. IRMP is not prepared for 
such frame lengths.

@l_q: IRMP is the wrong tool here because Daikin's IR frames are much 
too long. Perhaps https://github.com/blafois/Daikin-IR-Reverse is the 
better tool for you.

: Bearbeitet durch Moderator
von Armin J. (arminj)


Lesenswert?

Frank M. schrieb:
> In C++ (wie Arduino) ist die Verwendung von bool natürlich überhaupt
> kein Problem. Daher könnte man das durchaus für Arduino oder besser noch
> mittels
>
1
> #ifdef __cplusplus
2
> ...
3
> #endif
4
>
> so einstellen.

Das wäre SUUUUUUUPER
Danke
P.s. und für irmp_ISR (void); bitte auch :-)

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Armin J. schrieb:
>> gibt es einen Grund, warum irmp_get_data() uint_fast8_t und nicht
>> bool ist? Ist das noch historisch?
>
> Ja, das ist historisch und ich würde es für C auch nicht ohne zwingende
> Not ändern wollen. In C ist "stdbool.h" zwar mittlerweile Standard,

bool bzw. stdbool.h gibt's seit C99...

> aber ich weiß nicht, welchen (älteren) C-Compiler ich damit ausschließen
> würde. Daher habe ich das auch nie geändert. Die Verwendung von "bool"
> ergibt (in C) auch keinen verwertbaren Vorteil. Und wer weiß? Vielleicht
> gibt ja irmp_get_data() irgendwann aus irgendwelchen Gründen auch andere
> Werte als 0 und 1 zurück?!? ;-)

...wobei uint_fast8_t bzw. stdint.h ebenfalls C99 sind.

Problem wären also Compiler, die C99 nur teilweise unterstützen.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Was ist eigentlich der Grund dafür, dass die Voreinstellung nur ein 
einziges IR-Protokoll aktiviert hat, nämlich NEC?

Ist NEC der neue Quasi-Standard, also sozusagen das neue RC5?

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> bool bzw. stdbool.h gibt's seit C99...

Da magst Du recht haben. Wenn Du mir nur einen Grund nennst, was ich 
durch Verwendung von bool gegenüber uint8_t als Rückgabewert einer 
Funktion gewinne, kann ich das gerne ändern. Der erzeugte Assembler-Code 
ist jedenfalls derselbe und ich halte mir so die Option offen, noch 
andere Werte als true oder false zurückliefern zu können - ohne etwas am 
Interface ändern zu müssen.

Johann L. schrieb:
> Was ist eigentlich der Grund dafür, dass die Voreinstellung nur ein
> einziges IR-Protokoll aktiviert hat, nämlich NEC?

Es sind 4 Protokolle, die standardmäßig aktiviert sind, nämlich:
1
#define IRMP_SUPPORT_SIRCS_PROTOCOL             1
2
#define IRMP_SUPPORT_NEC_PROTOCOL               1
3
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL           1
4
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL          1

(siehe irmpconfig.h)

> Ist NEC der neue Quasi-Standard, also sozusagen das neue RC5?

Siehe 3. Abschnitt am Anfang des IRMP-Artikels, nämlich unter 
https://www.mikrocontroller.net/articles/IRMP#IR-Protokolle :

"Heutzutage wird (auch vornehmlich bei japanischen Geräten) das 
NEC-Protokoll verwendet - und zwar von den unterschiedlichsten (Marken- 
und auch Noname-)Herstellern. Ich schätze den "Marktanteil" auf ca. 80% 
beim NEC-Protokoll. Fast alle Fernbedienungen im alltäglichen Einsatz 
verwenden bei mir den NEC-IR-Code. Das fängt beim Fernseher an, geht 
über vom DVD-Player zur Notebook-Fernbedienung und reicht bis zur 
Noname-MultiMedia-Festplatte - um nur einige Beispiele zu nennen."

RC5 ist längst tot. Philips hatte zwar nochmal eine Wiederauferstehung 
mit RC6 versucht, ist aber damit längst nicht so erfogreich geworden wie 
damals mit RC5.

NEC als universelles Protokoll findest Du dagegen fast überall. Im oben 
genannten Kapitel des Artikels wird auch noch über die anderen oft am 
Markt anzufindenden Protokolle geschrieben, nämlich über Kaseikyo 
(vornehmlich in Asien) und Sony.

von 900ss D. (900ss)


Lesenswert?

Frank M. schrieb:
> bool gegenüber uint8_t als Rückgabewert einer Funktion gewinne, kann

Ich habe nicht selten Kollegen erlebt, die waren der Meinung in bool 
kann es nur 0 oder 1 (false oder true) geben. Wunderten sich dann als 
ein Vergleich mit true nicht klappte, weil 5 drin stand. :)
bool gehört abgeschafft.

von Joachim B. (jar)


Lesenswert?

900ss D. schrieb:
> bool gehört abgeschafft

wegen falscher Benutzung?

soweit ich weiss ist false immer NULL und true immer !false wobei es 
nicht interessiert was in true steht.

Gut ist doch das man true(!false) auch nutzen kann für Ergebnisse.

: Bearbeitet durch User
von Armin J. (arminj)


Lesenswert?

Aber wenn der Rückgabewert der Funktion (irmp_ir_detected) nur mit
1
irmp_ir_detected = FALSE;
und
1
irmp_ir_detected    = TRUE;
belegt wird, ist es doch transparenter, die Funktion als bool zu 
deklarieren, wenn es sonst keine Gründe (Compiler kann es nicht) gibt. 
Oder?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Johann L. schrieb:
>> bool bzw. stdbool.h gibt's seit C99...
>
> Da magst Du recht haben. Wenn Du mir nur einen Grund nennst, was ich
> durch Verwendung von bool gegenüber uint8_t als Rückgabewert einer
> Funktion gewinne, kann ich das gerne ändern.

Es war nur eine Anmerkung meinerseits, dass es sowohl uint8_t o.ä. als 
auch bool seit C99 gibt, ohne irgendeine Empfehlung.

Allerdings steht in der Doku zu irmp_get_data():
1
 *  @return    true: successful, false: failed

> Der erzeugte Assembler-Code ist jedenfalls derselbe und ich halte mir
> so die Option offen, noch andere Werte als true oder false zurückliefern
> zu können - ohne etwas am Interface ändern zu müssen.

Anstatt "failed" würde ich eher sagen "nothing here", d.h. es wurde noch 
nichts bzw. nichts mehr empfangen seit dem letzten Datensatz?  "failed" 
würde ich interpretieren als Fehler im Protokoll bzw. irgendwas 
Unbekanntes.

900ss D. schrieb:
> Ich habe nicht selten Kollegen erlebt, die waren der Meinung in bool
> kann es nur 0 oder 1 (false oder true) geben.

Ist auch so, zumindenst in C99+ und C++.

> Wunderten sich dann als ein Vergleich mit true nicht klappte,
> weil 5 drin stand. :) bool gehört abgeschafft.

Dann war's irgendein Hack wie
1
#define bool unsigned char

Das bool von C/C++ kann sich aber aber niemals nich so verhalten wie ein 
unsigned char weil in C99
1
bool x = 5; // Set x to true.

: Bearbeitet durch User
von 900ss D. (900ss)


Lesenswert?

Johann L. schrieb:
> Ist auch so, zumindenst in C99+ und C++

C++ ist bei uns verboten, ja :( Da funktioniert es mit bool, ja. Aber 
eben nicht in C. Und ich kenne wirklich einige, die nicht wissen das in 
C bool nicht wirklich bool ist. Es ist da nur irreführend.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

900ss D. schrieb:
> Johann L. schrieb:
>> Ist auch so, zumindenst in C99+ und C++
>
> C++ ist bei uns verboten, ja :( Da funktioniert es mit bool, ja. Aber
> eben nicht in C. Und ich kenne wirklich einige, die nicht wissen das in
> C bool nicht wirklich bool ist. Es ist da nur irreführend.

Dann ist es nicht dass bool von C (also von C99) sondern was 
hausbackenes.

Beispiel avr-gcc:

C99:
1
#include <stdbool.h>
2
3
bool global_5 = 5;
4
5
bool bool_5 (void)
6
{
7
    return 5;
8
}

Präprozessiert:
1
_Bool global_5 = 5;
2
3
_Bool bool_5 (void)
4
{
5
    return 5;
6
}
d.h. bool ist effektiv ein Typ mit eigener, nicht-int Semantik!

Assembly:
1
.global  bool_5
2
  .type  bool_5, @function
3
bool_5:
4
  ldi r24,lo8(1)
5
  ret
6
  .size  bool_5, .-bool_5
7
8
.global  global_5
9
  .section  .data.global_5,"aw",@progbits
10
  .type  global_5, @object
11
  .size  global_5, 1
12
global_5:
13
  .byte  1
d.h. in beiden Fällen wird true (1) gespeichert und eben NICHT 5.

Wenn du GCC verwendest, und bool wird nicht auf _Bool abgebildet wird 
(das übrigens älter als C99 ist) dann habt ihr selber was gebastelt und 
unzureichend dokumentiert...

Natürlich wird der Vergleich "if (global_5 == 5)" nie zutreffen, weil es 
nach den Promotion-Rules ein Vergleich 2er int ist, und global_5 immer 0 
oder 1 ist.  Damit der Vergleich zutrifft, müsste man sowas wie "if 
(global_5 == (bool) 5)" machen.

von 900ss D. (900ss)


Lesenswert?

Johann L. schrieb:
> Dann ist es nicht dass bool von C

Das müsste ich prüfen. Weiß ich nicht im Kopf. Vielleicht wird auch 
nicht C99 verwendet sondern älter. Es ist alles soo alt in dem Projekt 
;)

: Bearbeitet durch User
von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Noch ne Frage zum NEC-Protokoll:

https://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol

spezifiziert den Payload eines Frames als 4 Bytes:

1. Adresse (little Endian)
2. 1er Complement von 1.
3. Commando (little Endian)
4. 1er Complement von 3.

Demnach werden nur Adressen 0x0...0xff unterstützt.  Ich bekomme aber 
für meine Bleil-Schrott-Fernbedienung eine Adresse von 0xEF00.

In IRMP: Fernbedienungen sind noch viele andere NEC Geräte 
aufgelistet, und deren Adressen sind auch keine 8-Bit Adressen...

Wo ist da mein Denkfehler?

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Johann L. schrieb:
> Noch ne Frage zum NEC-Protokoll:
>
> https://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol
>
> spezifiziert den Payload eines Frames als 4 Bytes:
>
> 1. Adresse (little Endian)
> 2. 1er Complement von 1.
> 3. Commando (little Endian)
> 4. 1er Complement von 3.

Das gilt nur für das Standard-NEC-Protokoll. NEC wurde später nochmals 
erweitert, genannt "Extended NEC". Dabei wurde das Complement der 
vormaligen Adresse aufgegeben und Byte #2 als zweites Adress-Byte 
erklärt.

Damit wird das Standard-NEC-Protokoll nur noch ein Spezialfall vom 
Extended-NEC-Protokoll. IRMP betrachtet NEC immer als Extended NEC und 
gibt deshalb eine 16-Bit-Adresse zurück, aber nur einen 
8-Bit-Kommando-Code - wobei das Complement vorher selbstverständlich 
überprüft wird.

Das steht aber auch im IRMP-Artikel, vergleiche bitte: 
https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC

Auszug:
1
Daten NEC   8 Adress-Bits + 8 invertierte Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits
2
Daten ext. NEC   16 Adress-Bits + 8 Kommando-Bits + 8 invertierte Kommando-Bits

> Demnach werden nur Adressen 0x0...0xff unterstützt.  Ich bekomme aber
> für meine Bleil-Schrott-Fernbedienung eine Adresse von 0xEF00.

Dann ist das klar eine Adresse aus dem "Extended-NEC-Protokoll".

: Bearbeitet durch Moderator