Hallo, ich habe ein Problem bezüglich meines Raspberry Pi's. Ich habe gestern eine kleine elektronische Schaltung aufgebaut, welche aus einem Potentiometer und einer LED-Leiste besteht. Dazu ein Programm, welches die aktuelle Potentiometer-Einstellung im Terminal ausgibt und zusätzlich die LED-Leiste je nach Poti-Stellung ansteuert. Also bei Stellung ganz links leuchtet keine LED und bei ganz rechts leuchten alle 10 LEDs der Leiste. Soweit so gut. Führe ich das Programm über den Raspberry Pi selbst per Maus und Tastatur aus funktioniert alles problemlos. Versuche ich allerdings das Programm per Putty über SSH auszuführen, so wird mir lediglich das Putty Terminal am Rechner angezeigt, auf dem Putty installiert ist. Dabei funktioniert auch die Erkennung der Potentiometer Eingabe, jedoch leuchten meine LED's am Pi nicht.... Woran könnte das liegen und wie lässt sich dieses Phänomen beheben? Vielen Dank im Vorraus! Markus
Läuft das Programm in einer Endlosschleife oder wird nach Erfassen der Potentiometerstellung und Ausgabe an den LEDs das Programm beendet?
Ich nehme statt Putty gleich ssh. Warum der Umweg über Putty?
PittyJ schrieb: > Ich nehme statt Putty gleich ssh. Warum der Umweg über Putty? Putty ist das Terminalprogramm mit dem SSH ausgefühert wird.
Markus schrieb: > Woran > könnte das liegen und wie lässt sich dieses Phänomen beheben? Wer bist du wenn du dich direkt am Pi anmeldest? (user) Wer bist du wenn du dich über SSH am Pi anmeldest? (user) Beides Mal der gleiche user mit den gleichen Rechten?
Ja immer der selbe. Benutzer: pi. Rechte müssten dann auch gleich sein, oder?
Markus schrieb: > Versuche ich allerdings das Programm per Putty über SSH auszuführen, so > wird mir lediglich das Putty Terminal am Rechner angezeigt, auf dem > Putty installiert ist. Zeige mal einen Screenshot, auch von den relevanten Einstellungen. Mit ist nämlich gar nicht klar, was du mit "das Programm per Putty über SSH auszuführen" meinst.
Läuft dein Programm in der SSH Konsole im Hintergrund? Wenn nein, versuche es es im Hintergrund zu starten (Programm mit & am Ende starten). https://forum-raspberrypi.de/forum/thread/1227-anwendung-ueber-ssh-in-den-hintergrund/
Du weißt, dass es für die beiden IC von dir einen Kerneltreiber gibt, oder? https://github.com/torvalds/linux/blob/929d931f2b40d7c24587818cf6c1f7a6473c363f/Documentation/devicetree/bindings/hwmon/ti%2Cads7828.yaml https://www.kernel.org/doc/html/v5.12/hwmon/pcf8591.html Mit z.B. einem Overlay kannst du den Device Tree um die entsprechenden Einträge ergänzen und kannst die IC dann direkt nutzen - du bekommst direkt die Spannung in Volt sofern du die passende Referenz konfigurierst. https://github.com/raspberrypi/firmware/tree/master/boot/overlays Eine Umrechnung wie du sie implementiert hast ist dadurch vollkommen unnötig. Genauso die Pins deines Port Expanders, diese wären direkt nutzbar. Generell finde ich diese Bibliothek auf einem Raspberry Pi etwas gruselig, auf einem Arudino okay, aber so arbeitet man eigentlich nicht wirklich auf einem Linux System, dort will man ja eigentlich gar nicht mit I2C Devices direkt sprechen als normaler Anwender. Der Vorteil der Nutzung der Kerneltreiber: Du könntest nun einfach ohne großartig testen zu müssen mit simplen echo Befehlen die LED testen, genauso mittels cat den Wert des ADC auslesen. Als Anwendung würde dir nun ein simples Bash Script reichen, das könnte sogar ein Einzeiler sein.
Angehängte Dateien:
Das wäre mein Aufruf über Putty
Markus schrieb: > Ja immer der selbe. Benutzer: pi. Rechte müssten dann auch gleich > sein, oder? Ja, das sollten sie. OK, also wenn du direkt auf dem Pi arbeitest, dort auf dem Desktop eine Shell geöffnet hast und dein Programm startest, dann funktioniert es. Wenn du dich von einem anderen Rechner mittels SSH auf deinem Pi anmeldest bekommst du ja auch eine Shell. Und in dieser Shell startest du dein Programm und dann klappt zwar das Lesen (ADC) aber nicht das Schreiben(LED)? Irgendwelche Fehler geloggt? Eventuell als root mal ›dmesg‹ versuchen. Hast du in deiner - ich vermute mal bash - also ›~/.bashrc‹ irgend etwas drin stehen was nur für non-login shells ausgeführt wird?
Die Meldung ist doch eindeutig, dein Port Expander wird nicht gefunden:
if(adc->detectI2C(0x48)){ // Detect the pcf8591.
Onkel Ted schrieb: > Die Meldung ist doch eindeutig, dein Port Expander wird nicht > gefunden: > > if(adc->detectI2C(0x48)){ // Detect the pcf8591. Stellt sich die Frage warum wird der lokal gefunden und remote nicht. Beide Male als ›root‹ gestartet.
Onkel Ted schrieb: > Die Meldung ist doch eindeutig, dein Port Expander wird nicht gefunden: > > if(adc->detectI2C(0x48)){ // Detect the pcf8591. Das war Blödsinn, vergiss das. wiringPiSetup() <<< sicherer dir da einmal den Rückgabewert und gib diesen aus, genauso bei den digital write.
Doch der wird gefunden. Ich verwende nur einen der beiden ADC. Und der ist auch vorhanden. Den anderen habe ich garnicht in der Schaltung verbaut. Die Abfrage könnte man natürlich weglassen, ja....
Ich würde es einmal mit "sudo ./PotiMitLEDfertig &" versuchen.
Gerald K. schrieb: > Ich würde es einmal mit "sudo ./PotiMitLEDfertig &" versuchen. Warum bitte schön sollte ein solch einfaches Programm im Hintergrund anders laufen als eines im Vordergrund?
Hab ich versucht, hat nichts bewirkt. @Gerald K. Bin grad ein wenig verwirrt wegen dem Rückgabewert und dem ›~/.bashrc‹ Befehl. Wie bekomme ich nochmal genau den Wert? und der Befehl hat nicht funktioniert. Wurde nicht erkannt.
Markus schrieb: > Bin grad ein wenig verwirrt … ›~/.bashrc‹ Befehl. > … und der Befehl hat nicht funktioniert. Wurde nicht erkannt. Hätte mich auch sehr gewundert. Das ist kein Befehl sondern eine Konfigurationsdatei. Aber da du dein Programm sowieso mit root Rechten laufen lässt, dürfte der Inhalt wohl so ziemlich egal sein.
Ich würde es einmal mit "sudo ./PotiMitLEDfertig &" versuchen. Norbert schrieb: > Gerald K. schrieb: > >> Ich würde es einmal mit "sudo ./PotiMitLEDfertig &" versuchen. > > Warum bitte schön sollte ein solch einfaches Programm im Hintergrund > anders laufen als eines im Vordergrund? Warum sollte ein Programm am Desktop gestartet funktionieren und über SSH nicht funktionieren? wiringPi verwendet bzw. unterstützt i2c. Könnte es zwischen ADCDevice() und anschließendem wiringPiSetup() einen Konfikt geben?
Gerald K. schrieb: > Warum sollte ein Programm am Desktop gestartet funktionieren und über > SSH nicht funktionieren? Tja Gerald, das ist aber eine weitere Frage und keine Antwort auf die von mir gestellte.
In dem Zusammenhang kommt mir aber gerade ein Gedanke. Bitte mal als root ein: ›killall PotiMitLEDfertig‹ ausführen. Nicht das bereits zahlreiche im Hintergrund gestartete Prozesse um die Zugriffsrechte kämpfen.
Gerald K. schrieb: > PittyJ schrieb: >> Ich nehme statt Putty gleich ssh. Warum der Umweg über Putty? > > Putty ist das Terminalprogramm mit dem SSH ausgefühert wird. Verstehe ich nicht. Um mich auf meinen Pi einzuloggen mache ich in der Bash: ssh root@kirsche Wobei root der User und kirsche der Rechnername ist. Warum sollte ich noch Putty dafür nehmen? Müßte ja erst einmal installiert werden.
Abwendung mit "sudo ./PotiMitLEDfertig &" starten und mit "gpio readall" PIN Konfiguration (Mode) kontrollieren.
:
Bearbeitet durch User
PittyJ schrieb: > Warum sollte ich noch Putty dafür nehmen? Müßte ja erst einmal > installiert werden. Der To arbeitet vermutlich unter Windows. Gibt es putty unter Linux?
Mh. Dann jetzt mal die verzweifelten Versuche: - Logge dich mal per grafischer Oberfläche ein und teste dann dein Skript über SSH. Vielleicht macht irgendeine autostart Magie irgendwas. - Alternativ mittels "printenv" die Umgebungsvariablen in der grafischen Session mit denen in der SSH Session vergleichen. Vielleicht ist irgendwas anders. Also es wird bestimmt anders sein, aber vielleicht ist da was vergraben. Die grafische Session und die SSH session sind nämlich in den seltensten Fällen 100% identisch. Ich glaube aber nicht, dass das Problem hier liegt. - Braucht dein Programm aus irgendwelchen Gründen doch ein Display (GUI?) Werden irgendwelche Komponenten geladen, die das eventuell bräuchten? mal versuchen die SSH Session mit X11 forwarding zu starten. Ich würde das jetzt zwar auch nicht erwarten, aber man weiß nie... Im Normalfall käme sonst irgendeine Meldung wie "Cannot open display :0" oder so ähnlich. - Anstatt mit sudo <mein_prog> mal mit "sudo su" direkt als root einloggen und dann das Programm ausführen. (Das ist nämlich nicht äquivalent) Gerald K. schrieb: > Der To arbeitet vermutlich unter Windows. Gibt es putty unter Linux? Theoretisch ja. Aber wer das unter Linux nutzt, hat die Kontrolle über seinen Rechner verloren.
Markus schrieb: > Das wäre mein Aufruf über Putty Sehr gut. Die Screensh0ts verwirren mich aber. Im linken hast du offenbar noch nicht die Enter Taste gedrückt, um die Befehlszeile abzuschließen. Markus schrieb: > Versuche ich allerdings das Programm per Putty über SSH auszuführen, so > wird mir lediglich das Putty Terminal am Rechner angezeigt, auf dem > Putty installiert ist. Ich sehe im rechten Screenshot viel mehr als "lediglich das Putty Terminal", nämlich die Ausgaben von deinem Programm. Also läuft dein Programm. Kannst du nochmal für außen stehende verständlich Beschreiben, was dein Problem ist?
Onkel Ted schrieb: > Mit z.B. einem Overlay kannst du den Device Tree um die entsprechenden > Einträge ergänzen und kannst die IC dann direkt nutzen +1 Statt mit Overlay zu Booten geht im laufenden Betrieb: # echo pcf8591 0x48 > /sys/bus/i2c/devices/i2c-0/new_device Methode 4 von https://www.kernel.org/doc/html/latest/i2c/instantiating-devices.html Grade bei GPIO-Expandern ist das schick: es sind einfach neue GPIOs verfügbar, und für die Userspace-Applikation ist es egal, ob die direkt an der CPU hängen oder eben indirekt. API bleibt die gleiche.
:
Bearbeitet durch User
Εrnst B. schrieb: > Statt mit Overlay zu Booten geht im laufenden Betrieb: Stimmt, das ist zum Basteln viel sinnvoller, gerade wenn es das Overlay wie in diesem Fall noch nicht fertig gibt. Ich würde einmal an Stelle des TS schauen was die GPIO so genau aktuell treiben und wer die aktuell für sich beansprucht: cat /sys/kernel/debug/gpio
Gerald K. schrieb: > Ich würde es einmal mit "sudo ./PotiMitLEDfertig &" versuchen. Warum sollte er den Job in den Hintergrund schicken?
Ein T. schrieb: > Gerald K. schrieb: > >> Ich würde es einmal mit "sudo ./PotiMitLEDfertig &" versuchen. > > Warum sollte er den Job in den Hintergrund schicken? Man könnte dann mit "gpio readall" PIN Konfiguration (Mode) die Ports kontrollieren.
Wie greifst Du denn auf die LED-Leiste zu, über Python/gpio oder über /sys/class/gpio... Kannst Du, wenn Du per ssh eingeloggt bist, die LEDs über deinen Zugriff direkt ansteuern Ich vermute stark, dass das ein Rechteproblem ist, Du hast vermutlich am Raspi direkt andere Rechte als über ssh. Gibt doch mal am Raspi direkt und auch per ssh ein 'groups', das zeigt Dir an, in welchen Gruppen Du bist.
Gerald K. schrieb: > Ein T. schrieb: >> Gerald K. schrieb: >> >>> Ich würde es einmal mit "sudo ./PotiMitLEDfertig &" versuchen. >> >> Warum sollte er den Job in den Hintergrund schicken? > > Man könnte dann mit "gpio readall" PIN Konfiguration (Mode) die Ports > kontrollieren. Ja, auch das könnte man womöglich tun. Aber bitte beantworte doch zunächst meine Frage: Warum sollte er den Job in den Hintergrund schicken?
Starte dein Programm mal lokal am Raspberry aber auf der Konsole (CTRL+ALT+F1) und nicht im Terminal der grafischen Oberfläche.
rechteverwerter schrieb: > Wie greifst Du denn auf die LED-Leiste zu, über Python/gpio oder über > /sys/class/gpio... Lesen bildet, Pfosten. > Kannst Du, wenn Du per ssh eingeloggt bist, die LEDs über deinen Zugriff > direkt ansteuern Lesen bildet, wieder Pfosten. > Ich vermute stark, dass das ein Rechteproblem ist, Du hast vermutlich am > Raspi direkt andere Rechte als über ssh. Gibt doch mal am Raspi direkt > und auch per ssh ein 'groups', das zeigt Dir an, in welchen Gruppen Du > bist. Denk bitte mal nach bevor du einfach los blubberst, 3-fach Pfosten.
Ein T. schrieb: > Ja, auch das könnte man womöglich tun. Aber bitte beantworte doch > zunächst meine Frage: Warum sollte er den Job in den Hintergrund > schicken? Am Desktop gestartet läuft das Programm ebenfalls im Hintergrund. Man kann während das Programm im Hintergrund läuft weiter Programme starten.
Probiere es mal mit:
1 | ssh -X -C pi@192.168.x.x |
x: Dort Deine IP des Raspi eintragen.
Gerald K. schrieb: > Ein T. schrieb: >> Ja, auch das könnte man womöglich tun. Aber bitte beantworte doch >> zunächst meine Frage: Warum sollte er den Job in den Hintergrund >> schicken? > > Am Desktop gestartet läuft das Programm ebenfalls im Hintergrund. Das kommt darauf an, wie es aufgerufen wird. Auf jedem mir bekannten Linux kann man eine Terminalanwendung mit einer Shell aufrufen und dort Programme starten -- im Vordergrund, im Hintergrund, mit oder ohne sudo(8) und oder nohup(1)... > Man kann während das Programm im Hintergrund läuft weiter Programme starten. Danke für die Erinnerung, aber die Jobkontrolle unixoider Shells kannte ich schon. Mir ist nur nicht klar, inwieweit das einen Einfluß auf die Funktion des Programms unseres TO haben sollte.
Dieter schrieb: > Probiere es mal mit:ssh -X -C pi@192.168.x.x > x: Dort Deine IP des Raspi eintragen. Bei den doch recht schmalen Datenmengen in einem LAN würde ich vermuten, daß die Kompression lediglich die Latenz minimal erhöht, und was das X-Forwarding soll, wenn auf der Gegenseite kein X-Server läuft, verstehe ich leider auch nicht.
Ein T. schrieb: > und was das X-Forwarding soll, Eine Variante mit kleinen Unterschieden, mit dem kleinen Unterschied, dass es funktioniert auf die Sprünge helfen könnte. So wie es aussieht, verwendet der TO auf dem Desktop vom Raspian einen Terminalemulator.
Eine Variante mit kleinen Unterschieden wäre "ssh -X". Wenn das funktioniert, hilft das auf die Sprünge bei der Fehlersuche.
Also Leute. Es ist mir beinahe schon peinlich dies hier zu schreiben, aber ich habe tatsächlich gerade den Fehler gefunden. Ich wollte gerade versuchen X11 forwarding zu testen, als ich plötzlich ausversehen beim Programmstart das "sudo" vergessen habe. Und, oh Wunder, auf einmal hat alles funktioniert. Also beim Befehl 'sudo ./PotiMitLEDfertig' --> LED's leuchten NICHT, nur Terminal-Anzeige fürs Poti läuft. Aber beim Befehl './PotiMitLEDfertig' --> LED's leichten einwandfrei und Programm funktioniert. Ich habe keinen blassen Schimmer, wieso der Befehl "sudo" bei meiner SSH Sitzung zu diesem Verhalten führt. Bei einer direkten Sitzung am Pi funktioniert das nämlich schon. Naja, jedenfalls war's das Problem. Vielleicht versteht das ja jemand und kanns mir erklären^^ Viele Grüße und Danke für die vielen Antworten, Markus
Das ist aber komisch (nicht peinlich), ich dachte der super-user darf alles. Da würde ich alleine schon aus Neugier weiter nachforschen.
Stefan ⛄ F. schrieb: > Das ist aber komisch (nicht peinlich), ich dachte der super-user > darf > alles. Da würde ich alleine schon aus Neugier weiter nachforschen. Was sagte Hamlet doch gleich in Bezug auf Dänemark? ;-) Aber Zustimmung, ging mir genauso als ich's gelesen habe.
Was sagen id (als normaler user) und sudo id, jeweils über ssh und dann nochmal auf konsole?
Angehängte Dateien:
-
SSH.png
19 KB -
Terminal_direkt.png
26 KB
Tim T. schrieb: > Was sagen id (als normaler user) und sudo id, jeweils über ssh und dann > nochmal auf konsole? Hier beide Bilder. Einmal per SSH und einmal direkt im Terminal vom Pi.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.