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.
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?
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.
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.
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.
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
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.
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.
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.
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
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 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.
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.
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.
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 ^^.
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
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)
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.
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
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:
Vlad T. schrieb:> Daher würde ich warten, bis das läuft und dann die notwendigen> Änderungen nochmal zusammenfassen.
So, in Sigrok/Pulseview läufts (screenshot). Ich hab den Code für die
DLL in eigene Dateien gezogen. Allerdings ist ein kleiner Patch (patch
1) für die irmp.c trotzdem nötig.
Dem Compiler darf nur die irmp-main-SharedLib.c gegeben werden, da die
irmp.c includiert wird.
Außerdem hab ich angehangen, was für die IRMP integration in Sigrok oder
Pulseview nötig ist. Auch fertig gebaute dlls sind enthalten.
patch 2 fixt ein paar const issues.
Außerdem ist mir aufgefallen, dass an einigen stellen, Mikro und
Milli-Sekunden durchander gebracht werden.
Bei den Timeout-defines und bei dieser Zeile:
1
for(i=0;i<(int)((10000.0*F_INTERRUPTS)/10000);i++)// newline: long pause of 10000 msec
Meiner meinung nach kommt da eine Sekunde raus, weile F_INTERUPTS genau
einer Sekunde entspricht, was das komische rumgerechner überflüssig
macht.
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.
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.
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.
[ 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.
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.
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
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.
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....
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.
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.
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?
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 ;-)
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?
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.
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.
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.
[ 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.
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
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
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
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.
technikus schrieb:> ich empfange mit IRMP z.B. Protokoll=11, Add=67, Cmd=10;
Ich habe es gerade getestet und wohl den Fehler gefunden. IRSND sendet
mit kontanter Apple-ID 0x8B (ergibt Adresse 0xD1) und ignoriert daher
die von Dir übergebene Adresse 67. Das schien für alle mir übersandten
Apple-Scans bisher zu stimmen.
Korrigiere bitte in irsnd.c die folgende Zeile:
1
irsnd_buffer[3]=0x8B;
und ersetze sie durch
1
irsnd_buffer[3]=(command&0x00FF);
(Ja, die Adresse landet hier im unteren Byte von command, das ist dem
gemeinsamen Code von NEC und APPLE geschuldet)
Bitte sag dann Bescheid, ob es geklappt hat.
P.S.
Ausgabe im Simulator vor der Korrektur:
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
[ 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).
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.
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/27https://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
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.
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?
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.
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
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.
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.
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.
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
@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. :)
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
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.
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.
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
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.
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).
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?
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.
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?
@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.
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.
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.
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.
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."
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.
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.
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.
Frank M. schrieb:> Armin J. schrieb:>> Tested for NEC, [...]>> Dürfte aber dann nur noch funktionieren, wenn NEC42 ausgeschlossen ist.> Kannst Du das bestätigen?
Steht so in dem Beispiel :-)
1
#include <irmpSelectMain15Protocols.h> // This enables 15 main protocols
2
#undef IRMP_SUPPORT_NEC42_PROTOCOL // this protocols is incompatible to NEC in interrupt mode, since it is the same as NEC but has longer data sections
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
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/
@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!
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 ...
Hallo Frank und wer noch helfen könnte,
ich versuche Interoperabilität zwischen IRMP auf einem AVR,
IRremoteESP8266 (https://github.com/crankyoldgit/IRremoteESP826) auf
einem ESP8266 mit Tasmota, einer lernbaren Universalfernbedienung und
der FB meines Thomson TV herzustellen.
Die Universal-FB habe ich von der TV-FB angelernt. Mit beiden kann ich
den TV steuern. Und jetzt kommen IRMP und IRremoteESP8266 ins Spiel.
Beispielhaft hier der Power-Knopf der originalen FB.
IRMP: MATSUSHITA 04 0AB0 054F
IRremoteESP8266: "NIKAI","Bits":24,"Data":
"0x0D5F2A","DataLSB":"0xB0FA54"
Laut IRMP-Artikel hier im Wiki stimmt das mit den 24 Bit. In welcher
Beziehung MATSUSHITA und NIKAI stehen, kann ich nicht beurteilen.
Hier der Versuch, die Bits zwischen IRMP und IRremoteESP8266 zuzuordnen:
1011 0000 1111 1010 0101 0100 0xB0FA54
HHHH HHCC CCCC AAAA AAAA AAAA
0000 1101 0101 1111 0010 1010 0x0D5F2A
HHHH HHCC CCCC AAAA AAAA AAAA
H=Herseller, C=Kommando, A=Adresse
Betrachtet man 4 Bit und lässt ein wenig Fantasie walten, dann geht das
schon irgendwie auf. Ich hätte aber gerne ein klares Verständnis, schon
wegen der eingangs genannten Interoperabilität. Der IRMP-Wikiartikel
schweigt sich bezüglich der Aufteilung der 24 Bits aus.
Nächster Test ist das Senden ebendieses Signals.
IRSND -> IRremoteESP8266
"Protocol":"UNKNOWN","Bits":132,"Hash":"0xCEBB54B5","Repeat":0
IRremoteESP8266 -> IRMP
04 0AB0 054F
Sendet IRSND unsauber, was das Timing anbetrifft, oder liegt es an
IRremoteESP8266?
Und noch ein Test.
Universal-IR -> IRMP
04 0AB0 054F
Universal-IR -> IRremoteESP8266
"Protocol":"UNKNOWN","Bits":52,"Hash":"0x641EDF9D","Repeat":0
Dabei muss man der Universal-FB zu gute halten, dass diese das Protokoll
beim Anlernen nicht dekodiert, sonder nur aufzeichent und dann
wiedergibt.
Wer kann helfen?
eku schrieb:> Hier der Versuch, die Bits zwischen IRMP und IRremoteESP8266 zuzuordnen:>> 1011 0000 1111 1010 0101 0100 0xB0FA54> HHHH HHCC CCCC AAAA AAAA AAAA>> 0000 1101 0101 1111 0010 1010 0x0D5F2A> HHHH HHCC CCCC AAAA AAAA AAAA
IRMP fasst den Frame mit LSB first auf. Ob das richtig ist, weiß ich
nicht, darüber habe ich keine Infos im Netz gefunden, das war damals
lediglich bei der Dekodierung des MATSUSHITA-Protokolls eine Vermutung
von mir.
Deshalb steht unter
https://www.mikrocontroller.net/articles/IRMP#MATSUSHITA :
1
Bit-Order LSB first?
Wenn Du also jeweils 8 Bit rückwärts liest, wird aus:
> Sendet IRSND unsauber, was das Timing anbetrifft, oder liegt es an> IRremoteESP8266?
Wenn ich unter Linux den Output von IRSND in den IRMP per Pipe
"reinschicke", sieht das ganz korrekt aus:
Es kann natürlich sein, dass die Timings etwas abweichen. Ich persönlich
habe die Timings damals vermutlich empirisch aus mir zugesandten
IRMP-Scans per IRMP_LOGGING=1 gewonnen. Genau weiß ich es nicht mehr,
ist zu lange her.
Wie Jörg bereits fragte: Funktioniert denn IRSND -> Thomson TV?
Außerdem könntest Du mir einen Scan Deiner Original-FB schicken.
Genaueres findest Du unter IRMP_LOGGING im IRMP-Artikel.
eku schrieb:> ich versuche Interoperabilität zwischen IRMP auf einem AVR,> IRremoteESP8266 (https://github.com/crankyoldgit/IRremoteESP826) auf> einem ESP8266 mit Tasmota, einer lernbaren Universalfernbedienung und> der FB meines Thomson TV herzustellen.
Ist das Zufall oder warum bekomme ich bei dem Link ein 404?
eku schrieb:> Sendet IRSND unsauber, was das Timing anbetrifft, oder liegt es an> IRremoteESP8266?
IRremote hat eine seeeeehr schlechte Dekodierung, die Issues sind voll
davon.
Nimm einfach die Arduino IRMP https://github.com/ukw100/IRMP, die gibt
es für avr,esp8266,esp32,STM32,stm32,stm32duino,samd,apollo3.
Armin J. schrieb:> IRremote hat eine seeeeehr schlechte Dekodierung, die Issues sind voll> davon.> Nimm einfach die Arduino IRMP https://github.com/ukw100/IRMP, die gibt> es für avr,esp8266,esp32,STM32,stm32,stm32duino,samd,apollo3.
Gut gemeinter Rat. Ich verwende, wie geschrieben, Tasmota. Freilich
könnte ich versuchen, das Projekt zu einem Umstieg zu bewegen oder einen
PR dafür einzureichen. Allerdings bin ich bei Tasmota nur Anwender und
habe kein weiteres Wissen der Struktur und Arduino ist nicht meine
Domäne.
eku schrieb:> Allerdings bin ich bei Tasmota nur Anwender und> habe kein weiteres Wissen der Struktur und Arduino ist nicht meine> Domäne.
Danke, der Zusammenhang zwischen Tasmota und IRremote war mir gar nicht
klar.
Und auf dem AVR machst du IRMP nativ? Das ist mutig, ich hab mir das
nicht angetan.
Johann L. schrieb:> Ich dachte es wäre ein Projekt for AVRs? Das Makefile baut aber nur> Programme für den Host / PC?
Das Makefile ist für den Analyzer unter LINUX.
IRMP läuft auf AVR, XMega, PIC, STM32, STM8, TI, ESP und diversen
ARM Cortex.
Um das Projekt für AVR zu bauen, müsstest Du schon ein paar Blicke in
den Artikel IRMP werfen, insbesondere in das Kapitel
IRMP: Source-Code.
Zitat:
------------------------- Schnipp -----------------------
Der Source-Code lässt sich einfach für AVR-µCs übersetzen, indem man
unter Windows die Projekt-Datei irmp.aps in das AVR Studio 4 lädt.
Für andere Entwicklungsumgebungen ist leicht ein Projekt bzw. Makefile
angelegt. Zum Source gehören:
irmp.c - Der eigentliche IR-Decoder
irmpprotocols.h - Sämtliche Definitionen zu den IR-Protokollen
irmpsystem.h - Vom Zielsystem abhängige Definitionen für
AVR/PIC/STM32
irmp.h - Include-Datei für die Applikation
irmpconfig.h - Anzupassende Konfigurationsdatei
------------------------- Schnapp -----------------------
Beachte auch bitte die Hinweise zu den Konfigurationsparametern:
IRMP: Konfiguration
Armin J. schrieb:> Und auf dem AVR machst du IRMP nativ? Das ist mutig, ich hab mir das> nicht angetan.
das war easy, vielleicht einfacher als ich meinen ersten nativen AVR
Timer zur Camauslösung gebaut hatte irgendwann um 2007
achnee das war noch mit
/* RC5 Remote Receiver
*/
/* Author: Peter Dannegger
*/
IRMP erst mit Timer2 2011
nachdem das Display 2x zu früh aufgab nie fertig gebaut
IRMP also erst in wordclock12h eingesetzt 2015
Wie deaktiviert man denn ANALYZE, d.h. Anzeige der 01-Darstellung ohne
die Anzeige der Protokoll-Parameter zu deaktivieren?
-UANALYZE hat keinen Effekt, und -DANALYZE=0 führt zu Fehlern...
Die Version 3.2.0 ist online.
Neuerungen:
- 22.06.2020: Unterstützung von 433MHz Funkprotokollen (RF)
- 22.06.2020: "Neues Protokoll:" RF_GEN24
- 22.06.2020: "Neues Protokoll:" RF_X10
Das generische Protokoll RF_GEN24 wird von vielen Handfernbedienungen
für Funsteckdosen und Garagentoröffnern verwendet, z.B. Pollin 550666.
Ich habe da noch mindestens drei andere Fernbedienungen gefunden, die
dasselbe Protokoll verwenden.
Das Protokoll RF_X10 wird von einer PC-Funkfernbedienung verwendet, die
ebenso bei Pollin unter der Bestellnr. 721815 erhältlich ist und
ursprünglich von Medion stammt. Mit über 40 Tasten und sogar einem
Rollrad ist sie vielseitig einsetzbar, z.B. um damit Funkbrücken zu
IRSND (in einem anderen Raum) zu bauen - oder ähnliches. Kosten:
Schlappe 75 Cent.
Da die 433 MHz Funkempfänger im Gegensatz zu den IR-TSOPs mit aktivem
High-Pegel arbeiten, gibt es in irmpconfig.h dafür eine neue
Konfigurationsvariable:
1
#define IRMP_HIGH_ACTIVE 0
Diese ist für Funkempfänger auf 1 zu ändern. Für IR-Anwendungen ändert
sich nichts.
Die Software wurde im Artikel aktualisiert, die entsprechenden Stellen
bzgl. Funktionsumfang und Konfiguration wurde angepasst. Im Laufe dieser
Woche werde ich noch ein paar Bilder von diversen Funkfernbedienungen
einstellen und auch noch ein neues Kapitel zu geeigneten Empfängern
hinzufügen.
Johann L. schrieb:> Wie deaktiviert man denn ANALYZE, d.h. Anzeige der 01-Darstellung> ohne die Anzeige der Protokoll-Parameter zu deaktivieren?>> -UANALYZE hat keinen Effekt, und -DANALYZE=0 führt zu Fehlern...
Redest Du jetzt von der Host-Version oder von der AVR-Version?
AVR: ANALYZE-Ausgaben überhaupt nicht sinnvoll, schon gar nicht in einer
ISR. Hier könnte man addr, cmd, flags aber nach irmp_get_data() in der
main-Funktion ausgeben - auch den Protokollnamen, wenn gewünscht.
Host: ANALYZE wird hier in irmpsystem.h gesetzt, nämlich für Windows und
Linux.
Wenn ich es richtig verstehe, möchtest Du die 01-Ausgaben unterdrücken,
die Protokoll-Daten (addr, cmd, flags) aber ausgeben? Da wird im Code
jedoch nicht unterschieden. Man könnte noch ein ANALYZE-Level oder eine
Maske implementieren, um bestimmte ANALYZE-Ausgaben auszumaskieren.
Bisher bin ich allerdings der Einzige, der irmp überhaupt auf einem Host
nutzt. Von daher habe ich mir über solche Ideen überhaupt keine Gedanken
gemacht.
Was hast Du denn vor?
P.S.
Workaround:
1
./irmp-10kHz <IR-Data/nec.txt | sed 's/.*\(p=\)/\1/g'
Von der AVR-Variante. Da sieht die Ausgabe z.B. aus wie unten; mit
würde ersma die Ausgabe der oberen Zeile genügen.
Momentan stellt sich die Ausgabe auf einem Terminal so dar:
1
protocol: 0x02 NEC address: 0xEF00 command: 0x0003 flags: 0x01
Frank M. schrieb:> - 22.06.2020: Unterstützung von 433MHz Funkprotokollen (RF)
das ist hochinteressant, hat du Kenntnis über die Marmitek IR
Transmitter?
https://www.reichelt.de/marmitek-ir-funkuebertragungssystem-marmitek-08900-p50081.html
Ich habe davon einige im Einsatz, auch eine alte Marmitek FB die sendet
aber mittlerweile zu wenig Platz für Codes hat.
Ein Sendemodul in eine FB zu integrieren wäre klasse.
Ich weiss aber immer noch nicht ob die auf 433 MHz senden oder 866/868
MHz
Die Stabantenne ist bei einem RF Empfänger 17 cm also sieht nach 433MHz
aus und beim anderen 30cm keine Ahnung.
Natürlich kann eine Stabantenne Lambda/4 oder abweichend haben, entweder
mit Verlängerungsspule oder Verkürzungskondensator, ich habe die noch
nicht zerlegt.
Frank M. schrieb:> AVR: ANALYZE-Ausgaben überhaupt nicht sinnvoll, schon gar nicht in einer> ISR.
Keine Ahnung wo Du das ausgibst, ich hab's aktiviert um rauszufinden,
welches Protokoll überhaupt verwendet wird von dem Bleil-Schrott den ich
mir da gekauft habe...
Compiliert hab ich mit
Johann L. schrieb:> Von der AVR-Variante.
Lösung: Auf AVR die lediglich für Debugging-Zwecke gedachte Konstante
ANALYZE nicht verwenden, sondern einfach in main() schreiben:
Johann L. schrieb:> Keine Ahnung wo Du das ausgibst, ich hab's aktiviert um rauszufinden,> welches Protokoll überhaupt verwendet wird von dem Bleil-Schrott den ich> mir da gekauft habe...
Siehe Beispiel aus meinem Beitrag obendrüber.
> Compiliert hab ich mit -DIRMP_LOGGING -DIRMP_PROTOCOL_NAMES> -DF_CPU=22118400UL -DBAUD=19200UL
Wenn Du den Protokollnamen auch noch ausgeben möchtest, dann ändert sich
das obige printf() zu:
1
printf("p=%2d n=%s a=0x%04x c=0x%04x f=0x%x\n",
2
irmp_data.protocol,
3
irmp_protocol_names[irmp_data.protocol],
4
irmp_data.address,
5
irmp_data.command,
6
irmp_data.flags);
> Übrigens wird BAUD im Code 2× hart codiert; ich musste das> auskommentieren um die Baudrate von Kommandozeile aus setzen zu können.
Danke, schaue ich mir an.
Johann L. schrieb:> Compiliert hab ich mit -DIRMP_LOGGING -DIRMP_PROTOCOL_NAMES> -DF_CPU=22118400UL -DBAUD=19200UL
Wirf -DIRMP_LOGGING noch raus, das protokolliert jeden Pegelwechsel.
Brauchst Du aber nicht. Die LOGGING-Routinen sind dafür da, um aus den
IR-Frames Samples auf der Console zu erstellen.
Jetzt weiß ich auch, warum bei Dir 2x BAUD definiert ist. Du benutzt
sowohl die UART-LOGGING-Routinen aus irmp.c als auch die aus
irmp-main-avr-uart.c. Das passt natürlich nicht.
Johann L. schrieb:> Bleil-Schrott
Habs jetzt im Artikel gelesen. ;-)
Ja, das sind billigste Fernbedienungen, die man für 50 Cent beim
Chinesen um die Ecke nachkaufen kann. Die verwenden alle durch die Bank
das NEC-Protokoll mit derselben Adresse 0xFE00. Suchst Du da nach einer
Alternative oder möchtest da selber eine bauen?
Joachim B. schrieb:> das ist hochinteressant, hat du Kenntnis über die Marmitek IR> Transmitter?
Nein.
> Ich habe davon einige im Einsatz, auch eine alte Marmitek FB die sendet> aber mittlerweile zu wenig Platz für Codes hat.
Was heisst das? Ist das eine IR-FB oder eine RF-FB? Wieviele Codes
brauchst Du denn bzw. was machst Du damit? IR empfangen, RF übertragen
und dann wieder als IR ausgeben?
> Ein Sendemodul in eine FB zu integrieren wäre klasse.
Ein RF-Sendemodul? Ich habe mittlerweile auch IRSND prototypisch mit
einem RF-Sender ausgestattet, die Veröffentlichung eines neuen
IRSND-Releases dauert aber noch etwas. Vorher muss ich noch die
Abschaltung der IR-Modulation parametrisieren, damit man das allgemein
verwenden kann.
> Ich weiss aber immer noch nicht ob die auf 433 MHz senden oder 866/868> MHz
Steht im Datenblatt bei Reichelt: Frequency 433.92 MHz.
Schau Dir mal https://www.pollin.de/p/pc-funkfernbedienung-x10-721815
an. Diese Funkfernbedienung hat über 40 Tasten und kann von IRMP
dekodiert werden. Per IRSND könntest Du dann wieder IR-Signale für das
Endgerät (TV o.ä.) generieren.
Frank M. schrieb:> Johann L. schrieb:>> Bleil-Schrott>> Habs jetzt im Artikel gelesen. ;-)>> Ja, das sind billigste Fernbedienungen, die man für 50 Cent beim> Chinesen um die Ecke nachkaufen kann. Die verwenden alle durch die Bank> das NEC-Protokoll mit derselben Adresse 0xFE00. Suchst Du da nach einer> Alternative oder möchtest da selber eine bauen?
Nach ca. 2 Wochen hat das Ding rumgesponnen um nur noch grell türkis zu
leuchten no matter what. Erneuerung der Betterie der Fernbedienung
brachte nix, und als ich das Steuermodul aufgeschraut hatte sah ich dass
ein Transistor offenbar einen auf Geysir gemacht hatte.
Ergo: Die Fernbedienung will ich weiter verwenden aber ein neues
Steuermodul bauen, mit richtig dimensionierten FETs und mit höherer
PWM-Frequenz so dass die LED-Streifen nicht mehr (merklich) flackern,
also > 200 Hz oder so.
Johann L. schrieb:> Die Fernbedienung will ich weiter verwenden aber ein neues Steuermodul> bauen
Danke für die Info. Läuft der IRMP denn nun bei Dir wunschgemäß? Sollten
noch Probleme auftreten, melde Dich einfach.
Frank M. schrieb:> Johann L. schrieb:>> Die Fernbedienung will ich weiter verwenden aber ein neues Steuermodul>> bauen>> Danke für die Info. Läuft der IRMP denn nun bei Dir wunschgemäß? Sollten> noch Probleme auftreten, melde Dich einfach.
War easy zum Laufen zu bringen, und NEC-Protokoll (0x2) wird auch
erkannt; RC5 allerdings nicht, z.B.
Frank M. schrieb:> Nein.
schade
Frank M. schrieb:> Was heisst das? Ist das eine IR-FB oder eine RF-FB? Wieviele Codes> brauchst Du denn bzw. was machst Du damit? IR empfangen, RF übertragen> und dann wieder als IR ausgeben?
genaugenommen habe ich 2
1.
https://cdn-reichelt.de/documents/datenblatt/X600/Powermid_XL.pdf
die konnte eh zu wenig Code lernen und speichern, schon nach der Hälfte
der angelernten Tasten war der Speicher voll.
2. dito
https://www.bedienungsanleitu.ng/thumbs/products/l/84244-marmitek-easy-icon-10-rf.jpg
Trotz toller Multiauswahl mit Display, nach nur einer FB mit halben
Tastencodes war Schluß.
Beide lernen IR und senden IR und RF, die Empfänger im Wohnzimmer senden
dann IR an die Video/DVD Recorder, || Pause, > Play, << fast rewind, >>
fast wind, STOP.
Frank M. schrieb:> Steht im Datenblatt bei Reichelt: Frequency 433.92 MHz.
wozu dann 30cm Antenne, ach egal!
Frank M. schrieb:> Schau Dir mal https://www.pollin.de/p/pc-funkfernbedienung-x10-721815> an.
gerne, nur wie hoch ist deren Speicher?
Ich bin ja was Speichertiefe bei beiden Marmitek reingefallen, wenn die
nicht mal Platz für alle eigenen Tasten Codes aufnehmen?
Ich verlange ja nicht mal das mehr Tasten etwa soviel wie die
angelernten FB benutzt werden können als die RF FB besitzt, aber
mindestens die sollten doch belegt werden können.
Bis jetzt habe ich mir den Bau eines IRSND sparen können, weil ich
daheim gerne die Pyramiden nutze, soll ja nicht eine never ending
Bastelstunde werden ohne Gehäuse wie meine 433 MHz Rolladen
Fernbedienungen vom nano.
v1 2015
https://www.mikrocontroller.net/attachment/276364/rolladen.jpg
v2 2017 Anhang Bild
Joachim B. schrieb:> Frank M. schrieb:>> Schau Dir mal https://www.pollin.de/p/pc-funkfernbedienung-x10-721815>> an.>> gerne, nur wie hoch ist deren Speicher?
Die hat gar keinen, sie ist nicht anlernbar. Die Intelligenz müsstest Du
schon in IRMP (empfangen der Funksignale) und anschließendem Senden per
IRSND reinstecken. Gewiss sollte da der Speicher eines entsprechenden
AVR-µCs ausreichen.
Johann L. schrieb:> War easy zum Laufen zu bringen, und NEC-Protokoll (0x2) wird auch> erkannt; RC5 allerdings nicht,
Das wundert mich aber, das ist eines der bestgetesteten Protokolle. Du
hast RC5 auch in irmpconfig.h freigeschaltet?
Frank M. schrieb:> Die hat gar keinen,
also nur ein FB Gehäuse?
Das verstehe ich gerade nicht!
der Link funktioniert nicht
Verfügbare Downloads:
Download Beschreibung
am raspi ging es!
egal aber heftig
2,25 € 3 Stk
5,95 € Versandkosten
----
8,20€
bestellt, nun erst mal lesen!
"Ist der Funkkanal des Empfängers bekannt, stellen Sie die Fernbedienung
wie unten beschrieben auf den entsprechenden
Funkkanal ein.
1. SELECT-Taste drücken bis die LED erlischt (ca. 5 Sekunden).
2. Die Häufigkeit des LED-Blinkens entspricht dem eingestellten Kanal
(1...16)
3. Die LED leuchtet nach dem Blinken dauerhaft - ein neuer Kanal kann
jetzt vergeben werden
4. Zum Ändern des Kanals die gewünschte Kanalnummer mit der
Fernbedienungstastatur eingeben (1...16)
und mit der SELECT-Taste bestätigen.
5. Die LED blinkt erneut in der Häufigkeit des neu eingestellten Kanals
6. Der gewünschte Kanal ist jetzt aktiv - die Fernbedienung kann
verwendet werden
Ich verstehe immer noch Bahnhof....
Ein AVR mit IRSND hat keinen Funkempfänger, ein Nano keinen Port für USB
Kanäle muss ich in der FB vergeben?
Wie soll denn mit IRSND eine RF IR Brücke werden?
Joachim B. schrieb:> also nur ein FB Gehäuse?> Das verstehe ich gerade nicht!
Nein. Eine FB die statt IR 433MHz nutzt. Das Protokoll kennt irmp und
das wars. Den 433MHz Empfänger brauchste noch...
Klaus.
Joachim B. schrieb:> Wie soll denn mit IRSND eine RF IR Brücke werden?
Ich denke schon länger eher über einen BT -> IR / RF Hub
nach...allerdings sind die Protokolle meiner Funksteckdose eher komplex
und ne SCHÖNE BT app braucht auch Zeit. Dann wär endlich alles übers
smartphone Bedienbar und die FB immer "dabei".
Gibts da schon ein Projekt?
Klaus.
Joachim B. schrieb:> Frank M. schrieb:> Die hat gar keinen,>> also nur ein FB Gehäuse?> Das verstehe ich gerade nicht!
Ich meinte: Die FB hat keine Möglichkeit, etwas anzulernen. Die Codes,
die sie absendet, sind fix.
> "Ist der Funkkanal des Empfängers bekannt, stellen Sie die Fernbedienung> wie unten beschrieben auf den entsprechenden> Funkkanal ein.
Brauchst Du nicht zu machen, die Dinger funktionieren out-of-the-box.
Einfach Batterien rein und fertig.
> Wie soll denn mit IRSND eine RF IR Brücke werden?
RF-Sender -----> RF-Empfänger -----> IR-Sender -------> TV
Den RF-Empfänger und IR-Sender packst Du mittels IRMP/IRSND auf einen
µC.
Joachim B. schrieb:> also sowas:> https://www.ebay.de/i/173291278318
Jepp, die RXB6-Module (Stichwort Superheterodyne) sind ganz gut, vor
allem sind sie trennschärfer als die Pendelaudion-Empfänger, welche auch
den ganzen Müll mit aufsaugen. Allerdings haben sie einen kleinen
Nachteil: Sie verschlucken meist die ersten ein bis zwei Bits vom ersten
gesandten Frame. Es dauert wohl ein wenig, bis sie sich eingeschossen
haben. Macht aber nichts: Alle RF-Sender, die ich kenne, wiederholen die
Daten ständig, solange Du den Finger auf dem Knopf hältst. Der zweite
Frame wird dann von IRMP einwandfrei erkannt.
> Mit den Sendern:> Ebay-Artikel Nr. 232682854622> kann man ja arbeiten, die nutze ich selber, die dazugehörigen Empfänger> sind für den Elektronik Schrott!
Ja, das sind die Pendelaudion-Empfänger, die sehr störanfällig sind.
Allerdings verschlucken sie keine Daten wie die RXB6. IRMP wird durch
die vielen Störimpulse zwar etwas mehr beschäftigt, kann aber bereits
den ersten Frame sauber erkennen. Die Decodierung ist hier also ein
wenig schneller.
Insgesamt plädiere ich auch für die Superheterodyne-Empfänger. Muss aber
nicht unbedingt ein RXB6 sein, die RXB8-Module sollen ähnlich gut sein,
sind aber von mir noch ungetestet.
Ein Stück Draht von 17 cm Länge als Antenne hilft ungemein, wenn man
mehr als nur 1-2 Meter überbrücken möchte.
Johann L. schrieb:> RC5 allerdings nicht,> z.B.00000000000000011111111111100000000000000111111111111000000000000000
000000000000
> 001111111111110000000000000011111111111100000000000000011111111111100000
00000000
> 001111111111100000000000000011111111111100000000000000011111111111100000
00000000
> 011111111111100000000000000011111111111100000000000000011111111111100000
00000000
> 0111111111111111111111111100000000000000011111111111111111111>
Ich habe gerade mal die obigen Daten in einer Text-Datei "d.txt"
gespeichert und irmp drüber laufen lassen:
Dein RC5-Frame wird also einwandfrei erkannt. Ich kann mir da nur zwei
Konstellationen vorstellen:
1. RC5 ist nicht freigeschaltet in irmpconfig.h
2. Du hast noch weitere Protokolle freigeschaltet, wobei eines der
anderen bzgl. Startbit als Kriterium zur Protokollauswahl in Konflikt
mit RC5 steht.
Mir ist allerdings kein anderes Protokoll aus dem Kopf bekannt, welches
mit RC5 bzgl. Startbit kollidiert. Hier wäre interessant zu wissen,
welche IR-Protokolle Du in irmpconfig.h freigeschaltet hast.
Klaus R. schrieb:> Ich denke schon länger eher über einen BT -> IR / RF Hub> nach...allerdings sind die Protokolle meiner Funksteckdose eher komplex> und ne SCHÖNE BT app braucht auch Zeit. Dann wär endlich alles übers> smartphone Bedienbar und die FB immer "dabei".>> Gibts da schon ein Projekt?
Ich habe so etwas mal gemacht vor 5 Jahren:
https://www.mikrocontroller.net/articles/Remote_IRMP
Das Projekt könnte man nochmal aufleben lassen.
Zu den "komplexen RF-Protokollen" Deiner Funksteckdose: Du könntest mit
dem aktuellen IRMP mal Samples erstellen.
Einen RF-Empfänger an den aktuellen IRMP und
1
#define IRMP_LOGGING 1
2
#define IRMP_HIGH_ACTIVE 1
einstellen und dann die gesampelten Frames per Terminalemulation (PuTTY)
kopieren.
Frank M. schrieb:> Johann L. schrieb:>> RC5 allerdings nicht,>>> z.B.00000000000000011111111111100000000000000111111111111000000000000000
000000000000
>> 001111111111110000000000000011111111111100000000000000011111111111100000
00000000
>> 001111111111100000000000000011111111111100000000000000011111111111100000
00000000
>> 011111111111100000000000000011111111111100000000000000011111111111100000
00000000
>> 0111111111111111111111111100000000000000011111111111111111111>>>> Ich habe gerade mal die obigen Daten in einer Text-Datei "d.txt"> gespeichert und irmp drüber laufen lassen:
> Dein RC5-Frame wird also einwandfrei erkannt. Ich kann mir da nur zwei> Konstellationen vorstellen:>> 1. RC5 ist nicht freigeschaltet in irmpconfig.h
Ich hab den default verwendet (bis auf BAUD), und da ist RC5 wohl nicht
daber...
Nochwas zum Coding:
Die Variablen im Static Storage sind meist frei flottierende 8-Bit,
16-Bit oder 32-Bit Werte. Fasst man dieser zu einer Struktur zusammen
und greift indirekt darauf zu, kann man einiges an Code(größe) sparen
ohne den Code langsamer zu machen.
Beispiel für AVR ATmega168 mit allen Protokollen aktiviert (und Warings
ignoriert):
Direkter Zugriff: 8256 Bytes
Indirekt Zugriff: 6964 Bytes (85% Codegröße)
Aktiviere ich nur NEC, das Protokoll auf das ich's abgesehen hab, dann:
Direkter Zugriff: 1978 Bytes
Indirekt Zugriff: 1656 Bytes (84% Codegröße)
Compiliert mit avr-gcc-v8 -Os (ohne LTO).
Anbei ein Delta, welches das Prinzip zeigt.
Zugriff ist:
1
irmp_t*ir=&irmp;
2
__asm("":"+r"(ir));
3
4
if(ir->ir_detected)
5
{
6
switch(ir->protocol)
7
...
etc. anstatt auf irmp_protocol im Original
Das __asm dient dazu, die Adresse von irmp vor GCC zu verstecken.
Kommentiert man das __asm aus, etwa per
1
#define __asm(...) (void) 0
so steigt die Codegröße auf den Wert für (direkter Zugriff) weil GCC
trotz indirekter Adressierung die Adresse kenn (bzw. Offset auf Symbol
irmp ).
_______________
Und es gibt ganz viele Codestellen ähnlich der folgenden:
Man könnte den Code alse etwas kompakter schreiben, indem man das #ifdef
ANALYZE einfach rauswirft.
Je nach Code kann das Warnings geben, etwa wenn die einzige Verwendung
einer (lokalen) Variablen als Argument von ANALYZE_PRINTF ist. In dem
Fall kann man folgendes machen:
1
#ifdef ANALYZE
2
staticconstboolanalyze=true;
3
#else
4
staticconstboolanalyze=false;
5
#endif
6
7
#define ANALYZE_PRINTF(...) \
8
do { \
9
if (analyze) if (verbose) printf (__VA_ARGS__); } \
Johann L. schrieb:> Zugriff ist: irmp_t *ir = &irmp;
Danke erstmal für den Tipp.
> Das __asm dient dazu, die Adresse von irmp vor GCC zu verstecken.> Kommentiert man das __asm aus, etwa per#define __asm(...) (void) 0> so steigt die Codegröße auf den Wert für (direkter Zugriff) weil GCC> trotz indirekter Adressierung die Adresse kenn (bzw. Offset auf Symbol> irmp ).
Das klappt dann aber nur für avr-gcc. Für die anderen µCs lasse ich dann
das asm-Statement weg - wobei dann für diese µCs nichts gewonnen ist,
richtig?
> Man könnte den Code alse etwas kompakter schreiben, indem man das #ifdef> ANALYZE einfach rauswirft.
Genau das_ hatte ich vorher genau _so gemacht, nämlich so:
1
#else
2
# define ANALYZE_PUTCHAR(a)
3
# define ANALYZE_ONLY_NORMAL_PUTCHAR(a)
4
# define ANALYZE_PRINTF(...)
5
# define ANALYZE_ONLY_NORMAL_PRINTF(...)
6
# define ANALYZE_NEWLINE()
Dann konnte man einfach schreiben:
1
...
2
analyze_printf(foo,bar);
3
...
Du findest diese leeren Macros sogar noch in irmp.c, aber nur nur noch
in auskommentierter Form:
1
/******************************* not every C compiler knows variadic macros :-(
2
#else
3
# define ANALYZE_PUTCHAR(a)
4
# define ANALYZE_ONLY_NORMAL_PUTCHAR(a)
5
# define ANALYZE_PRINTF(...)
6
# define ANALYZE_ONLY_NORMAL_PRINTF(...)
7
# endif
8
# define ANALYZE_NEWLINE()
9
*********************************/
10
#endif
Das Problem: Nicht jeder Compiler kennt Variadic Macros, z.B. der
PIC-Compiler. Aus diesem Grund hatte ich dann nachträglich alle Aufrufe
von irgendwelchen analyze_printf() nochmal durch diese wirklich
unschönen Blöcke
1
#ifdef ANALYZE
2
analyze_printf(foo,bar);
3
#endif // ANALYZE
zusätzlich gekapselt, was den Source dann richtig hässlich macht.
Sag mir, wie ich das durch einen NON-gcc in der Variante, dass ANALYZE
"#undefed" ist, bekomme und ich machs - sogar sehr gern.
P.S.
Beispiel: Der PIC-Compiler XC8 kann "nur" C89, Variadic Macros gibt es
erst ab C99.
Der Aufruf eines solchen Makros müsste dann immer mit Doppelklammern
erfolgen, also:
1
analyze_printf((foo,bar));
Das wäre aber nicht dramatisch.
Wer hat einen XC8-Compiler für PIC und möchte das mal mit mir zusammen
testen? Ich würde dann eine modifizierte Variante von irmp.c zur
Verfügung stellten.
Ziel ist es, diese analyze_printf() -Aufrufe samt Evaluierung aller
Argumente vom Compiler komplett eliminieren zu lassen. Ich hoffe, dass
der nicht gerade durch "Intelligenz" bestechende XC8 das packt. Nicht,
dass er die Parameter noch ausrechnet oder gar Stringkonstanten im Flash
hinterlegt, obwohl sie dann gar nicht genutzt werden.
EDIT:
Alternative wäre, in die Steinzeit zurückzugehen, und für jede
verschiedene Anzahl von Argumenten ein eigenes analyze_printf() zu
bauen, also
1
#define analyze_printf1(fmt) printf(fmt)
2
#define analyze_printf2(fmt,a) printf(fmt,a)
3
#define analyze_printf3(fmt,a,b) printf(fmt,a,b)
4
usw.
Aber schön ist das nicht, zumindest auf dem Host (Linux, Windows) könnte
man die Variadic Macros bzw. die oben skizzierte Alternative durchaus
nutzen.
Frank M. schrieb:> Johann L. schrieb:>> Zugriff ist: irmp_t *ir = &irmp;>> Danke erstmal für den Tipp.>>> Das __asm dient dazu, die Adresse von irmp vor GCC zu verstecken.>> Kommentiert man das __asm aus, etwa per#define __asm(...) (void) 0>> so steigt die Codegröße auf den Wert für (direkter Zugriff) weil GCC>> trotz indirekter Adressierung die Adresse kenn (bzw. Offset auf Symbol>> irmp ).>> Das klappt dann aber nur für avr-gcc. Für die anderen µCs lasse ich dann> das asm-Statement weg - wobei dann für diese µCs nichts gewonnen ist,> richtig?
Ich glaub nicht dass das für andere µCs was bringt. Je nachdem wie
schlecht der Compiler optimiert könnte es sogar kontraproduktiv sein.
>> Man könnte den Code also etwas kompakter schreiben, indem man das #ifdef>> ANALYZE einfach rauswirft.> [...]> Das Problem: Nicht jeder Compiler kennt Variadic Macros, z.B. der> PIC-Compiler.> Sag mir, wie ich das durch einen NON-gcc in der Variante, dass ANALYZE> "#undefed" ist, bekomme und ich machs - sogar sehr gern.
Evtl. so? Braucht dann auch keine 2fach-Klammerung, ist allerdings nur
ein "normales" Makro, kein function-like:
Nochwas: Kann man irgendwie Platz sparen, wenn nur 1 Protokoll genbaucht
wird und dieses zur Compilezeit bekannt ist? In irmp_ISR() gibt's ja
folgendes:
Johann L. schrieb:> Ich glaub nicht dass das für andere µCs was bringt. Je nachdem wie> schlecht der Compiler optimiert könnte es sogar kontraproduktiv sein.
Hm, dann ist es wohl nicht sinnvoll, wenn ich allgemein auf
1
irmp_t*ir=&irmp;
umstelle. Zwei unterschiedliche Schreibweisen im gleichen Source machen
den Code dann noch unansehlicher. Ich könnte mir da höchstens einen
Trick per Preprocessor-Makro vorstellen. Irgendwann besteht der Code aus
mehr Preprocessor-Makros als aus C-Code ;-)
> Evtl. so? [...]> #define analyze_printf (void)
Danke, das ist schön einfach und ohne Ecken und Kanten. Gefällt mir!
Ich habe es nun so gemacht:
#if defined (__XC8) // XC8 does not support variadic macros
14
# define ANALYZE_PRINTF (void)
15
# define ANALYZE_ONLY_NORMAL_PRINTF (void)
16
#else
17
# define ANALYZE_PRINTF(...)
18
# define ANALYZE_ONLY_NORMAL_PRINTF(...)
19
#endif
20
# define ANALYZE_NEWLINE()
21
#endif
Meines Wissens nach ist XC8 der einzige Compiler, der "nur" C89. Sollten
doch noch andere betroffen sein, kann man die ja noch anfügen.
Damit sind die Blöcke
1
#ifdef ANALYZE
2
...
3
#endif // ANALYZE
weggefallen und es konnten ca. 350 Zeilen eingespart werden :-)
Johann L. schrieb:> Kann man irgendwie Platz sparen, wenn nur 1 Protokoll genbaucht wird und> dieses zur Compilezeit bekannt ist?
Puh, um festzustellen, ob genau ein Protokoll aktiviert ist, müsste man
alle IRMP_SUPPORT_XXX-Konstanten zusammenaddieren, also:
1
#if IRMP_SUPPORT_SIRCS_PROTOCOL + \
2
IRMP_SUPPORT_NEC_PROTOCOL + \
3
... + \
4
IRMP_SUPPORT_RF_X10_PROTOCOL == 1
5
#define IRMP_ONLY_ONE_PROTOCOL_USED 1
6
#else
7
#define IRMP_ONLY_ONE_PROTOCOL_USED 0
8
#endif
Heftig!
> In irmp_ISR() gibt's ja folgendes:> if (ir->isr.start_bit_detected)> {> memcpy_P (&irmp.param, irmp_param_p, sizeof (IRMP_PARAMETER));>> Der Inhalt von irmp.param ändert sich also nicht (mehr) und ist zur> Compilezeit bekannt weil irmp_param_p zur Compilezeit bekannt ist?
Ich mache übrigens den memcpy()-Call, um die anschließenden Zugriffe auf
die Daten zu beschleunigen, da meiner Erfahrung nach ein Pointerzugriff
im allgemeinen langsamer ist. Ich hätte nämlich hier auch einfach einen
Pointer setzen können.
Meinst Du, der Aufwand rechtfertigt so etwas? Da kann man alternativ
auch einen IRMP-Codegenerator schreiben, der einem den IRMP-Source aus
der Konfiguration generiert. Der könnte dann auch µC-spezifisch
optimiert werden, wie zum Beispiel Dein ir-Pointer für AVR. Auf die
Preprocessor-Schlacht könnte man dann größtenteils verzichten.
Frank M. schrieb:> Johann L. schrieb:>> Kann man irgendwie Platz sparen, wenn nur 1 Protokoll gebraucht wird und>> dieses zur Compilezeit bekannt ist?>> Puh, um festzustellen, ob genau ein Protokoll aktiviert ist, müsste man> alle IRMP_SUPPORT_XXX-Konstanten zusammenaddieren, also:
Ich dachte eher an sowas: Ich weiß dass ich nur 1 Protokoll verwende
und wollte fragen, was ich lokal bei mir ändern muss um (noch mehr)
Platz zu sparen.
Wprd gerne nen ATtiny24 verwenden. Der Code passt da zwar locker rein,
aber es soll ja mehr auf den µC als IR-Auswertung...
>> In irmp_ISR() gibt's ja folgendes:>> if (ir->isr.start_bit_detected)>> {>> memcpy_P (&irmp.param, irmp_param_p, sizeof (IRMP_PARAMETER));>>>> Der Inhalt von irmp.param ändert sich also nicht (mehr) und ist zur>> Compilezeit bekannt weil irmp_param_p zur Compilezeit bekannt ist?>> Ich mache übrigens den memcpy()-Call, um die anschließenden Zugriffe auf> die Daten zu beschleunigen, da meiner Erfahrung nach ein Pointerzugriff> im allgemeinen langsamer ist. Ich hätte nämlich hier auch einfach einen> Pointer setzen können.
irmp.param const zu machen funktioniert nicht, bzw. da werden wohl
einige Werte gepatcht :-(
Verwenden würde ich __flash. Das ist im Gegensatz zu pgm_read_xxx
nämlich transparent: Zum Beispiel compiliert
1
typedefstruct{inta,b,c;}abc_t;
2
3
const__flashabc_tabc={1234,5678,9012};
4
5
intadd(intx)
6
{
7
const__flashabc_t*p=&abc;
8
returnx+p->b+1;
9
}
zu:
1
add:
2
subi r24,-47
3
sbci r25,-23
4
ret
d.h. der Wert muss zu Laufzeit garnicht mehr aus dem Flash geladen
werden und kann in Immediates versacken wie hier.
> Meinst Du, der Aufwand rechtfertigt so etwas? Da kann man alternativ> auch einen IRMP-Codegenerator schreiben, der einem den IRMP-Source aus> der Konfiguration generiert.
Was dann freilich ein komplett neues Projekt wäre... Und nicht unbedingt
übersichtlicher? Unterschiedliche Protokolle, unterschiedliche
Controller / Hosts, unterschiedliche Compiler, ...
> Der könnte dann auch µC-spezifisch> optimiert werden, wie zum Beispiel Dein ir-Pointer für AVR. Auf die> Preprocessor-Schlacht könnte man dann größtenteils verzichten.
Ja, das würe es auf jeden Fall übersichtlicher machen. Und in welcher
Sprache? Python?
Johann L. schrieb:> Python?
ich bekomme Angst, wenn ich an die unterschiedliche Einrückung denke
TABS SPACES, mal mehr mal weniger Python v2 v3?
neee Python NEVER
Johann L. schrieb:> Aktiviere ich nur NEC, das Protokoll auf das ich's abgesehen hab, dann:>> Direkter Zugriff: 1978 Bytes> Indirekt Zugriff: 1656 Bytes (84% Codegröße)
Ich komme mit avr-gcc V4.7.2 für ATtiny24 und nur NEC mit dem
Original-Source aus dem SVN auf:
1
avr-size irmp.elf
2
text data bss dec hex filename
3
1284 4 39 1327 52f irmp.elf
(LTO eingeschaltet)
Das sind 64% Codegröße. Mit Deiner Optimierung über den direkten Zugriff
dürfte das noch besser ausfallen.
Sind die neueren avr-gcc sooo viel schlechter geworden?
Protokoll:
Johann L. schrieb:> Wprd gerne nen ATtiny24 verwenden. Der Code passt da zwar locker rein,> aber es soll ja mehr auf den µC als IR-Auswertung...
Immer diese Selbstquälerei, nimm einfach einen ATtiny44 ;-)
Okay, ich schaue noch, was sich machen ließe. Ich habe mal testweise den
memcpy_P() auskommentiert, um zu sehen, was man maximal rausholen
könnte. Brachte 60 Bytes Ersparnis, also nicht die Welt.
Ich persönlich halte den avr-gcc 4.7.2 immer noch für den besten. Alle
neuere Versionen erzeugen größeren Code.
Frank M. schrieb:> Ich persönlich halte den avr-gcc 4.7.2 immer noch für den besten. Alle> neuere Versionen erzeugen größeren Code.
ist mir auch aufgefallen, ich hatte gerade mal die Versionnummer
ausgeben lassen, der Alte macht das schon gut!
Joachim B. schrieb:> Johann L. schrieb:>> Python?>> ich bekomme Angst, wenn ich an die unterschiedliche Einrückung denke> TABS SPACES, mal mehr mal weniger
Mit einem vernünftigen Editior wie z.B. Emacs merkst du davon überhaupt
nix. Emacs etwa erkennt automatisch wie eingerückt wurde und verwendet
dieses Einrück-Schema.
Einrückung als Teil der Semantik ist vielleicht keine Sternstunde des
eines Sprachdesigns, aber immerhin vermeidet es Flame-Wars was denn die
richtige Einrückung sei und wo { oder } zu klatzieren seien.
Emacs fügt bei TAB auch kein Tab ein, sondern geht zu der entsprechenden
Einrückung (auch in C / C++ etc.). Falls die Syntax mehrere
Möglichkeiten bietet, iteriert Emacs sie bei TAB durch.
Alles easy und transparent. Vielleicht etwas ungewohnt, aber deshalb
schreiend vor einer Spache wegrennen...?
> Python v2 v3?
Schreib den Code einfach so, dass er für Python v2.7 und v3 passt. Bei
> 95% der Anwendungen genügt dafür als erste Zeile (nach einem evtl.
Shebang)
1
from __future__ import print_function
so dass print in v3-Syntax zu stehen hat.
> neee Python NEVER
Während man in VillalC++ noch in Spezifikation, cppreference.com und
cplusplus.com wühlt und sich die Haare rauft, ist man in VillaPython
schon am feiern :-)
Frank M. schrieb:> Johann L. schrieb:>> Aktiviere ich nur NEC, das Protokoll auf das ich's abgesehen hab, dann:>>>> Direkter Zugriff: 1978 Bytes>> Indirekt Zugriff: 1656 Bytes (84% Codegröße)>> Ich komme mit avr-gcc V4.7.2 für ATtiny24 und nur NEC mit dem> Original-Source aus dem SVN auf:>
1
> avr-size irmp.elf
2
> text data bss dec hex filename
3
> 1284 4 39 1327 52f irmp.elf
4
>
> (LTO eingeschaltet)>> Das sind 64% Codegröße. Mit Deiner Optimierung über den direkten Zugriff> dürfte das noch besser ausfallen.>> Sind die neueren avr-gcc sooo viel schlechter geworden?
Hier mal meine Codegrößen (in Byte), mit den indirekten Zugriffen wie
oben:
1
v4.7: 1618
2
v4.9: 1576
3
v7: 1558
4
v8: 1552
Der kleinste Code ist also mit v8, und v4.7 liefert den größten.
Übersetzt für einen ATmege168 weil sich irmp-main-avr-uart.c nicht ohne
weiters für einen ATtiny24/44/84 übersetzen lässt, vermutlich wegen USI.
Optimierungsoptionen:
für irmp.c und irmp-main-avr-uart.c.
> Okay, ich schaue noch, was sich machen ließe. Ich habe mal testweise den> memcpy_P() auskommentiert, um zu sehen, was man maximal rausholen> könnte.
Das problem ist nicht das memcpy_p, das brauch ja ein paar
Instruktionen.
Der Haken ist wie gesagt, dass pgm_read_xxx nicht transparent ist, d.h.
Flash-Zugriffe auf bekannte Adressen im Gegensatz zu __flash nicht
wegoptimiert werden (können).
> Brachte 60 Bytes Ersparnis, also nicht die Welt.> Ich persönlich halte den avr-gcc 4.7.2 immer noch für den besten. Alle> neuere Versionen erzeugen größeren Code.
Siehe oben.
Frank M. schrieb:> Johann L. schrieb:>> Würd gerne nen ATtiny24 verwenden. Der Code passt da zwar locker rein,>> aber es soll ja mehr auf den µC als IR-Auswertung...>> Immer diese Selbstquälerei, nimm einfach einen ATtiny44 ;-)
Hab hier noch nen ATtiny24 und 'nen LED-Streifen anzusteuern ist ja
keine Rocket-Science...
Wird ausgenutzt, dass nur 1 Protokoll (NEC) verwendet wird, schrumpft
der Code um 150 Bytes, und ohne UART wird er um weitere 300 Byte
kleiner.
Das memcpy_P ist dabei noch nicht aufgelöst; "Problem" von NEC ist, dass
es eigentlich 2 Protokolle sind: eines für "normale" Codes und eines für
Widerholungen. Löse ich die Gemainsamkeiten von nec_param und
nec_rep_param auch noch auf, komme ich auf unter 1000 Bytes Code. Wird
also lockerst in einen ATtiny24 passen :-)
Schönes Projekt!
Nur aus Interesse:
Gibt es einen bestimmten Grund warum der Receiver Pin so oft abgefragt
wird (10-20kHz), anstatt die Pegeländerungen mit einem Interrupt zu
detektieren und in der Interrupt Routine die Zeit zwischen den Aufrufen
zu messen?
Könnte man sich da nicht einiges an Prozessorlast sparen?
Lorand U. schrieb:> Gibt es einen bestimmten Grund warum der Receiver Pin so oft abgefragt> wird (10-20kHz), anstatt die Pegeländerungen mit einem Interrupt zu> detektieren und in der Interrupt Routine die Zeit zwischen den Aufrufen> zu messen?> Könnte man sich da nicht einiges an Prozessorlast sparen?
1. Nicht alle Protokolle lassen sich mit der Interrupt Methode erkennen,
das Problem ist die Erkennung wann das Protokoll zu Ende ist.
2. Die Arduino Library Version von IRMP https://github.com/ukw100/IRMP
hat die Interrupt Methode eingebaut!
Armin J. schrieb:> 1. Nicht alle Protokolle lassen sich mit der Interrupt Methode erkennen,> das Problem ist die Erkennung wann das Protokoll zu Ende ist.
Das versteh ich nicht.
Wenn eine gewisse Zeit lang kein Pinchange mehr passiert, weiß ich dass
das Signal zuende ist.
Genauso ist es aber auch wenn ich alle 50µs (20kHz) den Pin abfrage.
Erst wenn eine gewisse Zeit der Pin nicht mehr auf LOW geht, weiß ich
dass das Signal zuende ist.
Außer ich hab das Protokoll schon so weit analysiert, dass ich schon
weiß, dass nichts mehr kommen wird. Aber das ist auch bei beiden
Methoden gleich.
Überseh ich da irgendwas?
Lorand U. schrieb:> Wenn eine gewisse Zeit lang kein Pinchange mehr passiert, weiß ich dass> das Signal zuende ist.
Das ist korrekt:
Mit einer Kombination aus Pinchange-Interrupt und zusätzlichem Timer
als Timeout-Detector kann man die Prozessor-Last durchaus reduzieren.
Ohne Timer geht es aber nicht, weil sonst diverse Timeouts (z.B. bei
gleichzeitigem Verfolgen von verschiedenen Protokollen bzw.
Frame-Längen) nicht erkannt werden können und die Statemachine dann
"steckenbleiben" kann.
Das IRMP-Projekt ist allerdings vor mehr als 10 Jahren entstanden, da
hatten noch längst nicht alle AVRs beliebig viele Pins, die man für
Pinchange-Detektion einsetzen konnte. Da gab es beispielsweise nur INT0
(und INT1), z.B. für den damals doch recht beliebten ATmega8.
So habe ich mich damals für die alleinige Timer-Nutzung entschieden,
damit IRMP möglichst breit einsetzbar ist. Das betrifft nicht nur eine
Prozessorfamilie (z.B. AVRs), sondern auch die Portierung auf andere µC
Architekturen. Der Code würde heute durch zusätzliche Verwendung von
Pinchange-Interrupts noch komplizierter werden, als er schon ist: Für
jede Prozessorfamilie kämen dann nochmal die Interrupt-Handler hinzu.
Die Prozessorlast ist auch tatsächlich niedriger, als die Programmgröße
es vermuten lässt. Es werden pro Timeraufruf jeweils nur kleine
Bruchstücke der recht umfangreichen Statemachine durchlaufen. So hält
sich die Prozessorlast doch sehr in Grenzen.
Du kannst natürlich gern die entsprechenden Interrupt-Handler für die
aktuell unterstützten µCs beisteuern und den dazugehörenden
Timer-Interrupt neu erstellen. Ich freue mich dann auf Deinen Code :-)
Frank M. schrieb:> Die Version 3.2.0 ist online.> - 22.06.2020: Unterstützung von 433MHz Funkprotokollen (RF)
Ich habe mal die Medion PC Fernbedienung 20018071, die man schon ab 3€
bei Ebay(Kleinanzeigen) bekommt, analysiert.
Mit den folgenden Werten läuft es gut, ich habe dafür einach mal die
Telefunken Definition missbraucht. Es läuft übrigens mit allen 40
anderen IR Protokollen aus dem AllProtocol Example gleichzeitig, man
muss sie nicht disablen.
1
#define TELEFUNKEN_START_BIT_PULSE_TIME 3960.0e-6 // 4 ms usec pulse
Die Daten müssen aber anders als oben spezifiziert interpretiert werden:
Die oberen 8 Bit der Adresse sind die Command + 0x2B also Checksum oder
Plausi und die letzten 4 Bit der Adresse sind immer 0.
Command sind die ersten Bits, da sind die oberste Taste dann 01, 02 und
die Zahlen Tasten sind (Zahl + E1).
Wie kann mas das in IRMP aufnehmen, und sollte man das überhaupt?
Gruß
Armin
Armin J. schrieb:> Ich habe mal die Medion PC Fernbedienung 20018071, die man schon ab 3€> bei Ebay(Kleinanzeigen) bekommt, analysiert.
Ist das die X10 von Pollin für 75 Cent oder ein ähnliches Modell? Nach
den Anleitungen/Bildern, die ich für Deine PC Fernbedienung gefunden
habe, scheint sie sehr ähnlich zu arbeiten, nur mit anderen Timings.
Die Beschreibung, wie der Funkkanal geändert werden kann, entspricht der
X10 von Pollin, welches übrigens auch ein Medion-Modell ist.
> Die Daten müssen aber anders als oben spezifiziert interpretiert werden:> Die oberen 8 Bit der Adresse sind die Command + 0x2B also Checksum oder> Plausi und die letzten 4 Bit der Adresse sind immer 0.
Das passt zwar besser als meine erste Beschreibung, stimmt aber trotzdem
nicht ganz. ;-)
Mittlerweile habe ich die X10 mittlerweile vollständig entschlüsselt,
nachdem ich mal testweise die Funkkanäle gewechselt habe. Wie das geht,
steht in der Anleitung von Pollin.
Heraus kommt der folgende Aufbau:
- 1 toggle bit
- 7 checksum bits
- 1 toggle bit
- 7 command bits
- 4 channel bits
Die letzten 4 Bits sind nur dann 0, wenn Funkkanal 1 eingestellt ist.
Für die Funkkanäle 1-16 findest Du in den letzten 4 Bits nämlich die
entsprechenden Werte 0-15, wenn Du mal den Funkkanal wechselst.
Dabei gilt für die Checksum:
Anhand des Ausprobierens verschiederner Funkkanäle konnte ich
feststellen, dass das Kommando beileibe nicht vorne im Frame steckt,
sondern erst die Checksum kommt, dann das Kommando und am Ende der
Funkkanal.
Zweite wichtige Erkenntnis: Der Wert der Checksum ist abhängig vom
gewähltem Funkkanal! (siehe auch "Formel" oben)
> Wie kann mas das in IRMP aufnehmen, und sollte man das überhaupt?
Ich habe es in der neuen Fassung für die X10 folgendermaßen gemacht:
1
In der ISR:
2
1. Checksum in irmp_address gespeichert
3
2. Kommando inkl. 4 Funkkanal-Bits in irmp_command gespeichert
4
5
In irmp_get_data():
6
1. Checksum nach obiger Regel geprüft.
7
2. 4 Funkkanal-Bits nach irmp_address kopiert
8
3. Kommando um 4 Bits nach rechts geschoben
Damit wird in irmp_addr der Funkkanal gespeichert. Diesen bekommt man
dann per irmp_get_data() frei Haus mitgeliefert.
Ich kann meine Änderungen dafür mal heute abend einchecken, dann kannst
Du das entsprechend für Deine FB machen, die ja offenbar nur ein
abweichendes Timing hat und die Formel für die Checksum eventuell eine
andere ist.
Armin J. schrieb:> Es läuft übrigens mit allen 40 anderen IR Protokollen aus dem> AllProtocol Example gleichzeitig, man muss sie nicht disablen.
Es macht aber keinen Sinn, RF- und IR-Signale gleichzeitig zuzulassen.
Es gibt im irmp nur einen Input-Pin. Daran schließt Du entweder einen
RF-Empfänger (active high) oder einen IR-TSOP (active low) an.
Okay, man könnte nun durch entsprechende Vorkehrungen (Transistor am
RF-Empfänger-Ausgang) dafür sorgen, dass das RF-Signal active low wird
und gleichzeitig über dieselbe Open-Collector-Eigenschaft wie ein TSOP
verfügt. Dann könnte man sogar beide Signale an demselben µC-Eingangspin
anschließen.
Aber diese Konstruktion sehe ich schon als sehr "exotisch" an.
Und noch was zur Medion PC Fernbedienung 20018071.
Der Code wird mindestens 5 mal gesendet, auch wenn man nur kurz auf die
Taste drückt.
Kann man das irgendwo spezifizieren?
Frank M. schrieb:> Es macht aber keinen Sinn, RF- und IR-Signale gleichzeitig zuzulassen.> Es gibt im irmp nur einen Input-Pin.
OK, in einem Post erwähntest du das IRMP nun x10 dekodieren kann, ich
wollte es gerade mal aufbauen und stolpere schon (ich nutze ja am
Arduino immer noch deine Version von 2015 weil ich sie besser kenne und
sie am mega328p und am mega1284p unter Arduino gut läuft.
Nun habe ich in der Arduino IDE 1.8.9 unter Bib. Verwalter
nachinstalliert und bekomme nur die 3.0.0 aber es heisst ja im Artikel
Ab Version 3.2 kann IRMP auch RF-Funkprotokolle (433 MHz) dekodieren.
Erste Hürde!
Dann heisst es auch für den ESP32, der ist im Beispiel der 3.0.0 nicht
mal wählbar?
Also muss ich die LIB für den ESP32 nun händisch einbinden? und wo?
Normalerweise ja in Sketchverzeichnis aber unter Hardware wird ja dort
verzweigt nach tools, bin leicht verwirrt.
Eines fiel mir schon auf im Beispiel der v3.0.0:
1
voidsetup()
2
{Serial.begin(115200);
3
#if defined(__AVR_ATmega32U4__)
4
while(!Serial);//delay for Leonardo, but this loops forever for Maple Serial
delay(2000);// To be able to connect Serial monitor after reset and before first printout
8
#endif
9
#if defined(__ESP8266__)
10
Serial.println();// to separate it from the internal boot output
11
#endif
ESP32 nicht wählbar?
Serial.begin(115200); mit brutalen 115k OK wer kann, bei mir klemmts an
wUSB und USB Server LAN100/400 von sharkoon, ich mag da lieber das es
funktioniert mit 19k2
Dann fiel mir auf das der alte Müll in der Schnitte nicht entsorgt wird
nach Serial.begin....
finde das so etwas geschmeidiger
1
Serial.begin(19200);
2
Serial.flush();
3
/*while(Serial.available()) // alternativ
4
Serial.read();*/
würde mich nun über Antworten freuen wie ich weiter vorgehen kann.
LG jar
Joachim B. schrieb:> Erste Hürde!> Dann heisst es auch für den ESP32, der ist im Beispiel der 3.0.0 nicht> mal wählbar?
Wie möchtest Du ihn denn auswählen?
LG Armin
Armin J. schrieb:> Wie möchtest Du ihn denn auswählen?
nun darfst du raten warum ich frage, im ersten Moment dachte ich an
Joachim B. schrieb:> #if defined(ESP32)
aber da die LIB erst 3.0.0 ist und Frank schrieb ab 3.2.0 ist der ESP32
drin.....
Warum fragst du? hilft mir das?
Vielleicht gibt der Autor eine Antwort, eilt ja nicht ich dachte ich
probiere es mal aber wenn ich über den Bib. Verwalter nicht rankomme
scheint es ja nicht so wichtig zu sein.
Joachim B. schrieb:> aber da die LIB erst 3.0.0 ist und Frank schrieb ab 3.2.0 ist der ESP32> drin.....
Es könnte sein, dass die Versionsnummerierung des Arduino-Ports von der
Nummerierung der Original-Version abweicht. Auskunft könnte Dir Armin
geben, den Du gerade abgeschmettert hast. Er ist maßgeblicher Supporter
des Arduino-Ports von IRMP.
Ich persönlich kann überhaupt keine Auskunft geben, wenn es konkret um
den Arduino-Port geht. Da stecke ich zuwenig drin.
Frank M. schrieb:> Auskunft könnte Dir Armin> geben, den Du gerade abgeschmettert hast. Er ist maßgeblicher Supporter> des Arduino-Ports von IRMP.
und wie half dann?
Armin J. schrieb:> Wie möchtest Du ihn denn auswählen?> LG Armin
ich kann das doch nicht riechen und wenn er der Supporter ist hätte er
doch richtig antworten können, warum 3.0.0 genannt wird und 3.2.0
aktuell ist.
Du weisst ja selbst wie hier ständig mit Gegenfragen vom Thema
abgewichen wird!
Gegenfragen sind nun mal keine Antworten!
Jörg R. schrieb:> Guck mal da:
ich habe schon überall geschaut,
für Arduino wurde einiges stark geändert, aus *.c wurde *.c.h
Ich tippe mal ins Blaue die C-Sourcen wurden als Header eingebunden
(traurigerweise was mir hier mal als VÖLLIGE Ahnungslosigkeit
unterstellt wurde!)
Es scheint so als wenn nur die Anzeige noch auf version 3.0.0 steht,
möglicherweise ist der Code sogar aktuell, aber ich kann jetzt nicht
anfangen jede Zeile zu prüfen, dazu bin ich aus dem Source Code seit
2015 zu lange raus.
Frank M. schrieb:> Auskunft könnte Dir Armin> geben, den Du gerade abgeschmettert hast. Er ist maßgeblicher Supporter> des Arduino-Ports von IRMP.
muss ich nun auf die Knie fallen und um Vergebung bitten?
Du hattest ja die Version 3.2.0 erwähnt die ich unter der Arduino IDE
eben nicht einbinden konnte!
Ich verstehe auch nicht warum die Arduino IDE nur die Version 3.0.0
anbietet und nennt!
Meine Frage wurde nicht beantwortet und warum ein mir bis dahin
unbekannter Armin auf meine Frage eine Gegenfrage stellt bleibt auch
unklar.
Aber danke dafür!
Das sagt viel aus!
IRMP ist schon irgendwie genial, aber wie heisst es doch Genie und
Wahnsinn liegen dicht beieinander!
Joachim B. schrieb:> muss ich nun auf die Knie fallen und um Vergebung bitten?
Du hast schon eine sonderbare Art um Hilfe zu bitten zumal du hier schon
etwas geschenkt bekommen hast. Rumpöbeln und sich beschweren wenn keine
(wenig) Hilfe kommt.
Ja sicher, es ist nicht vollkommen, das Geschenk für dich, aber du nutzt
es doch freiwillig.
900ss D. schrieb:> Du hast schon eine sonderbare Art um Hilfe zu bitten zumal du hier schon> etwas geschenkt bekommen hast.
ja ich bin ein Mensch mit Fehler, aber ich gestehe das auch Autoren zu
die auf eine Frage mit einer Gegenfrage antworten!
Selbst Moderatoren gestehe ich Fehler zu (auch dem Frank, er wird sich
erinnern RTC3231 Ladeschaltung & CR, da hat er mich auch
irrtümlicherweise rund gemacht) das sie in der Arduino IDE nicht
involviert sind, aber das kann kein Grund sein nun nicht zu antworten
ausser sie wollen halt nicht.
OK habe ich öfter erlebt und scheint oft der Grund zu sein warum Arduino
in gewissen Kreisen verpönt ist.
Ich mag Arduino sehr, habe das öfter geschrieben aber so kann ich auch
mittlerweile Arduino Hasser verstehen!
Wollen die Arduino LIB Ersteller echt helfen oder nur ihrem EGO frönen?
min 2 Möglichkeiten, Neustart meinen "Tonfall" abhaken und eine
verständliche Antwort geben:
wie kann ich in der Arduino IDE die Version 3.2.0 einbinden?
oder mich weiter ignorieren, das sagt auch was aus!
Frank M. schrieb:> Ich kann meine Änderungen dafür mal heute abend einchecken, dann kannst> Du das entsprechend für Deine FB machen, die ja offenbar nur ein> abweichendes Timing hat und die Formel für die Checksum eventuell eine> andere ist.
Hallo Frank, bin erst jetzt dazu gekommen das mal zu testen.
mit dem Timing
Hallo Frank,
gibt es einen Grund, warum irmp_get_data() uint_fast8_t und nicht bool
ist?
Ist das noch historisch?
Ich versuche das gerade zu dokumentieren:
https://github.com/ukw100/IRMP#api
1
// Main check for result function used in loop() - returns TRUE or FALSE
2
uint_fast8_t irmp_get_data (IRMP_DATA *)
Und das wäre einfacher zu verstehen, wenn der Returnwert bool wär.
Ich weiss, dass das denselben Assembler Code gibt, aber verwirrend ist
es erstmal.
Könnte man das eventuell nur für #ifdef ARDUINO auf bool setzen?
Hello everyone,
I am try to make IR learning remote by using microcontroller ( my item
is EFR32 of Silicon labs)
I used to refer IRMP_English and IRSND to decoder and encoder IR signal
and I was successful with protocols which are available in the IRMP
Protocols.
but it will not work with strange protocols.
Do we need to decode it to be able to save it and emit it?
Is there any way we could capture the infrared signal, then save it and
emit it without encoding end decoding it? because if encoding and
recording will not work if there is a strange protocol.
I searched a lot of information on various forums but couldn't find it.
Hi Armin,
Armin J. schrieb:> gibt es einen Grund, warum irmp_get_data() uint_fast8_t und nicht bool> ist?> Ist das noch historisch?
Ja, das ist historisch und ich würde es für C auch nicht ohne zwingende
Not ändern wollen. In C ist "stdbool.h" zwar mittlerweile Standard, aber
ich weiß nicht, welchen (älteren) C-Compiler ich damit ausschließen
würde. Daher habe ich das auch nie geändert. Die Verwendung von "bool"
ergibt (in C) auch keinen verwertbaren Vorteil. Und wer weiß? Vielleicht
gibt ja irmp_get_data() irgendwann aus irgendwelchen Gründen auch andere
Werte als 0 und 1 zurück?!? ;-)
In C++ (wie Arduino) ist die Verwendung von bool natürlich überhaupt
kein Problem. Daher könnte man das durchaus für Arduino oder besser noch
mittels
Armin J. schrieb:> For just recording and replay you should consider to use the IRremote> library.
I already had contact with l_q by mail in the last days. He wants to
decode the Daikin protocol (air conditioning) with IRMP. But as I
learned on https://github.com/blafois/Daikin-IR-Reverse meanwhile, this
protocol consists of at least 15 bytes, not bits! Therefore it is
impossible to handle the protocol with IRMP. IRMP is not prepared for
such frame lengths.
@l_q: IRMP is the wrong tool here because Daikin's IR frames are much
too long. Perhaps https://github.com/blafois/Daikin-IR-Reverse is the
better tool for you.
Frank M. schrieb:> In C++ (wie Arduino) ist die Verwendung von bool natürlich überhaupt> kein Problem. Daher könnte man das durchaus für Arduino oder besser noch> mittels>
1
>#ifdef__cplusplus
2
>...
3
>#endif
4
>
> so einstellen.
Das wäre SUUUUUUUPER
Danke
P.s. und für irmp_ISR (void); bitte auch :-)
Frank M. schrieb:> Armin J. schrieb:>> gibt es einen Grund, warum irmp_get_data() uint_fast8_t und nicht>> bool ist? Ist das noch historisch?>> Ja, das ist historisch und ich würde es für C auch nicht ohne zwingende> Not ändern wollen. In C ist "stdbool.h" zwar mittlerweile Standard,
bool bzw. stdbool.h gibt's seit C99...
> aber ich weiß nicht, welchen (älteren) C-Compiler ich damit ausschließen> würde. Daher habe ich das auch nie geändert. Die Verwendung von "bool"> ergibt (in C) auch keinen verwertbaren Vorteil. Und wer weiß? Vielleicht> gibt ja irmp_get_data() irgendwann aus irgendwelchen Gründen auch andere> Werte als 0 und 1 zurück?!? ;-)
...wobei uint_fast8_t bzw. stdint.h ebenfalls C99 sind.
Problem wären also Compiler, die C99 nur teilweise unterstützen.
Was ist eigentlich der Grund dafür, dass die Voreinstellung nur ein
einziges IR-Protokoll aktiviert hat, nämlich NEC?
Ist NEC der neue Quasi-Standard, also sozusagen das neue RC5?
Johann L. schrieb:> bool bzw. stdbool.h gibt's seit C99...
Da magst Du recht haben. Wenn Du mir nur einen Grund nennst, was ich
durch Verwendung von bool gegenüber uint8_t als Rückgabewert einer
Funktion gewinne, kann ich das gerne ändern. Der erzeugte Assembler-Code
ist jedenfalls derselbe und ich halte mir so die Option offen, noch
andere Werte als true oder false zurückliefern zu können - ohne etwas am
Interface ändern zu müssen.
Johann L. schrieb:> Was ist eigentlich der Grund dafür, dass die Voreinstellung nur ein> einziges IR-Protokoll aktiviert hat, nämlich NEC?
Es sind 4 Protokolle, die standardmäßig aktiviert sind, nämlich:
1
#define IRMP_SUPPORT_SIRCS_PROTOCOL 1
2
#define IRMP_SUPPORT_NEC_PROTOCOL 1
3
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL 1
4
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL 1
(siehe irmpconfig.h)
> Ist NEC der neue Quasi-Standard, also sozusagen das neue RC5?
Siehe 3. Abschnitt am Anfang des IRMP-Artikels, nämlich unter
https://www.mikrocontroller.net/articles/IRMP#IR-Protokolle :
"Heutzutage wird (auch vornehmlich bei japanischen Geräten) das
NEC-Protokoll verwendet - und zwar von den unterschiedlichsten (Marken-
und auch Noname-)Herstellern. Ich schätze den "Marktanteil" auf ca. 80%
beim NEC-Protokoll. Fast alle Fernbedienungen im alltäglichen Einsatz
verwenden bei mir den NEC-IR-Code. Das fängt beim Fernseher an, geht
über vom DVD-Player zur Notebook-Fernbedienung und reicht bis zur
Noname-MultiMedia-Festplatte - um nur einige Beispiele zu nennen."
RC5 ist längst tot. Philips hatte zwar nochmal eine Wiederauferstehung
mit RC6 versucht, ist aber damit längst nicht so erfogreich geworden wie
damals mit RC5.
NEC als universelles Protokoll findest Du dagegen fast überall. Im oben
genannten Kapitel des Artikels wird auch noch über die anderen oft am
Markt anzufindenden Protokolle geschrieben, nämlich über Kaseikyo
(vornehmlich in Asien) und Sony.
Frank M. schrieb:> bool gegenüber uint8_t als Rückgabewert einer Funktion gewinne, kann
Ich habe nicht selten Kollegen erlebt, die waren der Meinung in bool
kann es nur 0 oder 1 (false oder true) geben. Wunderten sich dann als
ein Vergleich mit true nicht klappte, weil 5 drin stand. :)
bool gehört abgeschafft.
900ss D. schrieb:> bool gehört abgeschafft
wegen falscher Benutzung?
soweit ich weiss ist false immer NULL und true immer !false wobei es
nicht interessiert was in true steht.
Gut ist doch das man true(!false) auch nutzen kann für Ergebnisse.
Frank M. schrieb:> Johann L. schrieb:>> bool bzw. stdbool.h gibt's seit C99...>> Da magst Du recht haben. Wenn Du mir nur einen Grund nennst, was ich> durch Verwendung von bool gegenüber uint8_t als Rückgabewert einer> Funktion gewinne, kann ich das gerne ändern.
Es war nur eine Anmerkung meinerseits, dass es sowohl uint8_t o.ä. als
auch bool seit C99 gibt, ohne irgendeine Empfehlung.
Allerdings steht in der Doku zu irmp_get_data():
1
* @return true: successful, false: failed
> Der erzeugte Assembler-Code ist jedenfalls derselbe und ich halte mir> so die Option offen, noch andere Werte als true oder false zurückliefern> zu können - ohne etwas am Interface ändern zu müssen.
Anstatt "failed" würde ich eher sagen "nothing here", d.h. es wurde noch
nichts bzw. nichts mehr empfangen seit dem letzten Datensatz? "failed"
würde ich interpretieren als Fehler im Protokoll bzw. irgendwas
Unbekanntes.
900ss D. schrieb:> Ich habe nicht selten Kollegen erlebt, die waren der Meinung in bool> kann es nur 0 oder 1 (false oder true) geben.
Ist auch so, zumindenst in C99+ und C++.
> Wunderten sich dann als ein Vergleich mit true nicht klappte,> weil 5 drin stand. :) bool gehört abgeschafft.
Dann war's irgendein Hack wie
1
#define bool unsigned char
Das bool von C/C++ kann sich aber aber niemals nich so verhalten wie ein
unsigned char weil in C99
Johann L. schrieb:> Ist auch so, zumindenst in C99+ und C++
C++ ist bei uns verboten, ja :( Da funktioniert es mit bool, ja. Aber
eben nicht in C. Und ich kenne wirklich einige, die nicht wissen das in
C bool nicht wirklich bool ist. Es ist da nur irreführend.
900ss D. schrieb:> Johann L. schrieb:>> Ist auch so, zumindenst in C99+ und C++>> C++ ist bei uns verboten, ja :( Da funktioniert es mit bool, ja. Aber> eben nicht in C. Und ich kenne wirklich einige, die nicht wissen das in> C bool nicht wirklich bool ist. Es ist da nur irreführend.
Dann ist es nicht dass bool von C (also von C99) sondern was
hausbackenes.
Beispiel avr-gcc:
C99:
1
#include<stdbool.h>
2
3
boolglobal_5=5;
4
5
boolbool_5(void)
6
{
7
return5;
8
}
Präprozessiert:
1
_Boolglobal_5=5;
2
3
_Boolbool_5(void)
4
{
5
return5;
6
}
d.h. bool ist effektiv ein Typ mit eigener, nicht-int Semantik!
Assembly:
1
.global bool_5
2
.type bool_5, @function
3
bool_5:
4
ldi r24,lo8(1)
5
ret
6
.size bool_5, .-bool_5
7
8
.global global_5
9
.section .data.global_5,"aw",@progbits
10
.type global_5, @object
11
.size global_5, 1
12
global_5:
13
.byte 1
d.h. in beiden Fällen wird true (1) gespeichert und eben NICHT 5.
Wenn du GCC verwendest, und bool wird nicht auf _Bool abgebildet wird
(das übrigens älter als C99 ist) dann habt ihr selber was gebastelt und
unzureichend dokumentiert...
Natürlich wird der Vergleich "if (global_5 == 5)" nie zutreffen, weil es
nach den Promotion-Rules ein Vergleich 2er int ist, und global_5 immer 0
oder 1 ist. Damit der Vergleich zutrifft, müsste man sowas wie "if
(global_5 == (bool) 5)" machen.
Johann L. schrieb:> Dann ist es nicht dass bool von C
Das müsste ich prüfen. Weiß ich nicht im Kopf. Vielleicht wird auch
nicht C99 verwendet sondern älter. Es ist alles soo alt in dem Projekt
;)
Noch ne Frage zum NEC-Protokoll:
https://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol
spezifiziert den Payload eines Frames als 4 Bytes:
1. Adresse (little Endian)
2. 1er Complement von 1.
3. Commando (little Endian)
4. 1er Complement von 3.
Demnach werden nur Adressen 0x0...0xff unterstützt. Ich bekomme aber
für meine Bleil-Schrott-Fernbedienung eine Adresse von 0xEF00.
In IRMP: Fernbedienungen sind noch viele andere NEC Geräte
aufgelistet, und deren Adressen sind auch keine 8-Bit Adressen...
Wo ist da mein Denkfehler?
Johann L. schrieb:> Noch ne Frage zum NEC-Protokoll:>> https://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol>> spezifiziert den Payload eines Frames als 4 Bytes:>> 1. Adresse (little Endian)> 2. 1er Complement von 1.> 3. Commando (little Endian)> 4. 1er Complement von 3.
Das gilt nur für das Standard-NEC-Protokoll. NEC wurde später nochmals
erweitert, genannt "Extended NEC". Dabei wurde das Complement der
vormaligen Adresse aufgegeben und Byte #2 als zweites Adress-Byte
erklärt.
Damit wird das Standard-NEC-Protokoll nur noch ein Spezialfall vom
Extended-NEC-Protokoll. IRMP betrachtet NEC immer als Extended NEC und
gibt deshalb eine 16-Bit-Adresse zurück, aber nur einen
8-Bit-Kommando-Code - wobei das Complement vorher selbstverständlich
überprüft wird.
Das steht aber auch im IRMP-Artikel, vergleiche bitte:
https://www.mikrocontroller.net/articles/IRMP#NEC_.2B_extended_NEC
Auszug:
> Demnach werden nur Adressen 0x0...0xff unterstützt. Ich bekomme aber> für meine Bleil-Schrott-Fernbedienung eine Adresse von 0xEF00.
Dann ist das klar eine Adresse aus dem "Extended-NEC-Protokoll".
Johann L. schrieb:> Frank M. schrieb:>> Johann L. schrieb:>>> Würd gerne nen ATtiny24 verwenden. Der Code passt da zwar locker rein,>>> aber es soll ja mehr auf den µC als IR-Auswertung...>>>> Immer diese Selbstquälerei, nimm einfach einen ATtiny44 ;-)>> Hab hier noch nen ATtiny24 und 'nen LED-Streifen anzusteuern ist ja> keine Rocket-Science...
Hab den Code jetzt auf 'nen ATtiny24 umgezogen. Ein "leerer"
IRMP-Empfänger nur mit NEC Protokoll belegt knapp 1kB inclusive
Vectortabelle und Startup-Code etc. Den RGB-Streifen anzusteuern
braucht dann zusätzlich noch knapp 800 Bytes, passt also locker in die
2KiB Flash rein.
Die Ansteuerung ist auch besser als im Original: Ausgewogenere Farben
und höhere PWM-Frequenz, nämlich 1 kHz bei 60 Helligkeitsstufen für jede
Farbkomponente. Weil es Software-PWM ist ergibt sich eine relative hohe
IRQ-Last von 45% für Timer0 nur für die RGB Ansteuerung. IRMP
funktioniert problemlos mit dieser hohen IRQ-Last und mit F_CPU = 8 MHz.
Danke nochmal für den Code und die Hintergrundinformationen!
Johann L. schrieb:> IRMP funktioniert problemlos mit dieser hohen IRQ-Last und mit F_CPU = 8> MHz.
Danke für das Feefdback, freut mich, dass es so läuft!
900ss D. schrieb:> Johann L. schrieb:>> passt also locker in die 2KiB Flash rein>> Da bekommst du doch bestimmt noch ein Spiel rein, gesteuert von der> Fernbedienung ;)
Wird dann aber ein ödes Spiel, wenn das "Display" nur ein LED-Streifen
ist...
Hab spaßeshalber mal 'nen eigenen NEC-Decoder implementiert, der spart
gegenüber dem bereits optimierten und kastrierten IRMP immerhin 550
Bytes ein.
Hab allerdings geplant, einen "Supportmodus" einzubauen:
Der LED-Streifen sind im Schlafzimmer an Fußleisten etc. Mein
selbstgebautes Bett steht auf 2 Zeilen Glasbausteinen an den Flanken,
und unter dem Bett und hinter den Glasbausteinen sind 4 (rot, grün,
blau, gelb/weiß) Lichterketten. Diese dienen als Nachtlicht und können
über 4 Schalter am Kopfende an- und ausgeschaltet werden; die
LED-Streifen hängen am 5. Schalter.
"Supportmodus" bedeutet, dass die LED-Streifen dem Zustand der
Lichterketten folgen. Wenn z.B. die rote Lichterkette an ist, sollen
die LED-Streifen auch rot sein, und zwar ohne dass man diese fummelige
Bleil billig-Fermbedienung betätigen muss.
Ein Knopf der Fernbedienung würde diesen Supportmodus betätigen, danach
folgt die Farbe bzw. an / aus den 230V~ Schalten am Bett.
In die verbliebenen 300 Bytes Flash passt das lockerst rein :-)
Frank M. schrieb:> Johann L. schrieb:>> IRMP funktioniert problemlos mit dieser hohen IRQ-Last und mit F_CPU = 8>> MHz.>> Danke für das Feefdback, freut mich, dass es so läuft!
Tut auch noch bei 90% CPU-Last der RGB-PWM-ISR, d.h. PWM-Frequenz von 2
kHz. Ist auch klar: Jitter der IRMP-ISR bleibt wie bei 1 kHz (ca. 60
Ticks), und die IRMP-ISR ist nicht unterbrechbar; funktioniert also
unverändert.
nach der Änderung tat es das auch.
Einige Protokolle z.B. RECS80, RC6, RECS80EX, RC6A, lassen sich nur mit
einem guten Empfänger IC decodieren, aber viele gehen so.
Ich habe auch die direkte Verbindung getestet, das geht jetzt mit
IRSND_GENERATE_NO_SEND_RF aber da klappt sogar NEC nicht.
Die Protokolle A1TVBOX + TELEFUNKEN + ab FAN bis IRMP16 können gar nicht
decodiert werden.
Bei FDC und SIEMENS bekomme ich das Protokoll zwar erkannt, aber das
Comand stimmt nicht.
Ich hab noch nicht alle überprüft, aber die Inkonsistenzen sind doch
hoch.
Hast Du eine Erklärung dafür? Hab ich was übersehen? Hast Du mal alle
getestet?
LG Armin