Beiträge von M-Reimer

    Nochmal als "Referenz" was ich da treibe mit den "Variablen" (die eigentlich keine sind).


    Mein "Angelpunkt" sind diese Zeilen:

    https://github.com/arduino/Ard…/arduino/USBCore.cpp#L768


    Der "Status" eines USB-Geräts kann am Auftreten von gewissen "Ereignissen" (am Atmel Interrupts) festgemacht werden. In unserem Fall sind das die Interrupts "WAKEUPI" und "SUSPI". Diese selbst können wir aber nicht abfangen oder "empfangen" weil die Arduino-Lib selber dafür eine Interrupt-Service-Routine definiert. Wovon man aber profitieren kann, ist, dass (wie am Kommentar darüber schon ersichtlich) zur "Stabilisierung" des ganzen Interrupts "getogglet" werden:


    https://github.com/arduino/Ard…/arduino/USBCore.cpp#L773

    https://github.com/arduino/Ard…/arduino/USBCore.cpp#L783


    Das Register "UDIEN" ist aber global. Was die Arduino-Lib hier macht kann also von jeder Stelle im Code (auch im "Arduino-Sketch") gelesen werden. Auf dem Weg kann man ohne Änderungen den Status des Controllers lesen indem man diesen Code-Teil der Arduino-Library für eigene Zwecke "missbraucht".


    Was ich oben beschrieben habe (RX-LED) wäre zwar in der Theorie möglich, aber man müsste dann, dass die LED bei "laufendem PC" auch aus geht, das Timeout abwarten:


    https://github.com/arduino/Ard…/arduino/USBCore.cpp#L768


    Und ich bin mir nicht sicher ob ich wirklich irgendwo > 100 Millisekunden verschenken will. Die Lösung mit den Interrupts ist "schöner" und bei den meisten Mainboards sollte sie funktionieren. Auf dem "problematischen" geht ja nichtmal die FT232RL-Lösung und das ist ein ASIC. Wenn der schon nicht geht, warum sollte dann etwas anderes auf Biegen und Brechen funktionieren?


    Die "SOF-Lösung" ist schöner und auch zuverlässiger. Allerdings kümmern die bei Arduino sich eh nicht um den entsprechenden Bug oder Pull-Request. Man wird also erstmal mit einem Würaround nach Wahl leben müssen.


    https://github.com/arduino/Arduino/issues/7363

    https://github.com/arduino/Arduino/pull/6964


    Ich weiß nicht wie und nach welchem Prinzip bei denen entwickelt wird, aber eine handelsübliche Rennschnecke ist schneller :evil:

    Das mit den Variablen ist ein Hack um zu vermeiden, dass man die Arduino Libs anpassen muss.

    Es handelt sich um Interrupt Enable flags die in den Arduino Libs umgeschaltet werden.

    Das mit den Start Of Frame Ereignissen wird gehen. Am gleichen Mainboard habe ich einen IRMP_STM32 laufen und da ist die Erkennung genau so gelöst.

    Eventuell habe ich aber auch dafür einen Workaround. In den Arduino Libs wird das SOF Ereignis genutzt um die RX und TX LEDs auszuschalten. Meine Vermutung nach kurzer Recherche im Code ist, dass die RX LED bei ausgeschaltetem Rechner dauerhaft leuchtet. Und das könnte man eventuell auswerten.

    Aber wenn es dir nur darauf ankommt, dann kauf dir doch ein digitales Radio, welches du mit eben den genau gleichen Batterien auch ganz genauso lange laufen lassen kannst. Gibts doch tatsächlich zu kaufen, z.B. eines von Grundig für weniger als 40Euro. Oder von Medion unter 35.. ;-)

    Gibt es sowas wirklich?


    Ich habe das hier:

    https://www.amazon.de/dp/B00EYWW20G


    Und hier mal eine von vielen Rezension dazu:

    https://www.amazon.de/gp/custo…l?ie=UTF8&ASIN=B00EYWW20G


    Ich kann mir auch nicht so recht vorstellen, dass irgendein Digitalradio auch nur annähernd an die Laufzeit (mit Batterien) eines klassichen UKW-Geräts rankommt.


    "Notfallsicherheit" ist allerdings generell "out". Bei Analog- oder ISDN-Telefon war auch noch eine Notspeisung vom "Amt" vorgesehen (wahrscheinlich sogar vorgeschrieben). Ja, man konnte tatsächlich ohne Strom (aus der Steckdose) telefonieren. Im "Amt" wurde da "damals" sogar ein ziemlicher Aufwand (Batterien, Generator) betrieben um das tatsächlich sicherzustellen. Heute alles Geschichte. VoIP ist für den Netzbetreiber viel billiger.

    Liegt an systemd. Systemd verwaltet den Powerbutton selber (oder besser gesagt macht das logind). Möglichkeiten gibt es sicherlich mehrere. Ich möchte dennoch mal Werbung für mein Projekt machen:

    https://projects.vdr-developer.org/git/vdrpbd.git/

    Einfach installieren, mit systemd aktivieren und fertig.

    Optional, aber für saubere Systemd-Anbindung nötig ist "Net::DBus". Heißt bei "Debian-basierten" wohl so:

    https://packages.debian.org/de/jessie/libnet-dbus-perl

    Geht auch. Es gibt mittlerweile einige solche "USB-Grafikkarten", die auch unter Linux gehen. Auch die müssten ein Framebuffer-Device liefern.


    Herausforderung ist es, das passende zu finden. Hier wird eventuell eine udev-Regel fällig um das richtige immer an der gleichen Stelle zu haben.

    Ist letztlich die Entscheidung von Klaus wie er VDR erweitert. Von den Änderungen in Richtung Vernetzung in 2.4 sehen die Nutzer, die Fremdclients nutzen oder ohne große Ambitionen in Richtung Vernetzung, halt eher wenig. Favoritenlisten wären für jeden von Vorteil. Eben sofern die API dafür wenigstens grob für Kodi passt.

    Wenn's klappt, dann mach hier mal einen Thread dazu auf.


    Ich habe an meinem HTPC zwar tatsächlich eine zweite Grafikkarte (onboard) aber kein TFT zum Testen. Sonst würde ich das selber mal probieren.

    Wie wird das Ding angesteuert? Da steht was von "SVGA". Also eine eigene Grafikkarte nur dafür?


    Es gibt einen Treiber der auf einen Framebuffer ausgeben kann und auf allem was an einer Grafikkarte hängt sollte unter Linux auch eine reine Framebuffer-Ausgabe möglich sein. Also in der Theorie. Frag mich nicht wie sowas konfiguriert wird.


    Vorteil: Graphlcd kommt ganz ohne Patch im VDR aus.

    Nachteil: Deine Ausgabe wird deutlich weniger "Fancy" sein wie das was du von graphtft gewohnt bist. Graphlcd hat aber ein Skin-System. Du könntest dir da also nach deinen Wünschen etwas basteln. Also mit den zur Verfügung stehenden Mitteln.


    Graphlcd hat andere Ziele und es ist nicht angedacht das in Richtung "graphtft" zu entwickeln, denn damit riskierst du nur, das etwas neues entsteht, dass irgendwann keiner mehr supporten will.

    Und wenn die Bekannten Internet haben, könnte man die Änderungen in der Channels.conf sogar remote machen.

    Sorry aber nein. Irgendwo hört die Bereitschaft zur Unterstützung auch auf. Eine Lösung, die der "ganz normale" User nicht bedienen kann, ist nicht benutzerfreundlich. Und auch ich fand das rumeditieren in der channels.conf schon immer ausgesprochen lästig.


    Hätte mich ja schon mal interessiert wie Klaus dazu steht und welche Priorität das Thema hat.