Offizielles 7" TFT Touchdisplay parallel zu HDMI komplett abschalten

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hiho,

    ich versuche seit Tagen mein Touchdisplay des Raspberry 3 B+, offizielles 7" TFT, komplett stromlos zu kriegen, während mein HDMI-Ausgang weiterhin ganz normal funktioniert. Ich habe bisher keine Lösung dafür gefunden und das ärgert mich wahnsinnig.

    Anschluss:

    • Raspi 3B+ wird über das Display (aus Sicherheitsgründen von Überspannung) mit Strom per offiziellem NT versorgt.

    • 1 HDMI Monitor/Beamer ist parallel angeschlossen, soll aber nicht parallel zum TFT laufen

    Meine Absicht:

    • Entweder/oder

    • Als schnellen Mediaplayer für unterwegs (Youtube, Musik) brauche ich kein großes Display und keine erweiterten Steuermöglichkeiten. Touch reicht mir vollkommen aus, evtl. noch mit einer Fernbedienung (zwecks sinnvoller Tastatureingabe) gekoppelt

    • als Präsentations-PC für Beamer oder große Displays mit Office, Impress, HD Filmen, Musikwiedergabe usw. ist das Touchdisplay unnütz und stört lediglich den Zuschauer, daher muss es komplett stromlos geschaltet werden

    Was ich habe:

    • offizielles 7" Touchpanel, v1.1

    • Raspbian Stretch

    • non-GL Standardtreiber (im OpenGL Full KMS) stürzt mein Kodi ständig ab bzw. startet erst gar nicht

    • ein kleines Skript vergleicht nach dem Bootvorgang, ob ein HDMI-Display oder nur das LCD via DSI-Kabel angeschlossen ist und startet ggf. den Rechner automatisch neu, um auf das entsprechende Display umzuschalten

    -->ist zwar umständlich, funktioniert aber problemlos und die Bootzeit von weniger als 1 Minute ist mir dabei egal

    Allein das war bereits eine Odyssee, weil man wirklich mit exakten Werten in der config.txt hantieren muss, um das HDMI-Display allein zu betreiben. Andernfalls schaltet sich das Touchpanel immer dazu und dann hinkt natürlich auch die CPU-und Grafikleistung.

    • ein kleines Python-Skript fand ich, das mir mein Display in einen selbst definierten Dimmwert bei Tag-und Nachtmodus setzt, es funkioniert auch so weit, aber nur für das Touch-LCD. Bei HDMI-Anschluss hat es keinen Effekt, weil es ebenfalls nur die Werte in .../rpi_backlight/backlight umschreibt (Ordnerpfad verschwunden, siehe unten)

    • nachdem der Raspi gebootet ist und mein HDMI-Display komplett getrennt ist, nutze ich nur den Touchscreen

    • nachdem der Raspi gebootet ist und mein HDMI-Display angeschlossen ist, nutze ich nur HDMI und es sollte sich der Touchscreen abschalten

    Und genau letzterer Punkt funktioniert bei mir nicht.

    Problem:

    • /sys/class/backlight/rpi_backlight existiert nur, wenn das Touchpanel allein in Betrieb ist

    • Ist HDMI angeschlossen, verschwindet der Ordner einfach

    • alle Versuche der Zugänglichmachung über

    Code
    sudo nano /sys/class/backlight/rpi_backlight/bl_power

    resp.

    Code
    .../brightness

    bzw.

    Code
    sudo echo >> '0 oder 1' /sys/class/backlight/rpi_backlight/bl_power

    resp.

    Code
    sudo echo >> 10 /sys/class/backlight/rpi_backlight/brightness

    (denn unter dem Wert 11 schaltet sich das Display ebenfalls komplett ab) scheiterten, weil der Pfad nicht existiert

    Code
    dtoverlay=rpi-backlight

    in meiner config.txt hat keinen Effekt, wenn HDMI angeschlossen ist, der Ordner ".../rpi_backlight/backlight" existiert danach trotzdem nicht

    Code
    sudo tvservice

    schaltet mir nur mein gerade "aktives" Display ab, egal ob es HDMI oder LCD-Touch ist

    • mein Touch-LCD schliert, verschwimmt, leuchtet, blinkt, blitzt usw. wenn mein HDMI-Monitor nebenher angeschlossen ist (ich denke einfach der Grafikeinstellungen für mein HDMI-Display wegen)

    Weiterhin funktioniert aber die Touchfunktion

    • ich dachte, ich könnte evtl. über

    Code
    sudo rpi-backlight -b 10

    , wenn ich den Befehl mit in mein Erkennungsskript für HDMI schreibe, die Hintergrundhelligkeit fürs Touchdisplay so ändern, dass sie unter den Wert 11 und damit komplett aus geht, da aber BacklightControl scheinbar die Werte auch nur in "/sys/class/rpi_backlight/backlight" ändert und der Pfad mit HDMI nicht existiert, hat das auch keinen Effekt

    Deswegen:

    Gibt es für den Raspberry Pi Modell 3B+ eine geeignete Lösung, um das Touchpanel komplett auszuschalten?

    Hintergrund ist einfach der, dass LCDs mit der Zeit dunkel und farbuntreu werden und Flecken bekommen. Es muss doch nicht sein, wenn ein externer Monitor angeschlossen ist, dass das Touch-Display ständig Strom braucht und ständig eingeschaltet ist und sich damit auf Dauer selbst zerstört. Außerdem stört dieses Leuchten aus der Ecke ungemein. Ich verstehe nicht, weshalb anscheinend noch keine einfache Funktion ins Raspbian implementiert ist, um einfach mal das Touchpanel nebst HDMI ausschalten zu können.

    MfG Tantal

    Einmal editiert, zuletzt von Tantal (17. November 2018 um 17:41)

  • Offizielles 7" TFT Touchdisplay parallel zu HDMI komplett abschalten? Schau mal ob du hier fündig wirst!

  • Ich habe nun einen Versuch auf andere Art und Weise gestartet, der aber leider in die Hose ging.

    Ich habe immer noch keine Möglichkeit gefunden, das Display zuverlässig abzuschalten.

    Meine Überlegung ging dahin einfach den Masseanschluss vom Display durch eine kleine zusammengelötete SMD-Schaltung, die ich gefunden habe, abzuklemmen und diesen dann nur bei Bedarf zuzuschalten.

    Hintergrund:

    Ich habe immer wieder Spannungswarnungen eingeblendet bekommen, wenn der Pi über das Display lief. Scheinbar leckt es irgendwo an der Displayplatine oder an den Litzen für die Spannungszufuhr. Immerhin ist die Spannung bei meinem Netzteil mit 5,25V schon höher als das Soll bemessen, weil der Raspi 3B+ zu viele Billigkomponenten verbaut hat, die einen Flaschenhals bilden. Kommt zusätzlich noch einer vom Display daher, könnte es eng werden und Datenverlust geben. Also habe ich jetzt einfach das Display über den Pi laufen lassen und plötzlich sind sie weg. Auch wenn er ja angeblich die 400mA Ausgangsstrom nicht verkraften soll (evtl. zusammen mit allen USB-Anschlüssen und HDMI???). Ich weiß es nicht, jedoch ist er bis zu 400mA Ausgabestromstärke in der Version 3B+ abgesichert, so wie ich las. Da das TFT-Display mit der Sockelleiste mit Masse verbunden werden muss, dachte ich, Spannung kann es es kriegen, schalte ich bei Bedarf eben einfach die Masse weg.

    Dazu habe ich ein kleines Bash-Skript erstellt, das die Statusausgaben von tvservice -s abfragen soll und ggf. einfach einen entsprechenden GPIO auf 0 oder 1 setzt.

    Jedoch habe ich noch nicht alle Statusmeldungen testen können, d.h. Monitor aus, Monitor standby, Monitor ein, Monitor abgeschlossen usw., weil mir ein gravierender Fehler aufgefallen ist. Das Touch-Display hat ja ebenfalls über den DSI-Anschluss Masse. Daher hat es keinen Effekt, einfach nur einen Massepin an der Sockelleiste auszuschalten. Dementsprechend müsste man mit einer Schaltung eher die 5V-Spannungszufuhr unterbrechen, die vom Raspi kommt. Das werde ich demnächst versuchen.

    Hat hier jemand Einwände oder weiß, ob evtl. ein Problem mit dem DSI-Kabel auftreten kann, wenn die 5V vom Hauptanschluss fehlen?

    Denn ich will den Pi an möglichst allen/unterschiedlichen Medien betreiben, d.h. meine Monitore, mein Beamer, anderer Leute Monitore usw. und da sollte es eine allgemeingültige Lösung geben, um den HDMI-Status abfragen zu können. Momentan wird der Name meines Monitors abgefragt und in meinem Fall existiert auch einer. Wird er allerdings mal nicht ausgegeben (könnte evtl. mal passieren?), funktioniert mein Erkennungsskript nicht mehr. Der Status von tvservice -s sollte aber immer derselbe sein!?

    Für Python, was ich nicht beherrsche, habe ich Lösungen gesehen, die Spannungen von eingelöteten Widerständen oder Transistoren abfragen. Doch direkt auf der Platine herumzulöten geht mir dann doch zu weit. Immerhin hängt nicht nur der Pi, sondern auch ein 80€ Display dran. Und einfache allgemeingültige Lösungen zur HDMI Statusabfrage scheint es für Python nicht ohne Weiteres zu geben. Jedenfalls habe ich nichts entsprechend Aussagekräftiges gefunden, das ein Anfänger verstehen würde.

    Vielleicht gibt es ja den ein oder anderen, der ebenfalls so eine kleine Lötsteuerung als Denkanstoß nutzen kann. Für meinen CPU-Lüfter am Pi, als VLC Player noch nicht mit Grafik-Hardwaredekodierung bei mir lief, funktionierte sie astrein. Dazu einfach mal im Circuit Board nachschauen.

    https://circuit-board.de/forum/index.ph…Raspberry-Pi-3/

    Natürlich könnte man einfach mit 2 Netzteilen hantieren oder einem Y-Kabel. Nur sollte man bedenken, dass auch USB-Steckzyklen - und gerade Micro USB - begrenzt sind. Und mir ist es um das Geld zu schade, wenn ich den Pi und insbesondere das Display nach 2 Jahren Herumschleiferei durch Voträge, Messen und Versammlungen wegen defekter USB-Steckanschlüsse entsorgen muss.

    MfG Tantal

  • Kleines Update.

    Als Noob habe ich jetzt die Zuschaltung vom Display folgendermaßen gelöst:

    Ich habe mir eine Mini-Relais-Platine, die auf Masse durchschaltet (eine stabile und vor allem sparsame +5V-Lösung habe ich nicht gefunden) besorgt und über diese ein Reed-Relais angesteuert, das auf +5V durchschaltet. Damit hängt nun mein Display dauerhaft direkt an GND. Die Spannungsversorgung wird nahezu verlustfrei (ein Reed-Relais sollte so gut wie keinerlei Spannung und Strom verschlingen, zumindest viel weniger als ein MOSFET) zugeschaltet.

    Ich habe mich für diese Pulldown-Relaisplatine entschieden, über die ich dann direkt den Reed-Schalter per +3,3V-Pin ohne Widerstand und GPIO durchschalte. Funktioniert auch sauber.

    Dazu verwende ich ein SIL05-1A72-71D mit einem Transportstrom von 1A, einer Transportspannung von 5V und einer Schaltspannung von max. 3,5V. Das sollte für das Display mit 5V und 0,4A eigentlich völlig ausreichend sein und hat dabei auch keinen fetten Verlust. Beim Eingang messe ich ebenfalls nur noch 4,965V bei eingehenden 5,25V vom Raspi-Netzteil. Also sind hier schon fast 0,3V irgendwo im Raspi verloren gegangen. Das ist doof!

    Frage dazu: kann der GPIO bei einer direkten Pullup-Schaltung mit 10K Widerstand gegen +3,3V und 100Ohm gegen meine Magnetspule dann vom Schaltstrom der Spule mit 0,5A so belastet werden, dass er mir durchbrennt oder ist meine Denkweise falsch?

    Damit tat sich nun eine andere Herausforderung auf. Ich kann problemlos meine GPIOs schalten, aber erst, wenn der Raspi gebootet ist. Damit ist dann die Initialisierung des Touchpanels bereits durch und es wird nicht mehr zugeschaltet.

    Also habe ich mit meinen Anfängerkenntnissen den entsprechenden GPIO per Python auf Output und HIGH geschaltet und den Cleanup-Befehl weggelassen. Damit sollte der GPIO eigentlich nach einem Neustart als Output geschaltet bleiben, somit meine Relaisplatine durchschalten, somit mein Reedelais von Anfang an Saft geben, somit mein Display von Anfang an initialisiert werden.

    Hat auch geklappt, aber nur 3 Sekunden. Danach war mein Display wieder dunkel. Anscheinend ruft der Pi 3 B+ standardmäßig irgend eine Routine beim Bootvorgang auf, die generell die GPIOs auf intput schaltet. Hat jemand Erfahrungen dazu?

    Danach versuchte ich, den Schaltvorgang vor die Initialisierung des Displays im Bootvorgang über die rc.local-Datei zuzuschalten. Dazu habe ich über

    echo "XY" > /sys/class/gpio/export

    echo "out" > /sys/class/gpio/gpioXY/direction

    echo "1" > /sys/class/gpio/gpioXY/value die Befehle direkt in die rc.local geschrieben bzw. ein script mit diesen Befehlen aufgerufen. Wenn ich allerdings die LED auf meiner Relaisplatine beobachte, dann sehe ich, dass der Schaltvorgang erst nach dem eigentlichen Bootvorgang erfolgt. Alles wird ordnungsgemäß und sauber auf output 1 zugeschaltet, es nützt mir aber herzlich wenig. Ich weiß aber leider nicht, wann genau das Display initialisiert wird, d.h. an welchem Punkt es bereits Spannung bräuchte, um überhaupt zu funktionieren. Und ich weiß auch nicht, wieso der Schaltvorgang erst nach dem Bootvorgang erfolgt, selbst wenn ich ihn direkt in die /etc/rc.local schreibe.

    Ich könnte mir hier 2 Dinge vorstellen.

    1. sowas wie ein Prefetch bekommt den Befehl, hält ihn aber vor, bis das Betriebssystem komplett geladen ist. Danach wird der Befehl aus dem Kurzzeitspeicher heraus noch ausgeführt, weil quasi die Dateistrukturen erst mit dem Start des BS überhaupt existieren.

    2. Die Initialisierung des Displays erfolgt bereits bevor überhaupt CPU, NAND und die Peripherie initialisiert wird, was dann einen entsprechenden Schaltbefehl in der rc.local völlig nutzlos machen würde.

    1. Habt ihr dementsprechend irgendwelche Erfahrungen, wie ich die GPIOs vor dem Booten standardmäßig als "output" "1" schalten kann?

    Gibt es vor der rc.local vielleicht noch eine Datei, die ich zur GPIO-Zuschaltung entsprechend auffordern kann?

    Ich kann mich hier an irgend eine Bootdatei erinnern, in der der Kernel geladen wird. Allerdings hatte ich mir mit der Veränderung dieser Datei zuletzt mein Raspbian zerschossen, weshalb ich es erst wieder reparieren und die Datei original wiederherstellen musste.

    2. Ist es überhaupt grundsätzlich möglich, die GPIOs tatsächlich vor dem Booten dauerhaft zu schalten?

    Ich habe schon so etwas in anderen Foren gelesen. Allerdings glaube ich, dass diese Leute ihre Thesen selbst noch nicht überprüft haben und somit nur Blödsinn schreiben.

    3. Ist es möglich, das Touchpanel im Betriebssystem selbst initialisieren zu lassen, sodass es mir nach einer Stromlosphase wieder ein Bild anzeigt?

    Unterschied wäre nämlich der: Bei sudo rpi-backlight -b 10 wird ja scheinbar nur die LED-HG-Beleuchtung abgeschaltet (alles unter dem Wert 11 ist praktisch aus), das LC-Display selbst bleibt aber initialisiert und liefert quasi dauerhaft ein Bild.

    In meinem Fall dagegen wird das Gesamte LC-Display von der Spannung genommen und müsste vom Betriebssystem erst wieder als entsprechendes Display, mit entsprechender Auflösung, mit entsprechendem Overscan, mit entsprechender Hz-Zahl, mit entsprechender Touch-Funktion usw. usf. "erkannt" werden. Vielleicht gibt es ja sogar für das offizielle Touchpanel irgend eine vorgefertigte Datei zur Initialisierung?

    4. wenn 2. nicht zutrifft, gibt es evtl. einen GPIO, der standardmäßig verpolt ist und grundhaft auf output high steht?

    Ich wäre sehr dankbar, wenn mir hier jmd. helfen oder Auskunft geben könnte. Ich stehe damit kurz vor Abschluss meiner selbst gesetzten Aufgabe und evtl. hilft diese Lösung noch anderen Nutzern weiter, die ebenfalls entweder HDMI oder Touch mit dem Standardgrafiktreiber nutzen wollen.

    Andernfalls werde ich es wirklich so machen, dass ich hardwareseitig Touch-LCD und Raspi getrennt voneinander betreibe und dann einfach beim LCD den Stecker ziehe oder mir einen kleinen Öffner in die Zuleitung einbaue. Das wäre allerdings die plumpeste und hässlichste Methode, bei der niemand etwas gelernt hätte.

  • Wow, das sind aber ausführliche Beiträge... Eventuell wäre es besser das Problem in kleinen Stücken zu lösen...

    Ich hoffe ich kann helfen:

    GND wegschalten - besonders wenn 5V Versorgung im Spiel sind ist keine gute Idee. Die Spannung sucht sich idr. einen anderen Weg - zB über die GPIO.

    Spannungsverlust: Mit dem Multimeter messen, wo die verloren geht wäre möglich. Ich vermute mal hauptsächlich an der Polyfuse.

    GPIO: Normalerweise sollten die beim Start hochohmig sein - ev. Noch mit einem internen Pullup oder Pulldown konfiguriert sein. Du kannst also mit einem Widerstand (min 1KOhm) das Potential auf den gewünschten Pegel ziehen (zB 3,3 V). Achte aber darauf, dass der GPIO beim schalten nicht überlastet wird...

    ...wenn Software nicht so hard-ware ;) ...

    Freue mich über jeden like :thumbup:

  • ….

    GPIO: Normalerweise sollten die beim Start hochohmig sein - ev. Noch mit einem internen Pullup oder Pulldown konfiguriert sein. Du kannst also mit einem Widerstand (min 1KOhm) das Potential auf den gewünschten Pegel ziehen (zB 3,3 V). Achte aber darauf, dass der GPIO beim schalten nicht überlastet wird...

    Das soll im aktuellen Image (Raspbian) in der config.txt voreinstellbar sein.

    ;) Gruß Outi :D
    Pis: 2x Pi B (Rente) / 1x Pi B+ (Rente) / 1x Pi 2 B (Rente) / 2x Pi 3 B (RaspberryMatic / Repetier Server) / 2x Pi Zero 1.2 (B. Lite) / 2x Pi Zero 1.3 (B. Lite) / 2x Pi Zero W 1.1 (B. Lite) / 1x Pi Zero 2 (mal so, mal so) / 1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (BW Lite (Webserver)) / Pi 400 (BW) / 1x Pi 5 (BW) / 2x Pi Pico / 2x Pi Pico W
    Platinen: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT
    Kameras: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • GND wegschalten - besonders wenn 5V Versorgung im Spiel sind ist keine gute Idee. ...

    Richtig. Habe mich auch umentschieden. Mein Display hängt nun standardmäßig immer an GND.

    Der Eingang vom (Relais)Schließer hängt direkt an der 5V-Spannungsversorgung und schleift beim Schließen einfach nur zum Display durch. Damit treten Verluste auf, die vernachlässigbar sind.

    Zuerst wollte ich per PNP-Transistor, wenn ich es irgendwie hinbekommen hätte, direkt auf 5V durchschalten. Jedoch rieten mir mehrere Leute unabhängig voneinander davon ab, weil ein PNP-MOSFET einiges an Strom verschlingen kann, was ich mir beim Raspi nicht leisten kann. Daher bin ich auf ein quasi verlustfreies Mini-Reedrelais umgestiegen.

    Die Schaltspannung für den Reed-Schalter kommt direkt vom 3,3V Pin. Ich habe auch noch keine Überlast, sprich Abstürze oder Aufhänger am Raspi mit 500mA feststellen können, wobei ich bisher nicht genau sagen kann, ob mein Reedschalter tatsächlich auch 0,5A verschlingt. Das ist wahrscheinlich auch stark temperaturabhängig, inwiefern die Magnetspule dann Saft benötigt.

    Komisch ist bei der Spannungsversorgung des Displays, dass bereits der 5V Pin nur noch 4,96V liefert. Naja, aber daran kann ich wahrscheinlich nichts mehr rütteln. Habe die Spannung am Netzteil damals gemessen und die war höher. Sollten Probleme auftreten, muss ich trotzdem das Display direkt ans Stromkabel hängen.

    Das soll im aktuellen Image (Raspbian) in der config.txt voreinstellbar sein.

    Diesbezüglich muss ich nochmal richtig, richtig tief nachlesen und nachbohren, wenn das wirklich so sein sollte. Habe bisher absolut keine Information dazu. Es wäre aber eine ganz fette Sache, wenn es tatsächlich ginge. :)

    Das Problem mit dem Abschalten, besser dem Anschalten, während der PI schon läuft, ist, dass das Display dann nicht richtig initialisiert wird.

    Dazu habe ich vor wenigen Tagen glücklicherweise in irgend einem RasPi-Forum einen Entwicklerbeitrag gelesen.

    Fazit: Es geht nicht :(

    Das Display selbst wird scheinbar ohne Zutun weiterer Komponenten direkt von der GPU angesteuert und pulsweitenmoduliert, wie ich dem Beitrag entnehmen konnte. Wird die Verbindung dann nur einmal unterbrochen, kann es im Betrieb nie wieder von der GPU geschaltet werden. Den genauen Grund weiß ich nicht mehr. Aber es soll bereits gehörige Probleme im Vorfeld gegeben haben, um überhaupt die HG-Beleuchtung entsprechend dem bl_power-Befehl ab- und zuzuschalten. War ja vor 2(?) Jahren noch gar nicht möglich.

    Daher fällt Punkt 3 komplett weg. Auch nicht so schlimm.

    Hallo,

    zu 1. Versuche mal Pin 8 (GPIO14). ;)

    Hatte ich bereits gestern probiert. Leider erfolglos. Ich denke sogar, der GPIO schwankte sehr stark. Wenn ich mich recht erinnere (habe gestern mehrfach schnell zwischen Tür und Angel nachgemessen) lag er beim Initialisieren vor dem Booten bei 3,3V, ging dann runter auf 1,3V, dann wieder für einige Sekunden rauf auf 3,3V, dann wieder runter auf 2,3V im Betriebssystem - wohlgemerkt mit angeschlossener Platine. Eigenartig.

    Ich habe jetzt mehrere Bootvorgänge mit unterschiedlicher Verkabelung (um Störeinstreuungen durch meine Lüftersteuerung oder naheliegende Kabel zu verhindern) mit dem GPIO 02 durchgeführt. Er liefert bei mir immer standardmäßig 3,3V von Anfang an. D.h. das Bild ist da. Ich bräuchte nun nur noch eine Möglichkeit diesen Pin im Linux abzuschalten. Weil er scheinbar für I2C verwendet wird, geht das anscheinend nicht wirklich!? Zumindest wird mir immer der Zugriff selbst als root verweigert. Im BS steht er allerdings auf "input" "high", was mich sehr, sehr wundert. Dürfte er dann überhaupt meine Platine durchschalten? Sie hat einen eingebauten 10K Pulldown-Widerstand. Ich dachte zuerst an Schwankungen, sodass das Linux ihn nicht genau zuordnen kann, schließe sie aber in Anbetracht des Widerstandes nun aus.

  • Ich habe jetzt noch mal mehrfach Messungen durchgeführt. Ich habe die serielle Schnittstelle extra deaktiviert. War sicher ein guter Tipp, brachte aber leider keinen Erfolg.

    Beide Male, nach Aktivierung und Deaktivierung schwankt die Spannung extrem zwischen 380mV und 3,3V. Für die ersten 3 Sekunden bekomme ich in jedem Fall ein Bild, d.h. von Anfang an ist Spannung da. Danach fällt die Spannung wieder ab und schwankt bis zum Erscheinen des BS erheblich. Fast so, als würden dauerhaft beim Booten Daten gesendet. Seltsam, dass das in beiden Fällen auftritt, auch wenn Serial und das Anmeldeinterface deaktiviert ist.

    @Outlaw

    Der Eintrag in der config.txt bezweckt zwar die Schaltung der Pins ordnungsgemäß, aber eben leider auch erst nach bzw. im Bootvorgang, wenn der Kernel schon geladen ist. An dieser Stelle ist dann das Display schon durch und wird nicht mehr erkannt. War ein Versuch, aber leider erfolglos. Wie gesagt, denke ich, dass solcherlei Befehle aus best. Dateien heraus hier nicht richtig zielführend sein werden, weil wahrscheinlich die Pins standardmäßig vom Kernel alle auf Input geschaltet werden.

    So genau kenne ich mich mit dem eigentlichen Bootvorgang nicht aus, meine aber, dass die Pins bereits beim Herunterfahren oder evtl. physikalisch schaltungstechnisch invertiert sein müssten, dass sie beim Hochfahren von Anfang an Strom geben. Ist eben wie ein Sicherheitsaspekt des RasPi, dass man sich nicht schnell mal irgend was Angeschlossenes beim Hochfahren zerschießt.

    Das würde m.M.n. auch erklären, dass z.B. GPIO 03 auf "in" geschaltet ist, aber trotzdem Strom fließt. Vielleicht ist in diesem Fall einfach der Schaltkreis auf dem Board anders gepolt? Dazu habe ich aber nichts gefunden.

    Eine ganze dumme Idee ist mir eben noch in den Sinn gekommen. Knallhart könnte man ja das Display die ersten 10 Sekunden per NiMH-Akkupaket betreiben. Dazu bräuchte man allerdings ein zweite Relaissteuerung, wofür dann wahrscheinlich zu wenige 3,3V Pins vorhanden sein werden. Ist dann der entsprechende GPIO initialisiert, schaltet das erste Relais einfach auf Netzspannung um und trennt das Display dann vom Akku. Wahrscheinlich gäbe es da aber entspr. Schaltzeiten oder Spannungsschwankungen zu beachten, die ich absolut nicht abschätzen kann.

  • Noch mal von meiner Seite was. Ich habe nun erfolglos alles mehrere Male durchgespielt.

    Dabei habe ich herausgefunden, dass der Serial-Menüpunkt im raspi-config  nichts weiter tut als den Eintrag enable_uart=0 bzw. enable_uart=1, je nachdem eben, in der /boot/config.txt zu setzen. Genau so verhält sich dann auch meine kleine Status-LED. Erst an, dann aus, im BS wieder an oder eben aus, je nach Einstellung. Weil zwischenzeitlich beim Booten irgend eine Datenabfolge gesendet wird.

    Der Raspi soll in der v3 seinen echten UART fürs Blutwurst geschaltet haben, wohingegen der UART für GPIO14 nur emuliert wird (wenn man Aussagen anderer Leute Glauben schenken darf). Er steht zwar von Anfang an auf Spannung, lässt sich dann aber auch nicht weiter beim Booten kontrollieren, weil ja die config.txt erst später geladen wird.

    Ich glaube, ich bin jetzt so ziemlich am Ende mit meinen Möglichkeiten. Wie bereits geschrieben, hat der GPIO03 ständig Saft bei mir. Ich brauche I²C nicht.

    Evtl. könnte mir ja jemand erklären, ob der Anschluss GPIO 03 auf irgend eine Art einfach nur abschaltbar ist. Das wäre super und mehr bräuchte ich gar nicht.

    Den Kernel und die Schutzfunktion, die die GPIOs auf Input low setzt, kann ich selbstverständlich nicht umprogrammieren. Vielleicht kommt ja irgendwann mal ein aufgebohrtes Raspbian, was einen output high für frei programmierbare GPIOs von Anfang an erlaubt.

    Bis hierhin erst mal ein dickes Danke für eure, leider erfolglosen, Bemühungen! Werde ich wohl doch den Weg über einen einfachen Kippschalter in der Zuleitung gehen, wenn es sonst keine Möglichkeit mehr gibt.

    Ich habe jetzt mehrfach den Beamer nebst Touch-LCD angeschlossenen gehabt und es nervt wirklich, wenn der Raum abgedunkelt ist und man etwas zeigen oder erklären möchte und ständig aus der Ecke des Raspi ein grelles Leuchten kommt, als ob jmd. auf seinem Smartie spielt.

    Einmal editiert, zuletzt von Tantal (11. Dezember 2018 um 22:12) aus folgendem Grund: Anschlusspin falsch benannt

  • Zuallererst habe ich nun nach einem Weg gesucht, die GPIOs standardmäßig umzustellen und habe eine heiße Spur gefunden. Das Zauberwort heißt device tree.

    Das Device Tree Overlay in der /boot/config.txt funktioniert ja in meinem Fall nicht, weil lt. der offiziellen Raspi Dokumentation die config.txt erst viel zu spät geladen wird. Ich habe eine Lösung benötigt, die eher greift, irgendwo, bevor die GPU angesprochen wird. Und das könnte evtl. direkt über die dt-blob.bin funktionieren. Da muss man evtl. nicht mal über den Kernel gehen, sondern kann über den Device Tree regeln, welchen Status und Wert der jeweilige GPIO haben soll. Blöderweise habe ich NOOBS und dort vergeblich versucht, mir irgendwo her die Datei dt-blob.dts zu extrahieren. Angeblich wäre sie lt. der RPI Dokumentation bei NOOBS ausschließlich in der Recovery-Partition, doch ich habe sie nirgends finden können :(

    Also nach langer Suche für mich irrelevant und frustrierend.

    Ich bin nun trotzdem einen Schritt weiter. So ganz verstehe ich die Logik nicht, aber vielleicht wisst ihr da noch mehr.

    Ich habe nun noch mal rumexperimentiert und nutze den GPIO03 für die Schaltspannung meines Relais. Dieser steht ja standardmäßig vom Kernel auf Input High. Ich konnte ihn über die Konsole nicht auf 0 stellen und bekam eine Fehlermeldung, dass die Operation nicht erlaubt sei, obwohl als SU ausgeführt .

    Jetzt habe ich ihn mal probehalber auf Output, also das Gegenteil, gestellt, weil er ja bei Input bereits Spannung liefert und tatsächlich habe ich nun Zugriff auf seinen Status mit diesem Befehl. Ich darf ihn als SuperUser über echo "0" > /sys/class/gpio/gpio3/value nicht schalten (hat das mit dem hard wiring auf input 1 zu tun???), jedoch über echo "out" > /sys/class/gpio/gpio3/direction Und das Seltsame ist, dass meine Relaisspannung mit der Umstellung nun sofort weg ist, also genau so, wie ich es haben wollte. Damit muss ich mir nun nur noch mein script anpassen, damit das LCD beim Hochfahren vollständig abgeschaltet wird. Erste Tests sahen verdammt vielversprechend aus, jetzt muss ich als Noob nur noch irgend eine universelle Abfrage für HDMI-Displays in mein skript schreiben. Evtl. über best. Statusmeldungen von tvservice.

    Etwas komisch finde ich allerdings, dass das LCD beim Reboot aus bleibt. Um es einzuschalten, muss ich erst den Raspi komplett vom Strom trennen. Scheint so, als würde der GPIO03 seinen eingestellten Status dann trotzdem beibehalten und erst nach einer Stromlosphase auf seinen Standard resetten. Wie auch immer. Das finetuning kann nun erfolgen. Ich werde die Schaltung mal zwecks Stromaufnahme im Auge behalten. Sollte das Relais den GPIO auf Dauer tatsächlich überlasten, dann muss ich trotzdem auf einen Schalter umschwenken.

  • GND wegschalten - besonders wenn 5V Versorgung im Spiel sind ist keine gute Idee. Die Spannung sucht sich idr. einen anderen Weg - zB über die GPIO.

    das kommt mir bekannt vor, ich zitiere mich mal selbst von heute:

    Code
    deine IC sind doch mit ihren Eingängen sicher an einem µC
    Wie reagiert nun dieser Eingang wenn es keinen GND Bezug mehr hat weil du das GND per low side auschaltest?
    
    Deswegen damit der GND Bezug nicht weggeht für high und low schaltet man VCC aus, also hi side.
    
    Wenn du in der Seilbahngondel stehst und dich an der Haltestange festhälts hast du kein Problem 
    wenn das Dach plötzlich abhebt, 
    aber wehe der Boden ist plötzlich weg, dann brauchst du sehr starke Arme.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • jar

    Dann hast du meinen Nachtrag weiter unten überlesen. Mein LCD hängt nun dauerhaft an GND der GPIO-Leiste, weil es sich wegen DSI technisch anders gar nicht bewerkstelligen ließ - außer ich hätte das DSI-Kabel aufgeschnitten und umgelötet.

    Deinen Vergleich mit der Seilbahn zweifle ich hier an. Denn wenn ich was gelernt habe, dann dass Mikroelektronik nahezu nichts mit Elektrik zu tun hat ;)

    Wenn die Lehrpläne unserer inkompetenten, überbezahlten und selbstherrlichen Politiker vor 20 Jahren Raum für solcherlei Experimente im Physikunterricht gelassen hätten, statt Kindern unnütze Zahlen einzuhämmern, hätte ich mich vielleicht hier an dieser Stelle wieder mit Freude dran erinnert. So kann ich nur abschätzig drüber lächeln. Krass ist, wie schnell man die Grundlagen wieder ausblendet, weil sie bis dato nie Relevanz besaßen.

    Meine Displayschaltung funktioniert jetzt fast genau so, wie ich sie haben wollte. Mein Skript, das über tvservice den Status von HDMI abfragt, habe ich nun noch um die Schaltung des GPIO03 erweitert. Wobei es eigentlich zwei Skripte sind, weil eins für den Reboot zuständig ist, das andere wiederum einfach die Spannung vom LCD wegnimmt.

    Muss mal sehen, ob ich noch die Umschaltung des Pins auf seinen Standardwert gebacken bekomme, sodass das LCD nach einem evtl. Reboot wieder funktioniert. Allerdings wird die Häufigkeit dieses Falls gen 0 tendieren.

    In dem Sinne euch allen eine besinnliche Weihnachtszeit und gutes Einläuten des neuen Jahres.

  • Richtig. Habe mich auch umentschieden. Mein Display hängt nun standardmäßig immer an GND.

    gute Idee!


    Deinen Vergleich mit der Seilbahn zweifle ich hier an.

    darfst du, trotzdem finde ich den Vergleich gut zum immer wiederkehrenden Wunsch low side wegzuschalten einfach weil es einfach ist und üblicherweise Transistor als Schalter so verstanden wird ungeachtet der Umstände, ob Relais, LED oder andere Schaltungen.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Nach einigen Wochen habe ich mir nun noch eine USB-Soundkarte zugelegt.

    Jetzt ist wirklich Feierabend, Leute!

    Meine Schaltung funktioniert nach wie vor, aber ich rate nun jedem, der mal dasselbe oder Ähnliches wie ich vor hat, tu es mit einem mechanischen Taster.

    Die Soundkarte zieht nun noch ein bisschen mehr Saft und ich stelle nun sporadische Abstürze bzw. freezes meines Raspbian fest. Mal nach ner halben Stunde, mal nach 10 Minuten, mal nach 3 Stunden. Da die Stromkurve meines Reed-Relais gegenüber der Temperatur wahrscheinlich eher exponentiell verläuft - obwohl ich keine tatsächliche Stromaufnahme messen konnte -, das Display seinen Tribut fordert, manchmal auch der 5V-Lüfter saugt und das WLAN permanent eingeschaltet ist, nehme ich stark an, dass die Stromzufuhr über den Raspberry an sich hinkt.

    Ausdrücklich sei nicht das Netzteil erwähnt, weil ich alles über die Raspberry-Platine laufen lasse.

    Ich habe nun ein Micro-USB-Y-Kabel rangetütelt und bisher keinen Absturz mehr festgestellt, werde das aber weiterhin beobachten.

    Das alles gibt mir zwar eine ganz schöne Ohrfeige, weil alle Bastelei trotz Minimalistik und Funktionalität umsonst war, aber zumindest weiß ich jetzt, wo der Raspberry an seine Grenzen stößt und ich kann mich evtl. zukünftig mal auf ein anderes Projekt konzentrieren, weil ich nun wieder einige Versorgungspins frei bekomme.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!