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

  • Hatte ich am Anfang bereits geschrieben, dass ich mich da eingelesen habe.
    Leider scheint es an elementaren Dingen zu happern.


    Ich versuche gerade das "stm32-irconfig-gui" auf der Konsole zu starten (sterm aus dem VDR heraus), aber leider kennt der Rechner den Befehl nicht.
    Da mache ich bestimmt eine Kleinigkeit falsch (komme von Debian, mag sein das es dort ein wenig anders funktioniert, aber das sollte bei yaVDR nicht so weit weg sein).


    Bin ein wenig verwirrt orientierungslos.

  • Ich versuche gerade das "stm32-irconfig-gui" auf der Konsole zu starten

    Dazu muss das Paket stm32-irconfig-gui installiert sein. Das Programm selber heißt stm32IRconfig_gui

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Herzlichen Dank.
    Das Paket war ja installiert, aber der Aufruf des Programms ist auf Grund des falschen Namens (Startbefehls) gescheitert.
    Jetzt kann ich es starten.


    ... jetzt nimmt der VDR aber auch leider auf :-) und ich muss erst einmal bis morgen pausieren.


    Da bleibt aber immer noch mein persönlicher Konflikt mit den der KEYMAP / Keytable / "lircd.conf" / ...
    Ich denke da brauche ich auch noch eine Initialzündung :-)


    yaVDR ist wirklich super. Manches mal verliert MANN aber den Kontakt zur Basis weil einem eben Aufgaben abgenommen werden ... was die meisten und auch ich ja wollen.
    Egal wie, Shaka, ich schaffe das :-) !

  • Da bleibt aber immer noch mein persönlicher Konflikt mit den der KEYMAP / Keytable / "lircd.conf" / ...

    Welche Konflikt? Die lircd.conf spielt keine Rolle, weil der Empfänger über irmplircd angesprochen wird, nicht über lircd. Die Keytables für rc-core Empfänger sind auch außen vor, weil die völlig andere Keycodes nutzen. Alles was du tun musst (und da ist es völlig egal, ob gerade eine Aufnahme läuft oder nicht, wenn du nicht willst, dass er auf die FB reagiert schickst du im einfach ein "svdrpsend remo off") ist dich mit irw an den Sockel /var/run/lirc/irmplircd zu hängen und dann eine Datei anzulegen, in der die Tastencodes dem gewünschten Tastennamen zugeordnet werden. Und den Pfad für die Datei hinterlegst du (wie in der yaVDR-Dokumentation beschrieben) in der /etc/default/irmplircd.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • @VDRFirtie: Eine Beispiel map-Datei findest du hier. Die legst du irgendwo ab, und definierst

    Code
    1. KEYMAP="/irgendwo/irmp_stm32.map"

    Die kannst du dann entsprechend deiner Fernbedienung bearbeiten.


    seahawk1986 : Was meinst du, würde es die Sache für Anfänger nicht einfacher machen, wenn der Pfad und eine *.map schon voreingestellt wären?

  • seahawk1986 : Was meinst du, würde es die Sache für Anfänger nicht einfacher machen, wenn der Pfad und eine *.map schon voreingestellt wären?

    Ich merke es mir mal für die Umstellung der Pakete auf Systemd vor.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Da nun auch Reset funktioniert (und zumindest als der Widerstand noch nötig war) mir die ST-Link mir auch mechanisch recht unsympathisch waren, habe ich mal etwas neues probiert.


    Das Ergebnis siehe Fotos.


    Das gute: Mechanisch finde ich das ganze super, nichts wackelt !
    Negativ: 2*40 + 16 + Widerstände+C (= >100) Lötstellen wenn man alles lötet. (Das dauert etwas. Aber man muss ja nicht alles löten)


    ed: Platinen habe ich noch reichlich, und einzelne fertig würde ich auch abgeben...


    PS: jrie : Ich habe neue Fotos gemacht. Die ersten zeige ich niemanden :-(

  • Ich habe noch 2-3 blaue ST-Links gefunden. Daran habe ich nicht geändert, auch keinen Widerstand eingelötet.


    Darauf habe ich geflasht (nicht die Variante old_with_pulldown!):
    IRMP_STM32/binaries/bootloader/IRMP_STM32/binaries/bootloader/boot.blue.bin und dann per USB:
    IRMP_STM32/binaries/firmware_for_bootloader/SimpleCircuit/2017-01-19_19-18_Blue_SC_BL_jrie.bin



    Aber es wird kein USB-Device enumieriert...
    Liegt der Fehler bei mir ? (Für mich waren die oben genannten Files schlüssig...)



    ed: Ergänzung: Noch einen blauen ST-LINK gefunden... Dieser funktioniert einwandfrei. Man könnte fast meinen: besonderes Pech ! (Aber komisch ist das schon !)

  • Ich habe die von dir benutzte Firmware nie selbst auf einem Blauen testen können, da ich keinen mehr habe. Aber wenn es auf deinem letzten Blauen läuft, muss ja wohl die Firmware OK sein.
    Kürzlich habe ich von dir einige defekte Blaue bekommen, die „von selbst“ kaputt gegangen sind. Könnte also sein, dass die, die du zuerst getestet hast, halb defekt sind.


    „Komisch“ finde ich das auch. Da der Bootloader erkannt wird, geht USB offenbar, aber dann bei der Firmware nicht.


    Was du tun könntest: Die geflashte Firmware auslesen und prüfen, ob mit der geflashten identisch.


    Vielleicht hast du Pech gehabt, und Boards schlechter Qualität bekommen.
    Mir selbst ist bisher nur ein einziges Board kaputt gegangen, und da auch nur ein Pin.
    Und da ich viel experimentiere, kann es gut sein, dass ich den aus Versehen mal kurz geschlossen habe.


    PS: Es gibt übrigens neuere Firmware-Binaries seit ein paar Tagen.

  • So sehen sie zur Zeit bei mir aus:

    Die Sticks sind eingeschrumpft (auch wenn das auf dem Foto kaum zu erkennen ist).
    Die zwei abgebildeten sind aktuell zu haben.


    Edit: Die zwei Letzten gibt es jetzt auf Wunsch auch mit Mainboard-USB-Pfostenstecker-Adapter.


    Edit2: Es gab eine Preissenkung.

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

  • Hallo und vielen Dank für das schöne Projekt.


    Ich hoffe damit endlich mein Problem mit der Fernbedienung in den Griff zu bekommen.
    Seit vielen Jahren lief ein yavdr0.3 und nachdem nun leider das Motherboard von heute auf morgen den Dienst verweigerte musste ich einen neuen VDR auf Basis yaVDR 0.6 aufsetzten.


    Nun bin ich also hier gelandet und habe mit das "blueDev" Board besorgt.
    Den USB D+ Wiederstand habe ich auf 1,5K geändert.
    Flashen mit einem USB2Ser und Boot0=1 funktioniert.
    Damit kann ich entweder das File 2017-03-28_16-15_blueDev_jrie.bin oder auch den Bootloader boot.blueDev.bin flashen.
    Leider gelingt es mit nicht mit dem Bootloader die eigentliche Firmware zu flaschen.


    Vorgehen : Programm auf der Komandozeile starten und dann das Board anstecken.


    Das sieht dann so aus :



    Das würde sich endlos wiederholen.
    Wenn ich dann das Board abziehe und anstecke blinkt kurz die LED für den Bootloader und bleibt dann an.
    Es wird aber kein HID-Device sonder nur ein "unbekanntes Gerät" unter Windows erkannt.
    Am VDR kann ich das alles nicht testen da der iim Wohnzimmer steht und außerem von der Familie "blockiert" wird.


    Was mache ich falsch ? Alle Files sind aus dem Git.
    Auch kein anderes Bin kann ich über den Bootloader flaschen. Immer bleibt es bei 98% hängen.


    Auf einem leere Board nur mit Bootloader bleibt der ja im Bootloader-Modus.


    Aber auch so kommt der gleiche Fehler mit 98%.
    Ab dem fehlerhaften flaschen läuft der aber in das wohl defekte Programm da der Bootloader-Modus endet, irgend etwas schreibt er also.


    Auch wenn ich die 2017-03-28_16-15_blueDev_BL_jrie.bin über die serielle Methode flasche geht nichts.
    Weder wenn ich an 0x08002000 noch wenn ich an 0x08000000 flasche.



    Gruß Ronald

    NEW: yavdr 0.3
    Board: ASUS AT5ION-I
    Grafik: (integriert) nvidia GT218
    DVB: Cine S2
    Gehäuse;: Antec Micro Fusion
    Display : IMON Display
    Fernbedienung: UIRT an USB2Ser-Wander (MSI Mediacenter FB)
    TV : Toschiba 37R3500P


    Old: genvdr (vdr 1.4.7) "MediaPortal" 800MHz Celeron, 256MB, 2x FF 1.3, SCART,

  • Als ersten Schritt würde ich mal unter Linux flashen.
    dfu-util 0.9 unter Windows hat bei mir auch nicht richtig funktioniert, hatte aber noch keine Zeit das näher zu erforschen. Ältere dfu-util Versionen haben unter Windows funktioniert.
    Hast du den Bootloader mit Verify geflasht?
    Hat die Nicht-Bootloader-Firmware funktioniert?


    Wenn du nach dem Bootloader die Bootloader-Firmware an 0x08002000 flasht, sollte es eigentlich gehen.

  • Hallo


    Danke für die Antwort unt Entschuldigung für die späte Reaktion.
    Ich hatte eigentlich schon an einer Antwort gearbeitet, aber offenbar vergessen sie abzuschicken.
    Inzwischen ist diese Antwort hinfällig, denn ich habe die Ursache meiner Probleme gefunden : die BINs vom Github funktionieren nicht.


    Auf deinen Empfehlung ein Linux zu nehmen und weil ich gerade einen verstaubten RasperryPi-I neu aufgesetzt hatte, habe ich dort die dfu-util installiert.
    Die Tools sind im Raspian in der Version 0.8 dabei.
    Hier wird das Flashen über den Bootloader zwar ohne Fehlermeldung beendet.

    Code
    1. Download [=========================] 100% 16524 bytes
    2. Download done.
    3. dfu-util: unable to read DFU status after completion


    Aber die Symptome sind die gleichen Bootloader wird erkannt, Firmware läuft nicht :


    Es spielt auch keine Rolle ob ich die Firmware per dfu-util oder per "Demonstrator GUI" an die 0x8002000 flashe.


    Interessehalber wollte ich aber mal testen ob ich die Firmware selbst bauen kann.
    Da ich das nicht auf meinem WindowPC machen wollte ( der ist eh schon voll genug) wollte ich das auf dem RasPi machen.
    Allerdings fehlt im Raspian der arm-none-eabi-gcc ...
    Aber mit Googles Hilfte findet man das hier : https://github.com/ARMinARM/arminarm 
    Damit konnte ich den arm-none-eabi-gcc installieren. (der baut auf Wunsch auch die dfu-util neu in der Version 0.9, die unter Linux auch funktioniert)


    3 kleine Fallen gab es noch.
    1.)
    Das prepare.sh versucht die irsndconfig.h zu patchen, was zur einem Reject führt .
    Das ist aber nur die Auswahl der Protokolle zum IR-Senden. Die kann man händisch nachpflegen.
    2.)
    Zum andere meckert der Compiler:


    Lösung : Im Makefile habe ich die Option ergänzt "COMMON = -g -Os -flto -std=c99"
    3.)
    Danach kommt noch einen Meckermeldung über doppelte Typedeklarationen:


    Lösung: in irmp/irmpsystem.h in Zeile 166 und 167 die beiden Deklarationen auskommtiert

    Code
    1. #if defined(PIC_CCS) || defined(PIC_C18) || defined(ARM_STM32) || defined(STELLARIS_ARM_CORTEX_M4)
    2. typedef unsigned char uint8_t;
    3. typedef unsigned short uint16_t;
    4. //typedef unsigned char uint_fast8_t;
    5. //typedef unsigned short uint_fast16_t;
    6. #endif


    Und schon läuft es durch :D 
    Und noch viel besser : die selbst gebaute Firmware funktioniert ! :D :D :D 
    Beide Varianten klappen, serielles flaschen an 0x8002000 oder auch via Bootloader :


    Was ich noch nicht raus bekommen habe ist, wie der Reset-Pin funktioniert.
    Ich habe etwas über wakeup und wakeupslot 4..7 gelesen. Leider tut sich am Reset-Pin nichts. Die LED blinkt zwar schnell mehrfach wie beim wakeup, mehr aber nicht.
    Wakeup selbst funktioniert. Ohne USB geht der Wakeup-Pin für 500ms an und die LED blinkt schnell.
    Auch die Macro-Funktion habe ich auch noch nicht verstanden.


    Was ich dann noch Suche ist eine Möglichkeit der Erkennung ob mein TV an oder aus ist.
    Ich kann ja nun schön die Power-Taste des TV anlernen und über den IRMP aussenden und den TV abzuschalten (der einzuschalten wenn man den VDR per IR startet).
    Das macht aber nur Sinn wenn der Zustand der TV bekannt ist.
    Leider unterstüzt, nach meinen Recherchen, eine Nvidia-GaKa kein CEC über den HDMI-Anschluss.
    Eine Idee ist die Schaltspannung von der Scart-Buchse abzugreifen und auf ein GPIO zu legen.
    Der STM32 hat ja viele GPIOs frei.
    Leider sind wohl meine C-Kenntnisst zu beschränkt um das in die Firmware einzubauen ...


    Gruß Ronald

    NEW: yavdr 0.3
    Board: ASUS AT5ION-I
    Grafik: (integriert) nvidia GT218
    DVB: Cine S2
    Gehäuse;: Antec Micro Fusion
    Display : IMON Display
    Fernbedienung: UIRT an USB2Ser-Wander (MSI Mediacenter FB)
    TV : Toschiba 37R3500P


    Old: genvdr (vdr 1.4.7) "MediaPortal" 800MHz Celeron, 256MB, 2x FF 1.3, SCART,

  • Hi,
    X erkennt doch den Bildschirmtyp + Auflösung, darüber müsste das doch zu erkennen sein, ob an?


    MfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 512MB PCIe x1 | v2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 750GB F1, GT730, 2x TT DVB-S2-3200) easyVDR 2.3
    VDR5: Gigabyte
    GA-G31M-S2L (Intel E2140, Zotac GT220 512MB + Zalman VNF100, Digitainer2-Geh., t6963c 6 " gLCD, 750GB F1, Sundtek DVB-C + Satelco DVB-C) easyVDR 1.0
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT 3200 | easyVDR 2.3 64bit
    VDR-User #1068 
    www.easyvdr.de 

  • Hallo



    Zitat




    "Einfach so" kann man das auch garnicht auf den GPIO legen. Dann ist der mit Sicherheit tot.

    Ja, das ist schon klar. Als Elektroniker bekomme ich die Spannungen aber angepasst. Nur der Software-Teil fällt mir schwerer ...


    Zitat

    Dir ist bekannt, dass man HDMI-CEC nachrüsten kann? https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter

    Richtig, kostet wieder extra Geld. Bei Amazon.de "nicht verfügbar", bei Amazon.com für 44$ ...
    Hier https://github.com/stefslon/cec-arduino habe ich auch eine Selbstbau-Idee gefunden.
    Da muss ich nur mal sehen ob ich ein Pärchen HDMI Stecker/Buchse bekomme die man gut auf eine Universalplatiene löten kann oder mal ein HDMI-Kable zerschneide.


    Zitat

    X erkennt doch den Bildschirmtyp + Auflösung, darüber müsste das doch zu erkennen sein, ob an?

    stefan : wie macht man das ? Als Ausgabe-Device läuft softhddevice.
    Mit ps finde ich :

    Code
    1. root@vdr6a:~# ps ax | grep X
    2. 1716 tty7 Ss+ 0:10 /usr/bin/X -nolisten tcp -noreset :1 vt7


    Aber wie fragt man das ab?


    Gruß Ronald

    NEW: yavdr 0.3
    Board: ASUS AT5ION-I
    Grafik: (integriert) nvidia GT218
    DVB: Cine S2
    Gehäuse;: Antec Micro Fusion
    Display : IMON Display
    Fernbedienung: UIRT an USB2Ser-Wander (MSI Mediacenter FB)
    TV : Toschiba 37R3500P


    Old: genvdr (vdr 1.4.7) "MediaPortal" 800MHz Celeron, 256MB, 2x FF 1.3, SCART,

  • ein Pärchen HDMI Stecker/Buchse bekomme die man gut auf eine Universalplatiene löten kann


    es gibt Platinen mit Lötanschlüssen, die machen die Sache rel. einfach. Dort zwei kurze HDMI Kabel zu den Geräten dran und gut.



    Es gibt die Teile auch mit Stecker



    dort müssten dann aber geschirmte Kabel angelötet werden. Und diese ordentlich löten macht rel. wenig Spaß

  • ronald_s : Danke für den Bericht. Du bist vermutlich der Erste, der Reset getestet hat. In LED_Switch_init() fehlt leider die Initialisierung für den RESET_PIN, das muss da noch rein.
    Kommt in den nächsten Tagen.
    Die anderen Sachen gucke ich mir auch an, sobald ich mal Zeit habe.