DAS ist die Kunst des programmierens solche deadlocks einfach nicht zu machen
spröde einfache antwort: blocking read vermeiden!z.B. der, der UART übeträgt...
du musst halt auch ein wenig mehr aufpassen was du machst wenn du threads verwendest ... schonmal mit serial.available() gearbeitet?! das blockiert nicht und sagt dir wieviele bytes im puffer sind!
es gibt KAUM eine schnittstelle bei der es unmöglich ist blocking calls zu vermeiden, alles nur eine frage des aufwandes
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
das ist doch Unsinn, das kann ich nicht 100%ig vermeiden!Zitat von Ceos
z.B., was ist wenn das UART-USB- Kabel abgeht oder doch wieder der kernel dazwischenfunkt und zu einem timeout führt (edit: wie vorher in der singlethread-Version)?
Oder der Arduino aus irgendeinem unbekannten Grund temporär den USB blockiert?
Genau dafür brauche ich nun eben diesen Plan B!
Wenn man richtig Bare Metal programmiert ist das möglich, Wenn man Arduino nutzt muss man halt mit den Schwächen leben oder sich intensiver damit befassen und einen Workaround entwickeln oder finden!
Das kann man Problemlos erkennen, wenn man Kontrolle über den USB Stack hat bzw. weis wie die Peripherie des Chip arbeitetwas ist wenn das UART-USB- Kabel abgeht
was hat das bitte mit read() und available() auf Controllerseite zu tun, das ist abwegig! Oder du meinst etwas anderes...oder doch wieder der kernel dazwischenfunkt
wenn available == 0 dann sperrt read oder bekommt ein timeout wenn man das einstellen kann (hab ich gerade keine ahung unter arduino was das angeht)und zu einem timeout führt (edit: wie vorher in der singlethread-Version)?
wenn available > 0 dann sperrt read 100% nicht!
Das ist ein ARduino Problem und der einzige Weg wäre Arduino nicht zu nutzen!Oder der Arduino aus irgendeinem unbekannten Grund temporär den USB blockiert?
Ich hab doch im ersten Satz geschrieben das es die Kunst des Programmierens ist ... Wenn ich einen Vergleich zwischen Arduino und echtem Bare Metal programmieren ziehen müsste, würde ich sagen, Bare Metal ist mit Pinsel und Leinwand während Arduino Photoshop und einen Drucker sind.
Dein Photoshop(Arduino) kann hängen bleiben und dein Drucker(Board Lib für Arduino) kann abstürzen oder falsch arbeiten.
Beim Zeichnen mit Pinsel und Leinwand entscheidet nur die Erfahrung, Übung und die Qualität der Leinwand(Controller/Board) über das Ergebnis.
Wenn man Bibliotheken nutzt, muss man sich mit den Schwächen abfinden oder eben selber das Konzept verstehen und entweder den Fhler an der Lib beheben oder selber eine schreiben.
Aber da rutschen wir gerade in eine Grundsatzdiskussion abalso lassen wir das Thema lieber, ich wollte dir nur klarmachen dass es absolut vermeidbar ist wenn man auf Komfort verzichtet. (ohne genauer auszuführen was ich mit Konfort meine)
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
es geht um Raspi code, nicht um Arduino-Code!
SerialAvailable() aus der wiringPi lib arbeitet nicht zuverlässig, um solche Fehler eindeutig zu lokalisieren, und auch timeouts tun es nicht, das habe ich schon mit diversen Tests (aus dem Raspi C++ Unterforum) herausgefunden. und wenn Raspi und Arduino im Robot verbaut sind und der Robot herumfährt und folglich der direkten Beobachtung entzogen ist, kann man den Grund für eine Verbindungsunterbrechung nicht unbedingt erkennen.
Es geht hier mit dem Beenden und Neustart eines Threads also lediglich um den automatisierten Versuch des autonomen Programms, den momentanen Fehler (z.B. kein Thread-heartbeat mehr) mit Bordmitteln selber zu händeln.
Einer davon soll sein:
den hängenden Thread stoppen (schrittweise: erst pthread_exit(), wenn erfolglos: pthread_kill(), dann das Serial file zu schließen, Variablen zu resetten, und dann das Serial file neu zu öffnen und den Thread neu zu starten.
Erfahrungsgemäß treten solche Fehler ab und an nicht nur bei UART sondern auch bei I2C auf, auch dafür soll eine solche Notfallmaßnahme implementiert werden.
Ach verdammt schon wieder mental verrutscht ... Ich war schon wieder bei Arduino Code sorry
Aber das macht es ja sogar noch einfacher, da der Kernel eigentlich alle Funktionen bereitstellt um auch das USB-Detach zu erkennen ... dass der Kernel beim read dazwischen Funkt und man das nicht erkennen kann fällt für mich unter die Kategorie "Kernel Bug" und damit muss man halt leben.
Aber dass die WiringPi Lib notorisch Buggy ist sollte bekannt sein. Es wird ja kontinuierlich dran gebastelt von vielen Köchen (dazu habe ich schonmal was gesagt)
Wenn du statt der Wiring Pi direkt die Kernelfunktionen benutzt hast du auch hier die volle Kontrolle!
UART lässt sich auch ganz bequem per open("/dev/ttyXXXX") erledigen aber dazu müsstest du dich ein wenig tiefer in Linux versetzen
In Lnux wird jede Peripherie und USB Gerät durch den entsprechenden Kernel-Treiber in das Dateisystem projeziert. Es ist die Qualität des Treibers die entscheidet was für Funktionen man nutzen kann, ähnlich wie es die Entscheidung des Hersteller ist wie eine Peripherie in dem entsprechenden Controller integriert wird.
Das was bei Linux das DAteisystem ist, sind die Steuerregister im Controller und solange man die beherrscht und auch der TReiber die Funktion hergibt, kann man auch hier die volle Kontrolle bekommen.
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
ich habe das Gefühl, du argumentierst sehr ins Blaue - hast du jemals selber auf dem Raspi UART mit wiringPi programmiert?
Nur von wiringPi gibt es ja die serialAvailable Funktion.
Was weißt du sonst über die Funktionsweise der wiringSerial Funktionen?
Dass ich aber weiß, wie man UART nutzt, das kannst du schon vorraussetzen, wie du auch problemlos in meinem Arduino-Raspi-UART code nachgucken kannst (https://www.roboternetz.de/community...l=1#post652616) - der läuft ja nun unter Normalbedingungen zusammen mit den kernel Programmen stabil
(ich kann nur nicht garantieren, dass IMMER der kernel nur das tut, was ich vorhersehen kann)
- - - Aktualisiert - - -
PS,
an der WiringPi Lib aber arbeitet nur Gordon Henderson, selbst da irrst du also - es wird über das apt package oder direkt von Gordon's git site bereitgestellt.Aber dass die WiringPi Lib notorisch Buggy ist sollte bekannt sein. Es wird ja kontinuierlich dran gebastelt von vielen Köchen (dazu habe ich schonmal was gesagt)
Bitte halte dich also ans Topic, und da geht es hier ausschließlich um pthread.
Um Threads zu steuern und zu Überwachen gibt es viele Möglichkeiten (besonders beim Mehrkern System):Einer davon soll sein:
den hängenden Thread stoppen (schrittweise: erst pthread_exit(), wenn erfolglos: pthread_kill(), dann das Serial file zu schließen, Variablen zu resetten, und dann das Serial file neu zu öffnen und den Thread neu zu starten.
Join ist die simpelste und ist eigentlich nur Sinnvoll, wenn man kurzlebige Threads hat, welche etwas parallel bearbeiten sollen udn dann ERgebnisse zurücklieefern sollen ... der Master kreaiert 10 Threads die unabhängig rechnen, wärend der Master noch irgendwas erledigt. Damit man dann synchronisieren kann, wendet man dann nacheinander auf alle Worker ein Join an um den Thread mit der Main zu synchronisieren, endet der Thread, fährt der Master mit den nächsten Join fort oder was auch immer er zu tun hat. (Das birgt den Nachteil dass man garantieren muss, dass der Thread niemals in ein Dead Lock geraten kann oder diese Methode ist unbrauchbar!)
Die Methode die für dich sinvoller erscheint sind Steuersignale und eine abbrechbare Thread Schleife ohne irgendwelche Hilfmittel von Thread-Librarys! (Thread librarys mögen verschiedene hilfereiche Funktionen anbieten, aber bisher war das immer mit einem unsauberen Exit behaftet oder mit entsprechend umständlichem try-final Blöcken bzw. einem Custom-Destructor)
Deine Threadschleife braucht 2 Abbruchflags von außen und 1 Zustandsflag nach drausßen. Das erste Abbruchsflag sollte in deinem Code dazu führen dass alles abgeschlossen wird und die Eegebnisse zurück geliefert werden und anschließend über das Zustandsflag signalisieren dass der Thread quasi beendet ist (in etwa wie ich es in dem Beispiel weiter oben beschrieben habe, ein Join nach dem pollen eines "Thread beendet" Signals ist immernoch sinnvoll um Raceing Conditions zu vermeiden, sollte aber i.d.R. nicht länger als ein paar Takte blockieren!)
Es gibt Thread Librarys die bieten entsprechende Abort-Funktionen an, die muss man dann im Thread Objekt selbst überschreiben oder eine Methode anbinden/implementieren, das macht es etwas übersichtlicher!
Aber wenn dein Thread einfach nicht "Thread beendet" zurück meldet musst du dir selbst ein kleines Timeout einbauen und den Thread halt mit Kill beenden!
Join sollte man nur nutzen wenn man auch garnatieren kann dass der Thread in absehbarer Zeit beendet wird oder das Programm hängt sich auf
PS:Ja, habe ich ... nutze ich nur nicht gerne weil eben verbuggt aber serial per kernel ist halt auch eine scheiß arbeit.hast du jemals selber auf dem Raspi UART mit wiringPi programmiert?
Nur von wiringPi gibt es ja die serialAvailable Funktion.
Was weißt du sonst über die Funktionsweise der wiringSerial Funktionen?
Ich weis auch so prinzipiell wie es arbeitet, der Code steht auf Github da kann man nachlesen und auch Reports machen wenn einem ein Bug auffällt
Das entscheidende ist dass du noch nicht weist wie Linux arbeitet und deshalb nicht das große ganz und die alternativen siehst .. du argumentiert es sei "unmöglich" exakt formuliert wäre da besseer "es ist für DICH und IM MOMENT unmöglich"
Kunst kommt vom Können und das kann man lernen
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
wieder mal sehr theoretisch -
poste lieber mal einen funktionierenden Code, um meinen hängenden pthread mit UART zu stoppen und neu zu starten, aller andere theoretische Krimskrams ist mir ja klar.
wenn der pthread aber komplett hängt, dann empfängt er auch von außen keine Variablen mehr bzw. kann auch nicht auf Semaphore oder interne Variablen reagieren.
Er hängt dann fest wie wenn da nur stünde
while(1);
- - - Aktualisiert - - -
PS,
klar weiß ich, wie man mit Linux programmiert, und Details, die ich nocht weiß, die frage ich nach.
So wie jetzt, aber wie es grob geht weiß ich ja auch - siehe hier:
https://www.roboternetz.de/community...l=1#post652792
- - - Aktualisiert - - -
PS 2:
der Code auf github ist nicht von Gordon sondern inoffiziell von einer dritten Person, was aber von Gordon nicht supportet und auch nicht registriert wird.
Berechtigungen
Zitieren
Lesezeichen