[Problem] SAS und Python für I2C-Interface - Pi hängt sich nach gewisser Zeit einfach auf

JL3

Aktives Mitglied
Mitglied seit
4 Dez 2010
Beiträge
1,995
Punkte für Reaktionen
8
Punkte
38
Noch immer kämpfe ich mit dem Pi und Python.

Hintergrund: SAS-Werte sollen auf einem 20x4 Zeichen-LCD dargestellt werden. Dafür schreibt SAS mit einem psg und der Hilfe des sashelper den Inhalt der Anzeige in eine Datei. Diese wird sekündlich auf dem Pi, an dem das Display angeschlossern ist, auf dem Display ausgegeben. Dies geschieht mit einem endlos laufenden Python-Script, welches den Dateiinhalt im Sekundentakt einliest und dann über die I2C-Schnittstelle des GPIO an das Display zur Anzeige sendet.

Das läuft mal 7, mal 10 oder auch mal 20 Stunden problemlos. Dann hängt der Pi mit dem Display sich einfach auf und nichts geht mehr.

Woran kann so etwas liegen? Laufen Python-Scripte nicht endlos durch? Ich habe inzwischen jede Komponente gewechselt. Das Phänomen bleibt. Weiß jemand Rat?
 
Zuletzt bearbeitet:
Hm, hab mal recherchiert, aber nichts dazu gefunden.
Es gibt in einer anderen Skriptsprache, auch Python, ein Schleifenlimit von 10.000 Durchläufen.
Damit, falls diese Schleife exklusiv läuft, ohne Waitstates, das System nicht ewig lahmlegt.
Das scheint hier ja gerade nicht der Fall zu sein.
Schwer zu sagen was das sein könnte.

Deswegen fällt mir dazu momentan nur ein:
Bau selber ein Limit ein, von einem Zeitraum wo du meinst, dass müsste passen.
Wenn es die Schleife ist, für die Schleife.
Wenn es die Skriptlaufzeit ist, für das Skript.
...und dann wirds einfach wieder gestartet.

Vielleicht mit einem Watchdog?
...bevor es zu spät ist.
 
Zuletzt bearbeitet:
Der Watchdog reagiert nicht und der Pi hängt komplett. Ich habe nochmal den Pi gewechselt, um zu sehen, ob es mit meinem Pi B+ durchläuft. Mal abwarten, denn es dauert ja ab und an einen Tag, bis er hängt. :gruebel:
 
Moin JL3

Vielleicht hilft dir das, im deutschen Python Forum hatte Jemand ein ähnliches Problem.
...aber bevor ich, aus Mangel an Erfahrung, was falsches schreibe, lies das lieber mal selber: Python Script beendet sich selbst - warum?
 
Danke für den Link, ist aber ein anders gelagertes Problem. Bei mir hängt nicht nur das Script sondern der Pi sich komplett auf. Ich vermute ein Problem mit dem GPIO-Bus. Zur Zeit teste ich einen meiner B+, der bis jetzt schon 18 Stunden durchlief. Wenn er es morgen auch noch macht, passt die Kombination und ich verwende ihn für die Displayanzeige. Wenn nicht versuche ich Treiber für die I2C-Schnittstelle unter PHP zu finden.

Wenn es läuft, ist es eine schöne Sache. Alles Wichtige über SAS wird abwechselnd angezeigt. Aber es soll halt 24x7 nonstop durchlaufen und nicht irgendwann hängenbleiben. ;)
 
Jetzt mit dem 2. B+ läuft es inzwischen über 28 Stunden. Pi 2 und vorheriger B+ hängten sich wie oben erwähnt auf. Jetzt gilt es wohl herauszufinden, warum es mit diesem 2. Pi B+ funktioniert und mit den beiden anderen nicht. :gruebel:
 
Moins

Hm, aufgeschnappt, beim Recherchieren, nur aus Erinnerung: Möglicher GPIO Bug
...frag mich jetzt aber nicht wo.
(Möglicherweise hier :gruebel: Post #5 :blonk: )
 
Jetzt mit dem 3. Pi (Pi B+) läuft und läuft und läuft das Script jetzt schon über 1 1/2 Tage ohne das geringste Problem. Nur... warum? :gruebel:

Können die GPIOs der beiden anderen eine Macke haben? Gleich bei zwei Geräten? Es ist mehr als seltsam. Sobald ich noch einen Pi frei habe, werde ich es auch mit dem testen. Normalerweise sind die Himbeeren eigentlich sehr robust...
 
Zuverlässig, sparsam...
Selbst mein Pi, der normale, nicht B+, läft @1GHz als wenn nichts wäre.
...aber ich spiele auch nicht an den GPIOs rum, vielleicht sind die ja so zickig.
 
Die GPIOs sind - soweit ich weiß - direkt mit dem Bus verbunden. Probleme können da sicher gleich den ganzen Pi aufhängen lassen. Trotzdem seltsam, dass es da solche Unterschiede gibt. Der getestete Pi B+, der sich aufhängte, lief zuvor als SAS-Testsystem mindestens einen Monat ununterbrochen und ohne je sich aufzuhängen. Der Pi B+, der sich nicht aufhängt, lief ebenfalls davor mal ein paar Wochen als SAS-Testsystem. Ist nicht so, dass sie irgendwann zuvor je gezickt hätten. Ich werde es weiter beobachten.

Mit dem TFT als Anzeigedisplay werde ich mich auch nochmal beschäftigen. Dazu wollte ich ebenfalls Python nutzen, aber in einer "richtigen" Anzeigeumgebung des Raspbian-OS. Da dürfte es hoffentlich weniger Überraschungen geben. ;)
 
@Pikachu: Vielen Dank für die Info. :) Da ich fast nur MT-F habe, werde ich auch das mal als SAS-Anzeige per psg testen. Leider ist die nutzbare Anzeige vom MT-F nicht besonders groß und in hellen Räumen nur schwer lesbar, aber trotzdem wirds mal ausprobiert. ;)
 
Moins

Mist ich Hab keine AVM DECTs....

Das eröffnet ja immense Möglichkeiten.
...theoretisch. :D

Zum Beispiel...
1. Ein Fritz!Box Telefonbucheintrag mit Bild.
2. Die Skripte bereiten das Bild auf/vor.
3. Wird das DECT von diesen "Teilnehmer" angerufen (laut oder leise), erscheint schon das was Sache ist.
4. So als Alarmfunktion oder so.
5. Zusätzlich können die verlinkten Skripte natürlich das machen was sie können/sollen.
 
Zuletzt bearbeitet:
Na ja so neu ist das nicht denn die meisten nutzen es wohl um das Bild der WebCam
vor der Tür zu Zeigen, dazu gibt es ja auch schon genug im Netz.
 
So, am Pi liegt es nicht. Heute Mittag hat sich der 3. Pi ein B+ nach über 48 Stunden verabschiedet und aufgehängt. :(

Hat jemand noch eine Idee, woran das liegen könnte?
 
Langsam komme ich dem Problem näher. Es geht um die Abfrage des Temperatursensors des Pi. Wird dieser gleichzeitig von zwei Programmen vorgenommen, dann steigt der Pi aus und hängt sich auf. Watchdog hängt sich seltsamerweise gleich mit auf und ist da keine Hilfe mehr. Minimiert man die Abfrage auf einen Prozess und lässt diesem genügend Zeit, die Werte zu ermitteln, hängt sich der Pi nicht mehr auf. Es ist an allen getesteten Pi's nachstellbar. Die unterschiedliche Laufzeit bis zum Ausstieg kam dadurch, dass beide Prozesse wirklich zeitgleich Zugriff nehmen und dann jedwede weitere Abfrage unmöglich machen, bis zum Hängen des Pi. Warum hier der Hardware-Watchdog so überhaupt nicht funktioniert, ist enttäuschend.

Warum der gleichzeitge Zugriff mit sudo cat /sys/class/thermal/thermal_zone0/temp dieses Problem verursacht ist unklar, aber wohl ein Fehler im Linuxkernel des Rasbian. Zumindest wurde wohl ein solches Szenario nie getestet, kommt aber bei sas durch seine psgs (wenn sie gleichartige Abfragen auf den gleichen Pi enthalten) schon öfter vor.

Zumindest weiß ich, dass es nicht an einem defekten Pi oder an Python oder an defekten GPIOs liegt. ;)

PS: Benutzt man an seinem Pi PiGlow und lässt dieses als Systemmonitor fungieren (wo auch die Temperatur dargestellt wird) und nutzt dazu sas mit einem psg, welches auch die CPU-Temperatur anzeigt, so hängt sich auch dieser Pi nach einigen Minuten, Stunden oder Tagen auf, sobald zwei Prozesse die Temperatur auslesen...

PPS: Seitdem ich dies berücksichtige läuft mein LCD2004-Display per I2C ohne weitere Probleme. :)

Nachtrag: Als nächstes versuche ich SAS-Sprachsteuerung über den Pi. Wenn das läuft, geht Kommunikation und Schalten der Dosen per Zuruf. ;)

Nachtrag2: Es sind wohl doch die GPIO des Pi. Ich habe die Kabel des I2C-Displays auf über das Doppelte verlängert und seitdem arbeiten zwei so angeschlossene Pi-Display-Kombinationen ohne weitere Probleme. Meine Vermutung ist, dass nun der Eigenwiderstand der Kabel nun groß genug ist, dass das angeschlossene Gerät nun den Prozessor des Pi nicht mehr abstürzen lassen kann.
 
Zuletzt bearbeitet:
Nachtrag3: Es hat etwas mit den GPIO zu tun, aber startet man den Pi und lässt ihn in Ruhe (kein Samba-, kein SSH-Zugriff) dann läuft er ohne Probleme. Meldet man sich einmal per PuTTY an und wieder ab, kann man davon ausgehen, dass er sich in den nächsten Stunden aufhängt. Ein seltsames, noch immer ungeklärtes Verhalten... :gruebel:
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,687
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.