Beiträge von Dieter

Hi,

jetzt habe ich den C-Code analysiert und verstehe warum du meine Frage nicht verstandest.

Ich bin über den Variablennamen "evdev" gestolpert und habe deshalb in eine andere Richtung gedacht.

Aber das ist nur ein struct der den Pfad und file desc enthält (und zu weiteren verlinken kann).

typedef struct evdev {
    char *name;
    int fd;
    struct evdev *next;
} evdev_t;

Damit war die Funktion klar. So habe ich die HIDRAW früher (in C++) auch verwendet.

Ein QuickHack zeigt dass es auch in Python so geht.

Bin am überlegen ob ich das hidapi Modul raus nehme. Es bringt hier nichts und es ist eine weiter Abhängigkeit.

(und hat mich einiges Zeit gekostet bis ich die richtige udev Regel hatte. Deine udev reichte nicht aus)

Die Daten kommen (bei mir) direct vom HIDRAW device (IRMP), werden geparsed, dann werden Adr, Command etc in einen String gepackt (wie bei der C-Version auch und mit sendall in den Socket geschrieben.

IRW (oder mein Python client) lesen vom Socket und zeigen die Daten dann an.

./irmplircd.py
LIRC UNIX Socket listening on path /home/USER/lircd
Read the data in endless loop
Accepted connection from client
15000f042200 0 KEY_OK IRMP
15000f042200 1 KEY_OK IRMP
15000f042200 1 KEY_OK IRMP

irw /home/USER/lircd
15000f042200 0 KEY_OK IRMP
15000f042200 1 KEY_OK IRMP
15000f042200 1 KEY_OK IRMP

Das lokale Socketfile habe ich nurs für debugging, später wird der im /run sein wie bei der C-Version.

Es sind auch noch Debugausgaben drin.

Ich muss mir die C-Version nochmals anschauen...

ja, ist mir klar, habe mich nur gewundert warum das bei irmplircd noch drin ist.

Hi,

seit einiger Zeit arbeite bastle ich am IRMP auf dem Raspberry Pi Pico (RP2040).

Mein Fork von Jörgs Repo.

Im Verzeichnis Examples/Python habe ich ein paar Beispiele der Verwendung in Python geschrieben.

Jetzt auch einen irmplircd.py sowie lircd_client.py (~irw).

Einfach weil ich lernen wollte wie man sowas mit Python macht. Da bin ich Anfänger (aber +30 Jahre C/C++ und andere).

Meine Frage an die Geeks: Der originale irmplircd in C liest auch per evdev. Ist das nur weil er vom inputlircd abgeleitet ist oder braucht man das?

Habe ich noch nicht drin (und ist für meine Anwendung nicht notwendig).

Ideen:

- Map file als Verzeichnis (/etc/irmplircd/irmplircd.d)

- Map files auch für Rückwärtsübersetzung (Name nach Code)

- Clienten können per sendall IR-Codes senden (~irsend) (deshalb die Rückwärtsübersetzung)

- Clienten können per sendall die Status-LED schreiben und auch meine NeoPixelerweiterung verwenden

Dann wäre alles an einem Platz wie bei Lirc auch.

Meinungen?

Hi,

habe ich kürzlich entdeckt und jetzt verwendet. Ist ein gute Hilfe für USB-Tests.

USB sniffer auf Github

Für weniger als 10€ eine Klasse Sache. Ist allerdings auf Low- und Fullspeed beschränkt.

Kann man auch nicht mit dem LeCroy oder dem Ellisys vergleichen, aber die liegen weit außerhalb des Budgets im Hobby.

Aus meiner Sicht nicht, aber vielleicht Abhängigkeiten?

CMD_NEOPIXEL=40;

Mache ich so.

Statusled zeigt an das VDR an ist?

Oder Aufnahme?

Ich habe zweifarb Leds rumliegen.... what about: grün: VDR, rot Aufnahme

Man könnte auch analoge RGB Leds nehmen, aber dann sind die Neopixel fast günstiger (1 Streifen mit 8 LED ~ 0,85€ beim Ali.

Oder eine von meinen 8 ist für VDR/Aufnahme. Aber da gibt es ev. Probleme da von zwei Seiten zugegriffen wird (Plugin und mein WAF-Daemon).

Die wissen ja nichts voneinander. Braucht ein "Store/Resume" Befehl...

Ach, nochwas.

Die StatusLed und der Neopixel verwenden den gleichen GPIO.

Falls jemand (ich?) beide haben will gibt es ein Problem.

Vermutlich verschiebe ich den Neopixel. Gibt es schon andere verplante GPIOs?

Vielleicht emuliere ich die Statusled auch mit einem Neopixel. Mal sehen.

Gehäuse muss ich vermutlich neu drucken weil die gewinkelten USB-Stecker mehr Platz brauchen als ich vorgesehen habe.

Dann kann ich auch eine Statusled vorsehen.

Habs nach set_handler verschoben.

Leider mussten dadurch auch die Offsets im Report angepasst werden.

README.md muss ich noch anpassen, aber RunLight.py passt schon.

Zu den CMD_NEOPIXEL:

Falls du die nicht ins enum nehmem möchtest, lasse ich Platz. Schreib was dir lieber ist.

Ich muss die README sowiso anpassen.

CMD_NEOPIXEL=40;

Hi Jörg,

Parser ist in main weil da schon etwas war. Werde das anpassen, Callback gefällt mir besser.

Bitte auch die CMD_NEOPIXEL,... rein nehmen sonst ist die Gefahr groß dass wir inkompatibel werden.

enum command {
CMD_EMIT,
CMD_CAPS,
CMD_HID_TEST,
CMD_ALARM,
CMD_MACRO,
CMD_WAKE,
CMD_REBOOT,
CMD_EEPROM_RESET,
CMD_EEPROM_COMMIT,
CMD_EEPROM_GET_RAW,
CMD_STATUSLED,
CMD_NEOPIXEL,
CMD_NEOPIXEL_INIT,
};

Status update:

Habe Jörg einen ersten PR geschickt.

done

hatte ich mir auch überlegt.

Wenn du einverstanden bist ändere ich das.

In Github hat es mehr Bilder.

Github repo

Status:

Github enthält Sources (keine binaries).

Erster Test war erfolgreich.

Werde jetzt ein Python-Programm schreiben das die HidReports senden kann.

Hi,

hier möchte ich über einen Erweiterung zu IRMP_STM32 berichten und Diskutieren.

Ich habe Jörgs Repo "geforked" damit ich hoffentlich PRs schicken kann.

Mein Fork

Die Idee:

=======

Jetzt-Zustand:

--------------------

Auf einem Banana PI läuft ein in Python geschriebener Daemon der die Geräte entsprechend der Aktivität umschaltet (Fernsehen, Musik hören, etc).

Er greift auch per ETH auf manche Gerät zu um z.B. den Status von Mute zu steuern (Die FB macht ja nur Toggle), Eingänge zu setzten oder die Lautstärke je nach Eingang zu setzten.

Die Tasten A,B,C der FB URC-7980 steuern die Aktivität. (Bei der URC-3661 will ich direkt die Aktivitytasten verwenden weil die auch schöne Icons drauf haben - aber ich schweife ab).

Es gibt auch eine Android APP, die kann dann noch ein paar weitere Aktivities einschalten.

Wenn der Daemon beschäftigt ist blinkt eine LED. Diese soll durch etwas schöneres ersetzt werden.

Soll-Zustand:

-------------------

Der IRMP soll Neopixel (8 Stück auf PCB) ansteueren. Per Hidreport (neue ID) werden bis zu 63 Leds angesteuert. Lauflicht etc wird vom Host aus gesteuert.

Man könnte auch noch normal LEDs einbauen die dann z.B. als "Recording-LED" dienen könnten.

Warum?

------------

Weils schön ist, mir langweilig ist (bin Rentner), ich es kann, weil ich dann doch vielleicht die Anzahl 50 bei meinen USB-Entwicklungen erreichen kann (bin bei +40 seit 1996)

Jörg: Bist du an PRs interessiert?

Versuche die auf dem WS2812-Beispiel des Pico-SDK aufbauen waren erfolgreich, braucht kaum Resourcen. Das Bitbanging für die WS2812 macht ein PIO und langweilt sich dabei.

Die LED-Daten aus dem Report herauszuholen und in die WS2812 zu schreiben braucht nur ein paar µS (den Teil muss ich noch implementieren)

Ein Gehäuse habe ich auch schon entworfen (openscad). Deckel ist transparent (milchig), sieht man im Film. Musste ihn in .txt ändern da mp4 hier nicht zulässig sind. Sind nur ein paar Sekunden um eine Eindruck zu bekommen.

Hi,

senden per IR habe ich jetzt auch noch richtig mit IR_Dioden und einem LIRC-Empänger, LG-TV und Onkio-Verstärker getestet.

Alle reagieren korrekt auf die Signale.

Very good job!! und Danke für die schnelle Hilfe.

PS: Wegen Statusausgabe per Neopixel eröffne ich einen neuen Thread.

hi,

Aber Miropython auf dem 2040 hat keinen Freertos Unterbau. Das ist nur so beim ESP32. Dort gehen viele Threads.

Signal nach Boot ist mit dieser Änderung ok.

irsnd_init (void)
......
#  elif defined (ARM_RP2040)                                                        // ARM_RP2040
        /* GPIO Configuration */
        gpio_set_function(IRSND_BIT, GPIO_FUNC_PWM);
        slice_num = pwm_gpio_to_slice_num(IRSND_BIT);
        pwm_set_output_polarity(slice_num, true, true);
 >>>>>  gpio_set_outover(IRSND_BIT, GPIO_OVERRIDE_LOW);    <<<<<<<<<<<<

        irsnd_set_freq (IRSND_FREQ_36_KHZ);                                         // set default frequency

Good job!

sowohl zwischen den Bits als auch zwischen den Paketen ist das Signal L.

Nur nach dem Boot ist es noch H bis zum ersten Paket. Aber das dürfte trivial sein.

Kann ich als Übung machen, nächstes Jahr.

PS: I will später noch einen Neopixelstreifen ansteuern (mit PIO, gibt ja sogar ein Beispiel im SDK).

Der soll den Status meines WAF-Daemon* anzeigen.

* WAF-Daemon:

Pythonprogram das die Geräte steuert (Ein/Aus, Eingänge, Lautstärke).

Ursprünglich wollte ich das in den Pico rein nehmen, aber Micropython kann nur zwei Threads und ich brauche pro Gerät einen.