Beiträge von M-Reimer

    In der Theorie könnte man das sicher tun.


    An der Stelle wäre ein Board mit DAB+ allerdings doch etwas interessanter.


    Für meine Zwecke kann ich mit dem Raspberry selbst schon genügend "Radio" machen. WLAN hat er an Bord und Internetradio geht somit ohne jegliche Anbauten.

    Ich würde mal vorsichtig behaupten, dass der Kondensator seinen Zweck nicht erfüllen wird. Die Betriebsspannung sollte schon halbwegs stabil auf dem Board vorliegen. Sonst hätte auch der Mikrocontroller ein Problem.


    Der zusätzliche Kondensator soll eigentlich Schwankungen oder Störungen blocken und das kann er am besten so nahe am TSOP wie möglich. Ich habe in der Vergangenheit schon IR-Empfänger mit etwas längerem Kabel gebaut und dort habe ich einen Keramik-Kondensator direkt an den TSOP gelötet.


    Ansonsten aber eine saubere Sache. Ich hätte die Pads für die Stiftleiste als "Rechteck" ausgelegt und eine gerade Stiftleiste in Verlängerung zur Platine flach da draufgelötet. Die gewinkelte Stiftleiste, zur Platine gerichtet, sieht schon etwas "speziell" aus :P

    Selbst wenn nicht, wäre das Ding aber trotzdem etwas schneller als die Grafikkarte, bei gleichzeitig niedrigerem Stromverbrauch und geringen Anschaffungskosten...wenn es denn überhaupt unter Linux läuft. Die Frage wurde ja immernoch nicht beantwortet.


    Die wird dir mit großer Wahrscheinlichkeit hier auch keiner beantworten können.


    Würde mich nicht wundern wenn das Ding unter verschiedenen Namen auf den Markt gekommen wäre. Also selbst wenn es funktionieren könnte bräuchte man Product und Vendor IDs um anständig danach suchen zu können.


    Und passende Software bräuchte man neben dem Treiber auch noch, denn irgendwer muss das Video durch deinen Stick schieben.


    Bezüglich Raspberry ergibt sich ja dann noch das Problem, dass Hardware-Beschleunigung ersteinmal freigeschaltet werden muss. Der Key ist zwar nicht teuer. Wenn man aber gar kein Openelec benutzt weiß ich gar nicht wie man den ohne config.txt aktiviert.

    Ich würde es ja über die "config.txt" versuchen :P


    Die ist Bestandteil der "Raspberry-Firmware" und die hat irgendwo jede Distribution dabei, da das Ding nur so bootet.


    Videos dann auf eine über USB drangehängte Platte und einfach laufen lassen. Du hast den großen Vorteil, dass das Ding nur ganz wenig Strom verbraucht.

    Nachtrag: 1.0.1 ist online. Mit dieser Version ist Kompilieren gegen Freetype 2.9.1 möglich. Ab dieser Version gibt es das in graphlcd-base genutzte Tool "freetype-config" nicht mehr und es muss zwingend pkg-config genutzt werden.

    Ich weiß ja auch nicht. Haben die Leute nicht selbst darum gebeten dort aufgenommen zu werden und dir das Bild entsprechend auch geschickt?


    Jemand hat also bewusst und absichtlich seine Daten dort einstellen lassen. Wie soll das illegal sein? Wenn das illegal wäre, müsste sich Facebook einmal komplett aus dem Netz löschen, denn dort stellen Millionen EU-Bürger freiwillig Daten von sich rein.

    Ich weiß nicht wie das bei Ubuntu gemacht wird, aber letzlich ist das mit dem Systemdienst, der einen X-Server mitstartet, ein ganz großer Verhau. Wir haben bei vdr4arch z.B. dieses faktisch nach wie vor aktuelle Problem: https://github.com/VDR4Arch/vdr4arch/issues/159

    Eigentlich ist xineliboutput auf "modernen" Distributionen der elegantere Weg. VDR als Systemdienst im Hintergrund ohne jede Verbindung zum X-Server und das vdr-sxfe dann mit eigenem Service-File via xinit sauber in eine Session starten.

    Oder eben mit Kodi. Auch den kann man sauber in eine Session starten lassen. Dann geht auch ohne viel Aufwand USB-Hotplug und ähnliches.

    Noch nicht im Zusammenhang getestet (habe die Hardware im Moment nicht hier) aber der Code kompiliert und die Library funktioniert:


    https://github.com/M-Reimer/us…58e2007dfbc83fb321d5778c5


    https://github.com/M-Reimer/USBStatus


    Die Library ist kein Hack sondern die Lösung, die ich für IRMP_STM32 umgesetzt habe und die SHF hier auch schon vorgeschlagen hat. Nur das ich das ganze etwas anders angehe um keine Konflikte mit den Arduino-Libs zu bekommen. Im Prinzip sollte das auch auf meinem "problematischen" Mainboard gehen.


    Die Library habe ich für den Library-Manager vorgeschlagen https://github.com/arduino/Arduino/issues/7529. Falls das also jemand für seine Projekte braucht, dann einfach etwas warten oder von meinem GIT als ZIP installieren. Ich habe die Library unter LGPL3 gestellt. Sollte also für die meisten Projekte einsetzbar sein.

    Zunächst: USBserLCD auf dem 32u4 läuft bestens. Mit dem Interrupt Hack bekomme ich auch mit wenn der PC aus ist.

    Bin da aber noch an einer anderen Lösung dran, die ohne Hack auskommt und nur Arduino Features und Atmel Register braucht. Ist letztlich genau was SHF macht. Kann aber ohne Konflikte mit den bestehenden Arduino Libs zusammenarbeiten. Ich habe vor das als kleine Arduino Library umzusetzen und in den Library Manager zu bekommen.

    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