IRMP auf STM32 - ein USB-HID-Keyboard IR Empfänger+Einschalter mit Wakeup-Timer

  • ****************************************************************************************

    Projektseiten:

    IRMP_STM32_KBD

    IRMP auf STM32 – stark vereinfachte Bauanleitung

    IRMP auf STM32 - Bauanleitung


    Verkauf im Forums-Marktplatz:

    IRMP-STM32-USB-IR-Empfänger+Einschalter

    ****************************************************************************************



    Ich habe mit der Weiterentwicklung des Empfängers von HID-Raw zu HID-Keyboard angefangen. Er gibt dann als Tastatur den Fernbedienungs-Knöpfen zugeordnete Tastendrücke aus, ähnlich wie Flirc.


    Es geht bereits grundsätzlich:

    Wie der Vorgänger über USB-HID konfigurierbar (stm32kbdIRconfig und stm32kbdIRconfig_gui funktionieren, allerdings kann man noch nicht viel damit machen).

    Die ausgegebenen Tastendrücke sind noch nicht konfigurierbar, aber bereits für den VDR nutzbar (nach Anlernen).


    Die nächsten Schritte: IR-Senden heraus werfen (hat das überhaupt jemand mal benutzt?) und den freigewordenen Platz im Eepromm für die Zuordnung von IR-Daten und Tastatur-Tasten benutzen.


    Die Hardware bleibt dieselbe, das heisst, wenn es mal fertig ist, kann man vorhandene Empfänger updaten.

    Dieser Beitrag wurde bereits 3 Mal editiert, zuletzt von jrie ()

  • Die nächsten Schritte: IR-Senden heraus werfen (hat das überhaupt jemand mal benutzt?) und den freigewordenen Platz im Eepromm für die Zuordnung von IR-Daten und Tastatur-Tasten benutzen.


    Würde ich schade finden.


    Habe IR senden früher mal mit extra IR Sendehardware (habichthugo) zum Verstärker und Fernseher einschalten genutzt.

    Die Lautstärkeregelung vom Verstärker hatte zuviel Verzögerung per IR senden.


    In meinem aktuellen Hardwareszenario schalte ich per Kommandozeile einzelne Steckdosen einer USB Steckdosenleiste (EG-PM2)

    Lautstärkeregelung nutze ich vom vdr.


    Einen Tot muss man sterben :-)


    Großes Lob für die Arbeit an dem Projekt !

    Der neue Weg das als HID-Keyboard zu realisieren erfordert keinerlei extra Software zum betreiben?

    Es müssen lediglich die Tasten mit stm32IRconfig_gui konfiguriert/belegt werden analog zu den vdr Tastaturbefehlen.

    Zumindest verstehe ich das Prinzip von Flirc so.


    Munter bleiben, Rossi

  • Würde ich schade finden.


    Habe IR senden früher mal ... genutzt.

    Mhm, wieso schade, wenn du es nicht mehr benutzt?


    Heutzutage benutzen die meisten anscheinend CEC.


    Großes Lob für die Arbeit an dem Projekt !

    Danke. :)


    Als nächstes müssen die Konfigurationsprogramme angepasst werden, dann kümmere ich mich um den Rest. Ich halte euch auf den Laufendem und sage Bescheid, wenn es was zum Testen gibt.

  • Auf der Kommandozeile kann man schon testen.

    Es gibt 62 Plätze, zu jedem Platz gehört ein IR-Code und ein Tastatur Key.

    Wenn der IR-Code von Platz x empfangen wird, wird der Key von Platz x ausgegeben. Wenn derselbe IR-Code auf mehreren Plätzen ist, wird der erste genommen. Dazu müssen die IR-Codes und Keys mit stm32IRconfig eingegeben werden. Die IR-Codes können mit der Fernbedienung eingegeben werden, die Keys von Hand, z.B „KEY_1“. Am besten schreibt man sich das in einer Tabelle auf ;)

    q – i – 0 – FB-Taste, p – k – 0 KEY_… und fertig ist das Paar auf Platz 0.

    Wenn man dann FB-Taste drückt, wird KEY_… ausgegeben.

    Das ist noch etwas unbequem und eher für Tüftler, funktioniert aber schon ganz gut.


    Bis stm32kbdIRconfig_gui entsprechend angepasst wird, kann es noch etwas dauern.

    Es gibt noch viel zu tun ...

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von jrie ()

  • Mhm, wieso schade, wenn du es nicht mehr benutzt?


    Heutzutage benutzen die meisten anscheinend CEC.

    Jedes Setup ist anders - wenn das heutzutage nicht mehr benutzt wird ok.

    CEC ist mächtig, wollte ich per PulseEight CEC Adapter auch schonmal über Kommandozeile steuern - das ist aber ein komplettes extra Thema.


    Wie geschrieben, schade aber von mir aus ist es ok das IR send rausfliegt.


    Die angemerkten Abstürze vom Windows Konfigurationsprogramm (stm32IRconfig_gui.exe) kann ich bestätigen.

    Auf zwei unterschiedlichen Win10 Systemen getestet. Bin aber trotzdem zum Ziel gekommen.

  • Bei mir auf Windows 8.1 habe ich keine Abstürze bemerkt.

    Betrifft das nur die Windows Version oder auch die Linux Version?

    War es die ca. 5 Monate alte Version aus meinem git?

    Was für einen Treiber hast du unter Windows 10 für den Empfänger?

    Ich erzeuge meine Treiber mit zadig.

    Ich bräuchte mal reproduzierbare Schritte, wie man so einen Absturz erzeugen kann, dann gucke ich mir das an.


    Edit: Das mit den Treibern ist nur für den Bootloader relevant.

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von jrie ()

  • IRMP_STM32_KBD:

    Ist jetzt brauchbar. Es gibt bestimmt noch den einen oder anderen Fehler, aber ist schon mindestens beta. Bitte alle Fehler hier melden.

    Firmware und stm32IRconfig_gui für Linux und Windows sind im git.


    Es wird vom Konfigurationsprogramm beim Start die map im eeprom ausgelesen, das sind erstmal viele Zeilen ffffffffffff ffff.

    Dann kann man wie gewohnt mit der Fernbedienung eine Taste in eine Zeile programmieren und auch einen Key.

    Die werden dann sofort von evtest erkannt.


    Noch bequemer ist es eine fertige map-Vorlage zu öffnen, dann sind alle Keys schon da, und es müssen nur per Fernbedienung noch die Tasten programmiert werden. Das ist dann so wie beim Flirc.


    Viel Spaß beim experimentieren!



    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von jrie ()

  • Hi jrie,


    I started testing the keyboard version.


    So far it is working oke, but I had one problem:

    This line "if(cur_dev->usage == 0x00)" in stm32IRconfig_gui.cpp is not working.

    I believe the usage field is only valid in MAC and Windows.

    But after disabling this line I could configure the keys.


    Another problem is the fact that my remote is sending repeats very fast after the initial key press.

    So now it is very difficult to send only one KEY, most of the times I get multiple characters.

    It would be very nice to have a configurable time between first press and first repeat.


    Greetings René (sorry for the English, I can read German, but writing .......)



  • Hi René,


    thanks for the feedback.


    The purpose of if(cur_dev->usage == 0x00) is to show only one of the two devices.

    Maybe you could help to figure out, why it is not working for you. For me it does work.


    Implementing the repeat delay and period is on my TODO list.


    Regards, Jörg

  • I am testing on openSuse and Windows 8.1.

    I see two devices without cur_dev->usage, one for hidraw (configuration) and one for keyboard as in #859.

    I implemented repeat, not tested much yet.

    At this time the values are fixed, if you want it a bit faster you could use 250/150 instead.

  • Now each sent key gets released 30 ms later.

    Maybe I should send only one release at the end in case of repeats?

    But maybe for kodi it works better as it is?

  • Hi,


    250/150 is working perfect for me! That was a quick fix:)


    As for the devices: I only see the hidraw device, not the keyboard.

    I also tested "hidusb-dump" and signal11/hidapi : hidtest-hidraw


    In hid.c: hid_enumerate there is a

    dev_enumerate_add_match_subsystem(enumerate, "hidraw");


    doesn't this mean, it will only give me the hidraw devices ???


    I also saw an issue about hidapi, that it would skip already open devices. The keyboard is in use (Xorg)

    could that be the problem ? (although I tested hidusb-dump without a running X, that was the same.


    Greetings René

  • Hi René,


    please test last git, I added "send release only after last repeat" (plus "fix mistake").

    This is theoretically better, but I wonder if it actually works better?


    I don't have the time to look into the devices issue now.


    Regards, Jörg

  • Hi Jörg,


    about repeat: The new version seems to be oke, but maybe the first release will be a bit slower ? (120 vs 30?)

    In practise it seems to work oke (tested in vdr).


    about usage: With the patch :

    I still get one device for our stm32 but with valid fields.

    usage-page==FF and usage==1
    These values are defined in usb_desc.c (CustomHID_ReportDescriptor), so I think that is correct.


    Greetings René







  • Hi René,


    if you check keypresses with evtest, you see that the new version creates "repeats", while the previous created just new keypresses.

    Old:...1 0 1 0 1 0 1 0 1 0

    New: 1   2   2   2   2 0

    1 = first keypress

    2 = repeat

    0 = release

    That the release takes a little longer doesn't matter. For speed only keypress/repeat counts.


    Under linux I have only one device, too (I was mistaken), so I guess the patch isn't necessary.

    Thanks for testing the patch, anyway :)


    Have you tested with kodi?

    I wonder what a good template for kodi would look like (something like this based on that and that).


    Regards, Jörg