Posts by peuler

Wenn das Thema erledigt ist, markiere dies bitte auch noch, danke.

An Peter0311: Habe Deinen Beitrag #72 eben gemeldet. Bei Deiner Wortwahl ist die eingestellte Oktanzahl viel zu hoch eingestellt. Vielleicht solltest Du mit Blick auf Deinen Neffen (Zitat "... alle Welt für blöd hält") sein Verhalten nicht zu Deinem Leitbild machen.

An dem ursprünglichen Jahr der Verfügbarkeit (2024) scheint mehr dran zu sein, als mir das lieb ist.

Auf welchem OS laufen die Python-Programme denn heute? Hierzu Klarheit zu haben, ist wohl sehr hilfreich.

Quote from Bernd666

Nachdem es nun Raspberri Pi OS basierend auf Debian Bookworm gibt, habe ich mal getestet wie nun der Stand der Dinge ist.

Getestet habe ich wieder mit einem Raspberry Pi4 und einem 3.2 Inch LCD-Display von Joy-IT.

Handelt es sich bei dem erwähnten Display um das RB-TFT 3.2 mit den 3 Knöpfen am linken Rand?

Falls ja; Hast Du ein Beispiel in C/C++, wie man die Knöpfe benutzt?

P.S.: Habe eben herausgefunden, wie man das mit den Knöpfen macht: GPIOs werden kurzgeschlossen, wenn ein Knopf gedrückt wird, siehe Anleitung zu dem Display.

Ich schlage vor, dass Du mal mit einem Debugger da durchgehst und Dir Schritt für Schritt anzeigen lässt, was das Programm wirklich tut.

Quote from __blackjack__

Ich glaube wenn Du Framework geschrieben hast, meintest Du eigentlich IDE.

Habe Code::Blocks mit Qt verwechselt. Qt ist für mich ein Framework, Code::Blocks ist hingegen eine IDE (allerdings seit über 3 Jahren nicht mehr erneuert). Eine IDE halte ich für sinnvoll, ich würde dennoch nicht zu Code::Blocks raten sondern zu Geany, weil letzteres auf dem Pi zu den vorinstallierten Programmen gehört.

Quote from framp

Kannst Du auch mitlerweile in Deinem Profile setzen

Danke für den Tipp, habe ich angepasst.

Zu Deinen Punkten meine Sicht wie folgt:

Endlosschleife: Welchen Sinn macht es, eine Funktion laufen zu lassen, die nie endet? Das gibt es im wahren Leben auch nicht. Denk lieber mal darüber nach, eine Ende-Bedingung zu definieren, unter der die Endlosschleife endet.

join-Aufrufe:

Du solltest Dir Grundlagenwissen zur Thread-Programmierung aneignen, um zu verstehen, warum es join-Aufrufe überhaupt gibt. Diese sind zur Steuerung und Kontrolle von Threads notwendig, um gezielt auf das Ende eines Threads zu warten.

Compiler-Aufruf:

Mein ernst gemeinter Rat: Lass die Finger von Frameworks wie Code::Blocks, bist Du sie wirklich brauchst. Bei dem vorgestellten Programm sehe ich nicht im Ansatz, warum der Einsatz des Frameworks Sinn ergeben soll.

Die von Dir erwähnte Datei libpthread.so ist kein Compiler sondern eine Bibliothek. Dass Du das nicht erkannt hast, zeigt, dass Dir jegliche Grundlagen zur Programmierung in C/C++ fehlen. Da hast Du noch eine sehr steile Lernkurve vor Dir.

Einrückung/Formatierung:

Einfache Regeln helfen hier weiter: Geschweifte Klammer-Auf ist immer gleich weit von dem linken Rand entfernt wie die dazugehörige Klammer-Zu. Und wenn nach einer Klammer-Auf eine weitere Klammer-Auf kommt, dann wird die nächste Klammer-Auf 4-8 Leerzeichen nach rechts gerückt (per Tabulator).

WiringPi:

Die Bibliothek wird nicht mehr gepflegt. Suche mal in diesem Forum nach dem Begriff, da gibt es schon jede Menge Beiträge, die auch Alternativen beschreiben.

Fazit:

Du solltest Dir Grundlagenwissen in C/C++ aneignen (Bücher, Youtube ...) und dann kritisch Deinen Code anschauen. Und lass die Finger von Frameworks und fange ganz klassisch mit Editor und Compiler (gcc oder g++) an.

Zu Post #23: Mir ist die schlechte Formatierung auch aufgefallen, dazu kommen noch weitere Punkte am Code, die mir nicht gefallen. Aber ich will den TO nicht überfordern, in dem ich mit allem auffahre, was mir aufgefallen ist.

Das nächste dicke Ding ist, dass wiringPi nach meiner Grundlagenforschung als veraltet gilt.

In meinem Beitrag #14 habe ich bereits gefragt, wie die Funktionen zu einem Ende kommen sollen, die in den Threads aufgerufen werden. Konkret sind die Funktionen "Einlesen" und "ventil" gemeint. Ich frage mich, wie der jeweilige join-Aufruf funktioneren soll, wenn die Funktionen nicht zu einem Ende kommen. Dazu hätte ich gerne mal eine Erklärung.

Quote from peuler

... auch den Compiler-Aufruf posten. ...

__blackjack__ : Der Screenshot ist nur dann in einer vernünftigen Größe zu sehen, wenn man sich eingeloggt hat. Von daher hast Du recht. Aber auf die Idee muss man erst einmal kommen, dass eine Vorschau auf das Bild davon abhängt, ob man als User in diesem Forum eingeloggt ist oder nicht.

Habe den Spoiler aufgemacht und erkenne rein garnichts. Der Screenshot ist viel zu klein.

Bitte stets den gesamten Quelltext und auch den Compiler-Aufruf posten. Mit gekürzten Versionen mag ich mich nicht beschäftigen.

Zum Beitrag # 11:

Der Quelltext hat aus meiner Sicht mindestens 1 Designfehler:

Die Funktionen laufen alle in einer Endlosschleife: while(1) kommt nie zu einem Ende. Das hat zur Konsequenz, dass bei einem Abbruch des Threads dieser in einem undefiniertem Zustand endet. Besser wäre es, eine Bedingung zu definieren, die die Funktion ordentlich beenden lässt (die im Thread ausgeführt wird) und damit auch den Thread ordnungsgemäß zu einem Ende kommen lässt. Ich frage mich, wie die join-Aufrufe funktionieren sollen, weil die in den Threads aufgerufenen Funktionen nicht enden.

Ich bin kein Freund von Definitionen von namespaces. Meine bescheidene Erfahrung mit C++ hat ergeben, dass man besser versteht, was man tut, wenn man darauf verzichtet.

Zu der Frage nach der maximalen Anzahl von Threads hilft vielleicht das Programm tell_max_threads.cpp weiter. Eine kleine Doku ist hier zu finden.

Auf einem Raspberry Pi 2 bin ich auf über 200 Threads gekommen. An der Anzahl der Threads wird das Vorhaben wohl kaum scheitern.

Eine Schachengine ist ziemlich rechenintensiv. Ich würde klar zu einem Lüfter raten. Ob das allerdings Spaß macht, wage ich etwas zu bezweifeln, denn der Raspberry ist auch in Version 5 kein Rechenmonster. Als Alternative würde ich empfehlen, die x86-Version des Raspberry Pi Desktop in einer virtuellen Maschine zu nutzen, weil es keine Investition in Hardware bedeutet.

Kannst Du eine Tastatur und Bildschirm anschließen? Damit könntest Du prüfen, ob nur die Netzwerkschicht nicht mehr will. Und Du könntest im Falle eines Falles den Pi ordnungsgemäß herunterfahren.

Irgendwie erinnert mich die Aufgabenstellung an eine Filmszene aus Star Wars Episode 4: R2D2 fährt seinen kleinen Arm aus, um mit dem Boardcomputer in Kontakt zu kommen. Na, das hilft jetzt nicht wirklich weiter.

Zu dem Thema mit dem Schrittmotor fällt mir dies auf: Der Schalter hat bestimmt so etwas wie Raster, damit die Schalterposition sich nicht ohne weiteres ändert. Und da frage ich mich, wie man es erreichen will, dass der Motor gegen die Rasterstellung arbeiten soll. Vielleicht kann man 'irgendwie' das Rasterproblem lösen, damit die Steuerung für den Motor etwas einfacher wird.