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

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

Projektseiten:

IRMP_STM32_KBD

IRMP auf STM32 – stark vereinfachte Bauanleitung

IRMP auf STM32 - Bauanleitung

Verkauf im Forums-Marktplatz:

Verkauf:STM32 Sticks und Arduino USB IR Empfänger, RP 2040 Zero I.R. Empfänger kompl.

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

Entstanden aus:

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

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

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.

Quote from vdr_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.

Quote from vdr_rossi

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 ...

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.

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!

IRMP_STM32_KBD:

Jetzt gehen auch die Modifier Alt, Shift, Ctrl.

Unter Windows stört noch, dass von QWERTY auf QWERTZ übersetzt wird.

Da muss noch die Übersetzungstabelle angepasst werden.

Ansonsten läuft es ganz gut.

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 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

This might help for the usage issue.

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

It did