Beiträge von peuler

    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 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.

    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.

    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.

    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.

    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.