C++ fstream GPIO Trigger/Interrupt

[alexander_ro]

Die ganzen Aufsteckplatinchen wären nicht austauschbar wenn es nicht die gleichen Pins wären. Es ist doch gerade die Kompatibilität zwischen den Raspi die den so beliebt machen. Man darf nur nicht verwechseln das die Benennung der Devicefiles manche Linux Distributionen anderes machen als andere. Das sollte eine Bibliothek aber auch nicht verstecken. Es ist nicht gut Sachen in einer Lib zu lösen die nicht allgemeingültig gelöst werden können. Ich habe drei verschiedene Layout die sind kompatibel und da unten steht auch meine PIs.

Wenn es keinen C und C++ Compiler zu einer CPU gibt würde ich die erst gar nicht einsetzten. Das wiringPI wurde für den Pi gemacht bei mir kann der ein Gentoo selber Compilieren da gibt es C und C++ in großen Mengen. Gut da dauert einen llvm zu übersetzen schon mal 48 Stunden aber es geht. Ich kann nun nicht erkennen warum man dann eine Bibliothek nicht in C++ schreiben sollte. wiringPi wurde für eine Rechnerklasse geschrieben die nicht wirklich in das Genre Embedded passt. Somit auch nicht die Einschränkungen hat die vielleicht ein Atmega8 hat. Daher macht es keinen Sinn eine Software Architektur neu zu bauen die im letzten Jahrtausend schon als veraltet galt.

Performance ist sicher auch wichtig aber als erstes sollte die Fehlervermeidung und die Sicherheit einer Software stehen und bei beidem hilft eine Modere Software Architektur. Auch ist es schlicht nicht wahr das C++ Software langsamer ist als C. Die Lüge wurde von C Programmieren verbreitet die C++ nie verstanden hatten und damit versuchten zu Programmieren. Klar schlecht geschriebene C++ Software ist langsam aber schlecht geschriebener C Code ist auch langsam. Momentan ist der Compiler nicht das Problem der Software Branche. Die müssen erst einmal lernen wie man Moderne Architekturen baut sicher und möglichst Fehlerfrei. Ich weiß schon das meine Meinung zum Thema nicht unbedingt bei jedem beliebt ist aber irgendwie gibt es zwar immer mehr Rechenleistung in den Geräten ohne das die einen brauchbaren Nutzen hat. Palm hatte mal eine Handschrifterkennung mit extrem wenig Rechenleistung umgesetzt. Heute hat man sehr viel mehr Rechenleistung in den Mobilen Geräten aber Handschrifterkennung ist praktisch nicht vorhanden. Man tippt auf einer Bildschirmtastatur die nicht mal so intelligent ist das sie sich an den User anpasst und schlecht getroffene Tipper korrigiert. Die meisten Menschen Tippen auf Touch recht konstant daneben was am Blickwinkel liegt. Bei Spracherkennung die bei Heutigen Rechenleistungen das Telefon erledigen kann wird aber die gesamte Sprache zum Google, Apple oder Amazon übertragen um diese auszuwerten. Die Liste kann man noch lange machen was alles auf Geräten ginge aber nicht gemacht wird weil die Betriebssystemhersteller die Rechenleistung lieber in Systeminternen ... was weiß ich ... versacken lassen als dem Kunden einen Mehrwert zu bieten.

Ist ja OpenSource daher darf man ja ändern und weiter veröffentlichen. Ja das mit github ist so Ok. Ist da dann so leichter einen Überblick zu behalten und man kann die Änderungen besser verfolgen.

[HaWe]

es gab im Lauf der Zeit vom Pi A bis zum Pi3 B+ durchaus mal Umbenennungen bzw. Vertauschungen der GPIO Nummern.
wiringPi kann die GPIOs automatisch um-mappen, per eigener konstanter wiringPi Nummerierung, bei den BCM Nummern und den physikalischen muss man tatsächlich selber aufpassen - dessen Autor Gordon Henderson hat sich irgendwann dazu im raspi.org Forum geäußert, als die 3 verschiedenen Nummerierungstypen diskutiert wurden.
Seit dem B+ layout hat sich aber dann bei den GPIO-Nummern nichts mehr geändert.

Auch der Jessie device tree wurde irgendwann in 2016 abgeändert, was wiringPi intern berücksichtigt, je nach Raspbian distri.
Der spezielle auf den Pi abgestimmte Raspbian dev tree führt auch dazu, dass z.B. wiringPi auf dem Pi2 nicht auf der Raspi Debian distri ev3dev funktioniert.
Sogar bei UART gab es von Pi2 zu Pi3 eine Änderung, die erst für die GPIO-UART für alle libs per serial0 statt ttyAMA0 ersetzt und dadurch wieder vereinheitlicht und rückwärtskompatibel gemacht wurde - in alten libs muss man das selber patchen.

[alexander_ro]

... - in alten libs muss man das selber patchen.

Genau deshalb sollte man diese Hardware Abhängigkeiten nicht in eine Bibliothek packen. Der Linux Kernel ist hier mit dem Devicetree schon recht modern aufgestellt. Das ist vielleicht für Anwendungen zu aufwändig aber Port Zuordnungen im Code festzulegen ist böösseeee ...
Das ist aber das gute an OpenSource wer das so möchte kann es so tun aber ich kann es anders machen.

Demnach würde wiringPi auf meinem Raspi unter Gentoo so nicht funktionieren. Ein guter Grund mehr warum die Entscheidung es nicht zu benutzen für mich richtig war.

Mit den verschiedenen Version hatte ich dann scheinbar einfach Glück das bei mir alles Kompatibel ist. Ich hatte bisher angenommen es lag daran das die Hardware Entwickler darauf geachtet hätten.

Das folgende ist ein früheres Experiment zu Software PWM. Das will ich noch in eine Klasse verpacken evtl. mit Unterstützung als Software Signal Generator. Dann könnte man Treppenspannungen, Sinus, Dreieck und Rechteck auch erzeugen. Die braucht man zum Entwickeln doch immer wieder mal. Die Frequenzen sind zwar nicht hoch aber die Software Kontrolle hat schon auch ihre Vorteile.

  long timeOn  = 1000;
  long timeOff = 29000;

  auto func = [&] ()
       {
         std::ofstream filePortValue ("/sys/class/gpio/GPIO11/value");

         for (;;)
         {
         // Port ausschalten 
           strConfig = "0";
           filePortValue << strConfig;
           filePortValue.flush ();

         // Zeit für "aus" abwarten
           microSleep (timeOff);

         // Port einschalten
           strConfig = "1";
           filePortValue << strConfig;
           filePortValue.flush ();

         // Zeit für "ein" abwarten
           microSleep (timeOn);
         }

         filePortValue.close ();
       };

  std::thread t1 (func);

[HaWe]

... - in alten libs muss man das selber patchen.

Genau deshalb sollte man diese Hardware Abhängigkeiten nicht in eine Bibliothek packen.

ich meinte es anders:
dir wird gar nichts anderes übrig bleiben, als es ebenso zu machen wie wiriningPi, denn es haben sich ja nun mal die GPIO-Nummern teilweise verändert, und der dev tree ebenfalls für die herausgeführten UART-GPIOs (z.B. der UART "Pfad" /devAMA0 ist ja nicht mehr wie früher auf den GPIOs, sondern wird ab Pi3 intern für BT verwendet - die GPIO UART heißen jetzt anders). wiringPi als lib prüft ja intern automatisch auf die aktuelle Hardware und die OS-Version, und kmpiliert dann entspr. abhängig.
Auch I2C0 und I2C1 haben eine Änderung erfahren von Pi A bis hin zum B+ design.
Wenn du also für verschiedene Pi-Plattformen kompilierst, muss du irgendwo in deinem Code die boardabhängigen dev Pfade reinschreiben, einmal so, und einmal so. Und für andere Plattformen wie BPi oder BBB oder gar Linux-PCs ebenso, erst recht.

[alexander_ro]

Die SD-Karten sind von Samsung und haben damit kein Problem. Für große Sachen ist der Raspi beim compilieren schon ein bisschen langsam. Würde man große Programme darauf Entwickeln ist das Störend aber so nicht der macht das ja alleine muss ich nicht darauf warten.

Ja man kann ein Smartphone mit 8 Kernen in der Hand halten ohne Brandblasen zu bekommen. Es wird deutlich warm das schon mehr nicht weil die CPU die Notbremse zieht wenn es zu warm wird. Sprache erkennen können die trotzdem. Braucht Strom keine Frage aber man braucht die ja nicht andauernd. Wäre aber immer noch besser als das ganze Leben an Ami Konzerne zu streamen.

Software PWM kann man vielleicht leichter Testen wenn man eine LED an den Port klemmt. Ich glaube Mensch erkennt Helligkeitsunterschiede leichter als Drehzahlunterschiede. Kann auch sein das die Frequenz für einen Motor zu hoch ist. Du musst ja drei Sachen einstellen die Grundfrequenz und das Tastverhältnis also ton/toff. Bei Software PWM stellt man das alles halt mit den Wartezeiten ein. Bei Hardware PWM wird die Frequenz ja aus dem Takt und dem gewählten Teileverhältnis eingestellt. Motore haben mit zu hohen Frequenzen Problem wegen der hohen Mechanischen Trägheit.

[NumberFive]

Zum Thema dev Pfade man kann es auch einfach in die Konfig packen für mich hat das nichts im Code zu suchen. Klar der Benutzer muss ein Gewisses Technisches Verständnis dann mit bringen aber mit Sample Config sollte es klappen. Warum sollte ich jemanden vorschreiben das die GPS Mouse an /dev/AMA0 hängen muss. Er könnte auch eine USB benutzen und dann heißt der Dev port anders.

Das mit der LED muss ich mal überlegen Thema ist halt die Belastung vom PIN.
Warum drei Werte vom PWM ja es sind 3 das richtig aber ich brauche ja nur 2 der Dritte ergibt sich immer. Mein source mach es so: Hz und ein wert zwischen 1 und 1000 damit stellst du die On Zeit ein in 0.1 % bis 100.0 % wenn ich meine Log Ausgaben trauen kann passt das dann auch. Vielleicht hat ein Bekannter auch mal Zeit würde mich schon Interessieren wie das auf dem OSSI aussieht was ich da mache.

Was ich auf jeden Fall noch ansehen muss ist das Thema CPU last das habe ich ganz vergessen.

[alexander_ro]

Logisch man muss das irgendwo einstellen wo welche Devicefiles zu finden sind. Nur wie schon oben geschrieben darf einem die Bibliothek nicht aufzwingen. Welcher Port, Timer oder Wandler was tut. Das ist Sache der Anwendung nur die kann wissen wie es am besten gemacht werden soll. Um es dem Anwender leichter zu machen kann man ja für alle unterstützten Platinchen eine Beispiel Konfiguration mit dazu geben. Die Bibliothek kann auch der Anwendung eine Funktion zum verarbeiten der Konfig mit liefern. Dann muss der Anwender kaum mehr tun und es ist trotzdem unter seiner Kontrolle welcher Port was tut.

Es ist so merkwürdig Raspi und Co wurden ja in erster Linie für die Ausbildung geschaffen. Das die ganzen Bastler die Dinger in Stückzahlen verbauen die keine Industrie zusammen bekommt war nie vorgesehen. Von dem Standpunkt ist es sogar schlecht wenn die Bibliothek alle Hardware Besonderheiten zu verbergen versucht. Jemand der Lernen will wie das Funktioniert und wie man es Anwendet muss schon mit bekommen wo die Hacken sind sonst ist die Ausbildung nicht vollständig.

Du hast doch einen Lüfter wie auch immer über den Port geschaltet dann kannst Du mit einem entsprechendem Vorwiderstand eine LED statt dem Lüfter anklemmen. Eine kleine Glühlampe aus einer Taschenlampe oder ähnlichem würde am Lüfteranschluss auch funktionieren. Eine LED ist aber mit einem passendem Vorwiderstand normal auch direkt an einem Port kein Problem. Du kannst den Widerstand aber einfach ein bisschen größer wählen dann wird die LED zwar nicht mit maximaler Helligkeit leuchten aber das ist zum testen auch nicht nötig. Sollte man dann halt in nicht zu heller Umgebung machen den Test.

CPU Last ist ja unter Linux leicht zu beobachten mit "top" zum Beispiel.
Die gesamte Last kann man mit "time ls" das zeigt dann vom ls die verbrauchte Rechenzeit an.