Damit meint er einen Client-Server-Ansatz. Wenn man zB pigpio verwenden wuerde, dann laeuft da der pigpiod, und kontrolliert zentral alle Resourcen. Und verschiedene clients koennen dann mit dem reden, und zB einen Pin schalten.
Das ist erstmal besser, als sich auf einen eher implizit geteilten Zustand eines Ausgabepins zu verlassen, oder zu riskieren, den aus verschiedenen Prozessen gleichzeitig zu bearbeiten....
Moin,
genau darum gehts. Danke __deets__ , für die Erklärung.
Es ging mir im Grunde nur darum, das Grundprinzip aufzuzeigen. Programme laufen in der Regel sequentiell ab. Parallele Prozesse gibt es im eigentlichen Sinn nicht, da die verfügbare Rechenzeit unter den Programmen nacheinander aufgeteilt wird.
In dem Fall z.B. macht Programm 1 in Zeile 299 irgendwas mit Pin 4, im nächsten Takt wird Programm 2 die Rechenzeit zugeteilt und das Programm macht irgendwas mit PIN4 , dann gehts wieder weiter mit Programm 1 Zeile 300 ... So kommt es dann zum undefinierten Zustand und im Ernstfall schmieren beide Programme ab. Mit dem Gedanken an einen Mehrkernprozessor wird es dann noch verrückter, wenn die beiden Programme womöglich auf verschiedenen Kernen laufen.
Programmierung ist nicht einfach, würde ich mal behaupten. Jedes Programm benötigt ein Konzept und würde lügen, wenn ich sagen würde, dass ich mir durch ein fehlendes oder fehlerhaftes Konzept nicht schon ein blaues Auge eingehandelt hätte. (mindestens eines ...)
Simsi hat mit der Programmierung begonnen und wird sicher in der Zukunft die Aufgaben anders angehen. Da entwickelt jeder seinen eigenen Stil.
Das ist auch kein Problem.
So nun noch ein Link für eine Server/Clientgeschichte.
https://riptutorial.com/python/example…-server-example
Darauf kann man die Geschichte aufbauen.
Der Server handelt PIN4 und wartet auf die Ereignisse , sei es eine Taste oder ein Signal von einem Client, welcher durchaus von einem Cronjob gestartet werden kann.