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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht lesenswert
IRSND 3.1.5 ist online.

Änderungen:

* Neues Protokoll: ONKYO

von Boris S. (cool-man)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


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

von E. K. (eku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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:

Bewertung
0 lesenswert
nicht 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:

Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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:
    static uint8_t key_table[128] =
    {
     // 0     1      2    3    4     5    6    7    8     9     A     B     C     D     E     F
        0x00, '^',  '1', '2', '3',  '4', '5', '6', '7',  '8',  '9',  '0',  0xDF, 0xB4,  0x00, '\b',
        '\t', 'q',  'w', 'e', 'r',  't', 'z', 'u', 'i',  'o',  'p',  0xFC, '+',  0x00,  0x00, 'a',
        's',  'd',  'f', 'g', 'h',  'j', 'k', 'l', 0xF6, 0xE4, '#',  '\r', 0x00, '<',   'y',  'x',
        'c',  'v',  'b', 'n', 'm',  ',', '.', '-', 0x00, 0x00, 0x00, 0x00, 0x00,  ' ',  0x00, 0x00,

        0x00, 0xB0, '!', '"', 0xA7, '$', '%', '&', '/',  '(',  ')',  '=',  '?',  0x60,  0x00, '\b',
        '\t', 'Q',  'W', 'E', 'R',  'T', 'Z', 'U', 'I',  'O',  'P',  0xDC, '*',  0x00,  0x00, 'A',
        'S',  'D',  'F', 'G', 'H',  'J', 'K', 'L', 0xD6, 0xC4, '\'', '\r', 0x00, '>',   'Y',  'X',
        'C',  'V',  'B', 'N', 'M',  ';', ':', '_', 0x00, 0x00, 0x00, 0x00, 0x00, ' ',   0x00, 0x00
    };

Das ist dann reines 7-Bit.

: Bearbeitet durch Moderator
von Vlad T. (vlad_tepesch)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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:
   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:

Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
1 lesenswert
nicht 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)


Bewertung
-1 lesenswert
nicht 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


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Das jage ich mit IRSND wieder raus.


Lernen

if (irmp_get_data(&irmpData))
{
if (!(irmpData.flags & IRMP_FLAG_REPETITION))
{
  System->irParameter.irmp[IRDATA_KEY1].protocol = irmpData.protocol;
  System->irParameter.irmp[IRDATA_KEY1].address = irmpData.address;
  System->irParameter.irmp[IRDATA_KEY1].command = irmpData.command;
  //nur die oberen 4 Bit speichern, da die unteren 4 Bit für diverse Flags reserviert sind
  System->irParameter.irmp[IRDATA_KEY1].flags = (irmpData.flags & 0xF0); 
          
  System-_LedBlink(1);
        
}
}



Senden

 irmpData.protocol = System->irParameter.irmp[IRDATA_KEY1].protocol;
 irmpData.address = System->irParameter.irmp[IRDATA_KEY1].address;
 irmpData.command = System->irParameter.irmp[IRDATA_KEY1].command;     
 irmpData.flags = RepVal;
      
 irsnd_send_data(&irmpData, 1);

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht 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:
irsnd_buffer[3] = 0x8B;
und ersetze sie durch
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:
./irsnd-15kHz 11 67 10 | ./irmp-15kHz
01110111111000010000100010001011 p=11 (APPLE), a=0x00d1, c=0x0010, f=0x00
Die hier ermittelte Adresse 0x00d1 ist falsch.

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

: Bearbeitet durch Moderator
von technikus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke!!!

Wo in irsnd die Zeile?

von technikus (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
Feedback: Positiv Getestet.
Die Änderung kannst du also übernehmen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Prima. Danke für die Rückmeldung.

von gsi (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
Ach so, gibt es eine Art Funktionsübersicht zu IRMP?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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.
void loop() {
  fahren();
}

void fahren() {
  if (runallowed == true) {
    for (int i = 0; i <= 320; i++) {
      digitalWrite(DIR, ydir);
      digitalWrite(STP, HIGH);
      delayMicroseconds(20);
      digitalWrite(DIR, ydir);
      digitalWrite(STP, LOW);
      delayMicroseconds(mspeed);
      runallowed = false;
      interrupts(); // enable interrupts
    }
  }
}

void handleReceivedIRData() {
  irmp_get_data(&irmp_data[0]);
  switch (irmp_data[0].command) {
    case 360: //rechts
      runallowed = true; //allow running
      ydir = HIGH;
      break;
    case 872:  //links
      runallowed = true; //allow running
      ydir = LOW;
      break;
  }
}

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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?
void handleReceivedIRData() 
  {
  irmp_get_data(&irmp_data[0]);

  switch (irmp_data[0].command) {
    case 360: //rechts
      Serial.print("rechts flags->");
      Serial.println(irmp_data[0].flags); 
      if (! (irmp_data[0].flags & IRMP_FLAG_REPETITION)) {
        Serial.println("rechts Einmalig");
        if (runallowed == true) {
          runallowed = false;
        }
        else {
          runallowed = true; //allow running
          ydir = HIGH;
        }
      }
      break;
    case 872:  //links
      Serial.print("links flags->");
      Serial.println(irmp_data[0].flags); 
      if (! (irmp_data[0].flags & IRMP_FLAG_REPETITION)) {
        Serial.println("links Einmalig");
        if (runallowed == true) {
          runallowed = false;
        }
        else {
          runallowed = true; //allow running
          ydir = LOW;
        }
      }
      break;
  }
}

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


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von tolero (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das steht im seriellen Monitor:
links flags->1
links flags->1
links flags->1
links flags->1
rechts flags->0
rechts Einmalig
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
links flags->0
links Einmalig
links flags->1
rechts flags->0
rechts Einmalig
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1
rechts flags->1

von tolero (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
Also bei mir tuts das, ich bekomme bei dem Interrupt Example:
P=NEC  A=0xFF00 C=0x19
P=NEC  A=0xFF00 C=0x19 R
P=NEC  A=0xFF00 C=0x19 R
P=NEC  A=0xFF00 C=0x19 R
P=NEC  A=0xFF00 C=0x19  <- Taste sehr kurz gedrückt
P=NEC  A=0xFF00 C=0x19  <- Taste sehr kurz gedrückt
P=NEC  A=0xFF00 C=0x19
P=NEC  A=0xFF00 C=0x19 R
P=NEC  A=0xFF00 C=0x19 R
P=NEC  A=0xFF00 C=0x19   <- Taste kurz gedrückt, 1 repeat
P=NEC  A=0xFF00 C=0x19 R
P=NEC  A=0xFF00 C=0x19
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)


Bewertung
-1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
-1 lesenswert
nicht lesenswert
Armin J. schrieb:
> Ja wenn Du meinst...

meine ich nicht, ist so

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


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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 :-)
#include <irmpSelectMain15Protocols.h>  // This enables 15 main protocols
#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
#define IRMP_SUPPORT_NEC42_PROTOCOL      0

von gsi (Gast)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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)


Bewertung
0 lesenswert
nicht 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 ...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.