Hinten sind die Ausgänge zum Ziel, wenn der Stick etwas anderes flasht.
Wenn der Stick selbst das Ziel ist, muss man an die 4 internen Kontakt-Löchlein (Eingänge).
Für Ground und 3V3 kann man die hinten nehmen, aber CLK und DIO müssen die internen sein. Und die muss man erst mal identifizieren.
Wenn ich mal Bilder von allen Bauweisen habe, stelle ich die interne Pin-Belegung mal in ein Wiki. Findet man aber auch im Internet und hier im Thread.
Nein, nur wenn sie "verbastelt" sind.
Es gibt mindestens drei verschiedene Bauweisen, die von Außen gleich aussehen.
Deswegen muss man beim Flashen gucken, wie die Belegung der 4 Löcher ist. Dazu steht hier schon Einiges (aber ev. nicht Alles).
Dein Problem kann ein Hardware-, ein Software- oder ein Konfigurationsproblem sein.
Ohne Messen tappst du im Dunkeln.
Bleibt er denn aus, wenn du im Betrieb so lange auf den Powerschalter drückst (ca. 10 Sekunden), bis er ausgeht (du ihn also "abwürgst")?
Was für eine Spannung misst du auf PS_ON?
1. während er noch läuft
2. beim Runterfahren
3. danach
4. wenn er von selbst wieder hoch fährt
Schau mal hier und folgende.
"%Y-%m-%d-git+<git commit>" von seahawk1986 oder ähnlich finde ich gut.
Der Patch von eins höher ist nur für VDR 2.2.0 und femon 2.2.2 .
Seit ca. Mai 2017 können VDR 2.3.4 und höher sowie femon 2.3.0 (und höher) DVB API 5.
Dafür wäre DVB API 5 im stv090x-Treiber angesagt, das könnte man von dddvb übernehmen.
Dementsprechend der Patch aus #9 an vdr-femon-2.2.2 angepasst (noch völlig ungetestet). Wie gesagt erst ab Kernel 4.10.
Hier eine verbesserte und getestete Version:
Für HID gibt es hier eine Vorlage: https://github.com/libopencm3/…es/stm32/f1/other/usb_hid
Als Einstieg könnte man den uC mit stm32IRconfig{_gui} kommunizieren lassen.
Dazu muss der Report Descriptor eingebaut werden und ein paar andere Anpassungen an den Descriptoren übernommen werden und buf[] angepasst werden.
Damit sollte man bald zum ersten Erfolgserlebnis kommen.
Ein weiterer Schritt wäre die Eeprom Emulation mit libopencm3.
Der letzte Schritt wäre dann, alle ST Funktionen durch libopencm3 Funktionen auszutauschen.
SSH mit X-Forwarding
wollte ich schon immer mal antesten. Auf meinem Windows Rechner Xming installiert, putty konfiguriert, und geht: stm32config_gui vom VDR auf dem Windows Desktop.
Mit TAG+="uaccess" und als normaler Benutzer.
Das geht vermutlich deshalb, weil nach einloggen per ssh der normale Benutzer einen aktiven Seat hat.
Durch den Wechsel von hidapi-libusb auf hidapi-hidraw ist das nicht mehr nötig.
Statt jedem auf dem System Schreibrechte für das HID-Gerät zu geben würde ich das lieber auf eine Gruppe wie dialout beschränken.
Was hälst du davon, statt z.B. GROUP="plugdev" das modernere TAG+="uaccess" zu verwenden?
Im git habe ich stm32IRconfig_gui für Linux von libusb auf libudev umgestellt.
Damit haut der Start von stm32IRconfig_gui nicht mehr das /dev/hidraw* weg.
Bitte testen und rückmelden 
.
Schon direkt nach dem Start von stm32IRconfig_gui haut es das /dev/hidraw* und den Symlink weg.
...
Statt rebooten hilft auch ...
Hi,
Reboot geht in der Regel schneller, wenn der Stick im Inneren verbaut ist.
Gruß
Noch schneller geht Reboot des Empfängers (wenn man wakeup7 programmiert hat).
Ein Tastendruck und es geht wieder.
Letztlich hast du deren Code angepasst und mit großer Wahrscheinlichkeit fällt das dann so automatisch unter deren Lizenz.
Nicht solange ich es nur als Patch habe. Das ist ja gerade der Witz an der Sache.
libopencm3 verwende ich bereits in einem meiner Bootloader.
Das hat Vor- und Nachteile. libopencm3 kann einfach nicht alles, was die ST Libs können.
Manches ist dort aber schöner und sauberer.
IRMP-STM32 möchte ich aber nicht noch mal komplett auf libopencm3 umbauen.
Der USB-HID Patch war unglaublich viel Arbeit. Den verschenke ich nicht an ST 
.
Deine Idee mit den submodulen gefällt mir zwar, aber das Lizenzproblem wird dadurch nicht gelöst.
So hat man dann auch keine Lizenzmischung im Haupt-Repo.
Doch, bei den Binaries. Ist jetzt aber auch schon.
Statt der Patches dann ein Branch im "ST Libs" GIT mit diesen Anpassungen.
Auch da stellt sich wieder die Lizenz-Frage. Die Patche sind ja auch GPL.
Der Vorteil wäre hauptsächlich, dass der manuelle Download mit Anmeldezwang entfällt.
Man könnte überlegen, ein ST-Libs-git nicht als submodul, sondern irgendwie anders zu "importieren". Also etwa so: Das Skript holt sich das ST-Libs-git und patcht es (statt auspacken der manuell geholten ST-Lib und patchen).
Das wäre machbar und praktischer.
Mein erster Gedanke ist, dass damit die Problematik nur verlagert, aber nicht gelöst wird.
Es wäre aber sicherlich besser als vorher.
Die eigentliche Frage ist, ob ST eine neue Lizenz macht, die Mischen mit GPL explizit erlaubt.
Denn dass sie das bisher tolerieren, ist ja keine Garantie für die Zukunft.
Im Grunde macht sich jeder, der, um es Usern leichter zu machen, ST Libs und eigenen GPL-Code mischt, abhängig von ST‘s Wohlwollen.
Das ist ja bisher auch gut gegangen.
Ich persönlich fühle mich mit der Trennung aber besser.
Du könntest anfragen, ob sie das Mischen von Github Code unter GPL mit den ST-Libs ausdrücklich erlauben.
Und wenn nicht, ob sie das Einbinden von ST Libs als Submodule in Github GPL-Code ausdrücklich erlauben.
Das wäre ja schon mal ein großer Schritt weiter für uns.
Zitatif you are in compliance with the license terms
Genau das ist ja der Knackpunkt.
Als ich mich damals damit beschäftigt habe, konnte ich nicht beurteilen, ob das zutrifft.
Ich bin kein Rechtsanwalt, und als Laie ist mir das unverständlich.
Soweit ich mich erinnere, geht das Vielen genauso und ist schon oft kritisiert worden.
Bisher lassen sie die Leute machen, aber die Frage ist ja, ob wir eine verlässliche Rechtsgrundlage haben.
Internationales Lizenzrecht ist für Laien schwer einzuschätzen. Vertragen sich die ST-Lizenz und die GPL?
Und ist das normal, dass wenn ich stm32IRconfig_gui benutzt habe, ich irmplircd nicht mehr gestartet bekomme? Ich muss rebooten, dann geht es.
Ich hab' das jetzt auch mal getestet (auf openSuse) und ich habe dasselbe Problem.
Schon direkt nach dem Start von stm32IRconfig_gui haut es das /dev/hidraw* und den Symlink weg.
Müsste man mal erforschen, was da schief geht ...
Statt rebooten hilft auch USB an- und abstecken bzw. den 5V Standby am USB an- und abstecken (wenn man den hat).
Mach mal die Messungen, die unten bei https://www.mikrocontroller.ne….C3.BCr_erfahrene_Bastler stehen. Was sind deine Ergebnisse?
