IRMP auf STM32 - ein USB IR Empfänger/Sender/Einschalter mit Wakeup-Timer

    Guter Fund! Echt klasse das die freien Projekten eine feste Product-ID spendieren.


    Stimme zu, dass das eine sehr gute Idee ist. In der udev-Regel sollte man dann bis auf Weiteres natürlich beide Kombinationen (die alte und die neue) drin lassen, damit alte Firmwares noch erkannt werden.


    Bisher wird die ID von diesem ST "USB HID Example" zweckentfremdet. Wenn man die Chance hat eindeutige IDs zu bekommen sollte man das meiner Ansicht nach unbedingt mitnehmen!

    Meine Änderungen habe ich nun getestet. Meine mit GCC 4.9 gebaute Firmware funktioniert bei mir wunderbar. Somit bin ich auf bestem Weg das ganze endlich produktiv in meinen VDR zu bekommen.


    Ich habe mir dafür irmplircd für Arch Linux gebaut, diesen gestartet und dann mit "irw" beobachtet was für Events reinkommen. Das klappt überraschend gut!


    Ich bin noch an ein paar anderen kleinen Modifikationen für die Firmware dran. Um meinen Git-Tree dafür erstmal wieder sauber zu bekommen habe ich jrie einen Pull-Request geschickt. Würde mich freuen wenn die Änderungen so übernommen werden könnten.


    Nachtrag: Für alle, die irmplircd für Arch Linux brauchen: https://github.com/VDR4Arch/vdr4arch/tree/master/irmplircd
    Ich gehe davon aus, dass Copperhead dann auch in Kürze entsprechende Binaries ausliefert.

    Habe den Pull Request übernommen.
    Zum Testen komme ich frühestens nächste Woche.


    Bin mir nicht sicher, ob das Ändern der VID und PID nützlich ist.
    Ich bitte um Kommentare.


    Meine Einwände:
    pid.codes gibt es erst seit ein paar Tagen. Wer weiß, ob die nicht bald weg geklagt werden oder sonstigen Ärger bekommen.
    Eine andere VID als von STM kommt mir komisch vor. Ist schließlich ein STM device. Wer kennt schon VID 1209?
    Über die PID können wir eher reden, die hatte ich früher schon mal geändert, aber beim Aufräumen wieder zurück gesetzt. Hätte das einen Vorteil für uns, die zu ändern?

    Die CPU ist von ST. Üblicherweise wird die VID dann vom Hersteller des Geräts gesetzt. Sind ja auch nicht alle Geräte mit Atmel-CPU mit Atmel-VID.


    Andern nur der PID alleine macht auch kaum Sinn, denn die musste uns dann eigentlich ST zuweisen. Die einzige saubere Lösung, die ich finden konnte, ist pid.codes. Damit hätte man eindeutige IDs.


    Nachtrag: Doch noch eine Alternative gefunden: http://wiki.openmoko.org/wiki/USB_Product_IDs

    Meine Frage bezog sich auf:
    "if you need multiple Product IDs, please indicate + explain this at the first message, rather than applying for a second ID later".
    Die Black Magic Probe z.B. hat eine PID für den normalen Anwendungsmodus, und eine für den DFU-Modus (= Device-Firmware-Upgrade Mode).
    Wir könnten sowohl im Bootloader von 1eaf:0003 zu 1d50:x wechseln als auch mit dem "STM32 IRMP HID-Device" von 0483:5750 zu 1d50:x+1.
    Der Produkt String des Bootloaders könnte dann auch gleich von "Maple 003" auf "STM32 IRMP Firmware Upgrade" oder "STM32 IRMP Bootloader" geändert werden.
    Manche Projekte haben viele IDs. Ich denke, die zwei reichen für uns.


    Seht ihr das auch so?
    Ich will es gleich beim ersten Anlauf "richtig machen".

    Interessante Neuigkeiten:
    Hier gibt es Software für ein MediaPortal Plugin. Ich hatte noch keine Zeit, mir das näher an zu schauen, aber da es so wie dies Projekt für IR das Protokoll von Portisch benutzt, müßte es auch mit IRMP_STM32 funktionieren.


    Zum Stand des Projektes:
    Seit Frank die schnellen Variablen in IRMP eingebaut hat (Januar) und nachdem Ole noch einen Fehler behoben hat (Februar), sind alle mir bekannten Bugs behoben und ich sehe das Projekt als absolut stabil an.
    Nachdem nun auch gcc 4.9 anwendbar ist, ist die letzte Einschränkung bewältigt.


    Ausblick:
    Ich bastele an einem Konfigurationstool mit grafischer Oberfläche. Da ist aber noch viel zu tun.


    Anbei die zweite Version von dem Kommandozeilen Konfigurationstool für Windows.

    Zitat von jrie

    sind alle mir bekannten Bugs behoben und ich sehe das Projekt als absolut stabil an.
    Nachdem nun auch gcc 4.9 anwendbar ist, ist die letzte Einschränkung bewältigt.


    Dann wäre das doch ein guter Zeitpunkt sich eine VID/PID-Kombination zu sichern. Ich denke man sollte nicht verschwenderisch sein und nur eine PID beantragen. Es gibt bestimmt noch andere gute Projekte, die eine eindeutige VID/PID-Kombination benötigen könnten.


    pid.codes wurde neulich erst von hack-a-day gefeatured. Da musste ich auch gleich an IRMP_STM32 denken.

    Ich sehe das genau so wie olebowle. Den Bootloader hatte ich garnicht im Fokus. Der ist ja immer nur sehr kurz aktiv. Zudem muss man den Empfänger kurz abziehen und wieder stecken um ihn überhaupt zu erreichen. Ich glaube nicht, dass da Verwechslungsgefahr besteht.

    Schon mal eine Vorabversion des GUI Konfig-Tools.
    Es funktioniert bereits alles, auf der Todo Liste steht noch neben Bugfixes eine anzeigbare Hilfe und das Editieren der irmp_stm32.map.


    Windows: Man lädt sich https://github.com/signal11/hidapi herunter, in einem parallelem Verzeichnis die hidapi-externals für die Fox Toolkit Sachen. Beigefügte Dateien müssen über die vorhandenen kopiert werden.
    Dann in Visual Studio (kostenlose Version reicht) die ...\testgui\testgui.sln bauen.
    Die ausführbare Datei für Windows ist auch beigefügt.


    Linux: hidapi aus git holen, test.cpp ersetzen, kompilieren mit make -f Makefile-manual.

    Folgendes ist zwar Meckern auf ganz hohem Niveau, aber vielleicht sind wir ja jetzt an einem Stand, an dem man Feinschliff machen kann.


    Ich habe gerade mal meine VDR-Fernbedienung am STM32-IRMP-Empfänger ausprobiert. Ich bekomme folgende Ausgabe von irw:



    Bis zur Leerzeile habe ich die Taste "OK" sehr schnell immer wieder gedrückt, aber jedes Mal auch losgelassen. Erwartet hätte ich, dass hier immer "0" für den Toggle-Bit-Indikator steht. Stattdessen schaffe ich es, rein durch schnelles Drücken, hier ein "Hochzählen" zu erreichen. Beim VDR wirkt sich das kaum aus. Bei anderen Programmen (Kodi, ...) aber schon.


    Nach der Leerzeile habe ich die gleiche Taste (OK) gedrückt gehalten und dort wird es richtig interessant. Erst zählt der Toggle-Bit-Indikator hoch, dann schießt mir die Firmware plötzlich irgendeinen anderen Code dazwischen, den ich nie gesendet habe. Dadurch wird das saubere "Hochzählen" unterbrochen. Es wird, auch bei mehrfachen Testen, immer der gleiche "Falschcode" erkannt. Wo kommt der her?


    Das gleiche, aufgezeichnet mit yaUsbIr:



    Nachtrag: Ich habe jetzt im IRMP alle Codes außer RC5 und RC6 wegkonfiguriert und jetzt sind die "Geistercodes", die "dazwischengeschossen" wurden, weg. Wäre mal interessant zu wissen welcher Code sich hier offensichtlich mit RC5 beißt. Es wird jetzt sauber hochgezählt ohne Unterbrechung. Was immer noch nicht geht ist das saubere Erkennen des Toggle-Bits. Schnelles wiederholtes Drücken einer Taste sorgt immer noch für ein "Anzählen". Kann IRMP das überhaupt oder wird hier ein "Toggle-Bit" simuliert wenn ein Code innerhalb eines Timeouts nochmal kommt?

    Am sinnvollsten wäre es vermutlich, wenn du dich wegen IRMP direkt an Frank wendest:
    https://www.mikrocontroller.ne…ed-multi-protocol-decoder


    Das mit dem toggled bit funktioniert bei IRMP „anders“.
    Wenn du eine Taste gedrückt hälst, erzeugt der erste IR Code Flag 0, jeder weitere Flag 1.
    Wenn du schnell neu drückst kommt jedesmal Flag 0.


    Das Umsetzen passiert in irmplircd, der zählt dann hoch.
    Seit einigen Versionen kann man das IIRC konfigurieren.


    * Wie ist das bei dir konfiguriert?
    * Schau ev. mal in den irmplircd Code.


    Bei meiner RC5 FB habe ich das noch nie beobachtet. Da muss es bei dir einen störenden Faktor geben.
    * Du könntest eine Debug Ausgabe an Frank schicken, der kann dir dann vermutlich genau sagen, was schief geht.
    Für die Debug Ausgabe brauchst du aber das Dev-Board, nur das hat die Debug Ausgabe über seriell.


    Edit: Die Debug Ausgabe nennt sich bei IRMP "Logging".

    Noch keine Antwort von openmoko. Gibt es dort überhaupt noch Jemanden, der antwortet?
    Was die Bootloader PID betrifft, man könnte in die Firmware eine Funktion einbauen, die auf Erhalt eines gewissen Befehls einen Reset auslöst. Dadurch könnte man dann ein Firmware Update implementieren, das ohne Ab- und Anstecken funktioniert. Das wäre für ins Gehäuse eingebaute Empfänger nützlich. Insofern wäre eine extra PID vielleicht doch nützlich.


    Ich denke, ich warte mal noch eine Woche und dann melde ich mich doch bei pids.org an.
    Soweit ich weiß, kann man da sich die PID selbst aussuchen.
    Hat jemand eine Idee, welche PID zu uns passt? Manche machen Wortspiele http://pid.codes/pids/ .


    Es gibt übrigens eine neue IRMP Version.

    Zitat von jrie

    Am sinnvollsten wäre es vermutlich, wenn du dich wegen IRMP direkt an Frank wendest:
    https://www.mikrocontroller.ne…ed-multi-protocol-decoder


    Daran habe ich auch schon gedacht. Im Sourcecode steht auch eine Mailadresse. Ich werde ihn später gleich mal anmailen. Im Sourcecode finde ich nur zu RC6 Hinweise auf ein Toggle-Bit. Vielleicht geht das bei RC5 aktuell wirklich noch nicht...


    Weiterhin gibt es tatsächlich eine Art "Timeout". Ob das ausschließlich oder nur alternativ verwendet wird ist für mich aber erstmal nicht ersichtlich.


    Zitat


    Bei meiner RC5 FB habe ich das noch nie beobachtet. Da muss es bei dir einen störenden Faktor geben.


    Man muss schon sehr schnell drücken um das zu reproduzieren. Im Zweifelsfall: So schnell wie irgend möglich eine Taste wiederholen, immer aber auch wieder loslassen. Ab einer gewissen Geschwindigkeit meldet IRMP eine Tastenwiederholung. Sieht für mich so aus als wenn ich in das Timeout komme. Entweder dieses greift selbst wenn ein Toggle-Bit vorhanden ist, oder das Toggle-Bit wird für RC5 noch nicht unterstützt.


    Zitat


    * Du könntest eine Debug Ausgabe an Frank schicken, der kann dir dann vermutlich genau sagen, was schief geht.
    Für die Debug Ausgabe brauchst du aber das Dev-Board, nur das hat die Debug Ausgabe über seriell.


    Ich brauche einen seriellen Port. Nicht zwingend das Dev-Board. Weißt du welche Pins vom STM32 zum seriellen Port gehen? Einen USB2UART mit 3,3V-Pegel habe ich da. Den bekomme ich dann auch irgendwie an die CPU dran.


    Nachtrag:
    https://www.mikrocontroller.ne…ol-decoder?page=1#1647521
    https://www.mikrocontroller.ne…ol-decoder?page=2#2168028


    Im weiteren Verlauf gibt es noch mehr solche Hinweise. Ist wohl wirklich so, dass das Toggle-Bit nicht interpretiert wird.

    Ja, das toogle bit wird ignoriert, und wie gesagt macht IRMP das anders. Das Ergebnis ist aber das gleiche, weil die flags in irmplircd so umgesetzt werden, dass stetig hoch gezählt wird. Ich verstehe Franks Ansatz und kann darin keinerlei Nachteil erkennen. Beim ersten Mal stolpert man halt darüber und muss umdenken.


    Wenn du an den Pin fürs Logging was anlöten willst: defaultmäßig ist in irmp.c B10 gesetzt. Könnte man ändern, aber es muss einer mit UART Fähigkeit sein.


    Wenn ich so schnell wiederholt drücke, wie ich kann, läuft bei mir alles wie es soll. Vielleicht bist du schneller als ich. Vielleicht hält sich aber auch deine FB nicht an die in RC5 vorgeschriebene Pause zwischen 2 Codes. Das wissen wir aber erst, wenn du loggst.


    Ich kann mich schwach daran erinnern, dass ich mir das mit dem timeout in IRMP mal angeschaut habe und es ok fand. So genau weiß ich das aber nicht mehr.


    Und zur Zeit geht alle meine freie Zeit in das Konfigurationsprogramm mit grafischer Oberfläche.
    Dabei bin ich auf ein paar interessante Probleme gestoßen, die gelöst werden wollen ;) .

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden