Python-Script beim booten starten

Python auf Einplatinencomputer wie Raspberry Pi, Banana Pi / Python für Micro-Controller
Antworten
Schlaaaange
User
Beiträge: 34
Registriert: Sonntag 5. Januar 2020, 18:05

Hallo Leute,
ich möchte mir eine kleine GUI mit tkinter in Python basteln und über den Raspi ein paar kleine SPS-Aufgaben erledigen.
Dafür habe ich mir ein schönes Gehäuse gebaut und habe dort auch ein 10 Zoll Display verbaut.
Dieses Display ist ganz einfach über HDMI an den Raspi angeschlossen.
Auf der SD-Karte habe ich Raspbian Lite geflasht.
Nach erfolgreichen Boot habe ich den WindowManager "nodm", den xserver und xinit, sowie python3-pip, RPI-GPIO, wiringpi, tkinter installiert.
Mit den Texteditor "nano" kann ich jetzt auch Python oder C - Programme schreiben und diese auf der Konsole ausführen.
Wenn ich tkinter-Programme schreibe kann ich die auch wie folgt starten:
Unter tty1:
startx
Wechseln auf tty2 (STRG+ALT-F2):
DISPLAY=:0 python meine_app.py
Wechseln auf tty1:
Da ist die Anwendung dann zu sehen.

1. Frage:
Geht das auch eleganter?
2. Frage:
Wie könnte man so am besten Pythonprogramme debuggen?

Und die 3. Frage:
Wie bekomme ich nach dem Bootvorgang den XServer mit meiner Anwendung automatisch gestartet?

Danke im vorraus.
Schlaaaange
User
Beiträge: 34
Registriert: Sonntag 5. Januar 2020, 18:05

Zur 1. Frage:
Ok!
Ich denke elegante geht es mit:

Code: Alles auswählen

if os.environ.get("DISPLAY", "") == "":
  os.environ.__setitem__("DISPLAY", ":0")
Außerdem habe ich mir die Titelleiste damit entfernt:

Code: Alles auswählen

main.wm_attributes("-fullscreen", "true")
Ich arbeite dann viel mit Frames.

Zur 2. Frage:
Mit print() geht es schon ganz gut, wenn man ständig mit strg+alt+F1 oder F2 zwischen den Anzeigen wechselt.
Aber das geht bestimmt auch noch besser, oder?

Bei 3. hänge ich irgendwie noch.

Außerdem (Da ich kein ssh, oder ähnlich nutze) habe ich mir auf der SD-Karte einen Order "outside" erstellt.
Ich kann dann immer die SD-Karte entfernen und in diesen Ordner Bilder, Python- oder C-Scripte, etc. packen.
Auf dem Raspi kann ich dann im Verzeichnis:
cd /boot/outside
auf die externen Dateien zugreifen.
__deets__
User
Beiträge: 14494
Registriert: Mittwoch 14. Oktober 2015, 14:29

Mit Woerterbuechern arbeitet man ueblicherweise mit dem []-Operator:

Code: Alles auswählen

if os.environ.get("DISPLAY") is None:
    os.environ["DISPLAY"] = ":0"
Seit Python 3.5 oder so gibt es das breakpoint()-Kommando. Das kann man einfach in den Code einfuegen, und da haelt er dann an. Es gibt noch bequemere Debugger, aber dafuer musst du eine IDE aufsetzen. Ich mach's immer nur so.

Gibt es einen Grund, kein SSH zu benutzen? Das ist doch endlos fummelig.

Zu den autostart-Themen kann ich nichts sagen, das sollte aber recherchierbar sein. Ich kenne nur dein eher ungewoehnliches Setup nicht, die normalen Foren zum PI beziehen sich auf LXDE.
nezzcarth
User
Beiträge: 1632
Registriert: Samstag 16. April 2011, 12:47

__deets__ hat geschrieben: Donnerstag 7. Januar 2021, 11:59 Ich kenne nur dein eher ungewoehnliches Setup nicht, die normalen Foren zum PI beziehen sich auf LXDE.
Soweit ich das verstehe, sollte man nodm jedenfalls nicht mehr verwenden, da der Autor selbst inzwischen davon abgerückt ist und dies empfiehlt: https://github.com/spanezz/lightdm-autologin-greeter
Schlaaaange
User
Beiträge: 34
Registriert: Sonntag 5. Januar 2020, 18:05

Hallo Leute,
also in meinem 1. Post habe ich geschrieben das ich "nodm" installiert habe.
Das habe ich auch, aber das ist hierbei ein Display-Manager und erstmal uninteressant.
Als Window-Manager habe ich "matchbox-window-manager" installiert.

Raspbian Lite möchte ich verwenden weil ich keine bunte "Klickibuntu"-GUI beim starten will und Linuxbefehle verstehen und anwenden möchte.
Mein aktuelles Linuxwissen möchte ich mit der intensiven Nutzung des Terminals erweitern.

Also irgendwie schwimme ich zwischen /etc/rc.local und meinem versteckten startx-Script /home/pi/.xinitrc hin-und-her.

Wenn ich nach dem Bootvorgang startx ausführe wird das hier ausgeführt:

Code: Alles auswählen

#!/bin/sh
xset s off -dpms
exec matchbox-window-manager &
while true; do
  python3 /home/pi/gui.py
done
Das funktioniert auch so, aber wie bekomme ich den startx und mein Python-Script beim Bootvorgang gleichzeitig gestartet?

In etc/rc.local steht:

Code: Alles auswählen

exec startx &
exit 0
Damit startet der XServer beim Booten auch, aber mein Python-Script wird nicht geladen. (schwarzer Bildschirm mit Mauszeiger)
Wenn ich das & hinter startx weglasse hängt sich mein ganzes System auf, weil der XServer in einer unendlichen Loop (Schleife) ist.
Und wenn ich in der rc.local Datei nach dem startx (mit &) mein python3-Program versuche zu starten ist der XServer schon wieder tot bevor mein Programm den DISPLAY nutzen kann.
Wie könnte ich jetzt zum Beispiel 2 Programme in verschiedene ttys starten?
Oder ist das Quatsch?

Wie bekomme ich den Bootvorgang hin?

LInuxnoob braucht hilfe!
Danke!
Schlaaaange
User
Beiträge: 34
Registriert: Sonntag 5. Januar 2020, 18:05

Hat sich erledigt!

Es funktioniert wenn ich:

Code: Alles auswählen

exec nodm &
exec matchbox-window-manager &
python3 /home/pi/gui.py
exit 0
..in die Datei "/etc/rc.local" schreibe.

Irgendwie hatte ich mich am startx festgebissen.

So startet meine GUI-Anwendung direkt nach dem Bootvorgang automatisch.
nezzcarth
User
Beiträge: 1632
Registriert: Samstag 16. April 2011, 12:47

Schön, dass es funktioniert. Allerdings sollte man vielleicht darauf hinweisen, dass das normalerweise nicht die empfohlene, moderne Variante ist (allerdings scheinen nodm und matchbox auch eher unkonventionell zu sein). Der Display-Manager wird als Systemd-Unit gestartet und über systemctl enable nodm.service (ggf. passenden Namen ersetzen) aktiviert. Die standardisierte Methode zum Autostart von (GUI-)Programmen ist über /etc/xdg/autostart (wenn der WM das unterstützt; Siehe: https://wiki.archlinux.org/index.php/XDG_Autostart).

Die Verwendung von "/etc/rc.local" hält sich im Raspberry-Pi-Umfeld leider hartnäckig, ist aber eigentlich überholt.
Benutzeravatar
joernius
User
Beiträge: 31
Registriert: Donnerstag 11. Juni 2020, 13:47
Wohnort: Dresden
Kontaktdaten:

nezzcarth hat geschrieben: Freitag 8. Januar 2021, 21:19
Die Verwendung von "/etc/rc.local" hält sich im Raspberry-Pi-Umfeld leider hartnäckig, ist aber eigentlich überholt.
Alles, was praktisch ist, hält sich.
Nur Masoisten schreiben sich eine Autostart-Datei für den systemd. Einen kurzen Aufruf in die /etc/rc.local geht schnell, man braucht nicht suchen wo es steht und schon gar nicht eine Service-Datei schreiben. Außer natürlich für die betriebliche Massenproduktion. Aber wir sind bei Raspberry. Was ist einfacher? Autostart per Crontab *duck & weg" ...
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@joernius: So praktisch ist es halt nicht mehr, denn die rc.local wird auf systemd-basierten Systemen teilweise zu einem anderen Zeitpunkt ausgeführt, wenn nicht nicht alles gestartet ist was früher beim init schon verfügbar war. Zudem *ist* so eine systemd-Unit sehr praktisch für Dienste, denn dann kann man den Dienst nicht nur starten, sondern auch stoppen, (de)aktivieren, Logs anlegen lassen, angeben was passieren soll wenn der abstürzt oder sich unerwartet beendet, und so weiter.

Und das ist a) nicht nur „für die betriebliche Massenproduktion“ und b) ist auch ein Raspberry Pi ein ganz normales Linux-System, keine Ahnung warum das ein Grund sein sollte den anders zu behandeln als andere Rechner.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Schlaaaange
User
Beiträge: 34
Registriert: Sonntag 5. Januar 2020, 18:05

Danke für eure ganzen Antworten.
Ich bin Einsteiger!
Keep it simple!
Benutzeravatar
DeaD_EyE
User
Beiträge: 1012
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

joernius hat geschrieben: Dienstag 12. Januar 2021, 10:29 Nur Masoisten schreiben sich eine Autostart-Datei für den systemd.
Witzig, genau das halte ich von denjenigen, die rc.local verwenden.
Bei modernen Distributionen gibt es das nicht mehr, genauso wie man schon lange ifconfig entfernt hat.
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
Antworten