C++ fstream GPIO Trigger/Interrupt

Ich habe einen HDMI Splitter mit Analog Ausgang das war für mich die Beste Lösung wenn es auch nicht gerade Billig war. Ich halte von den USB Soundkarten nicht viel. Per Splitter habe ich laut Datenblatt auch 5:1 aber in Realität habe ich es noch nicht zum Laufen bekommen (5:1) 2:1 geht. Der Splitter mach 48Khz bei 24Bit und das hört man dann schon. Natürlich nicht bei einer einfachen MP3 Datei.

Der Amtel steckt auf einer eigenen Platine ist kein Arduino und wenn ich einen 10KOhm Wiederstand in die RX Leitung geht alles wie gewünscht muss also noch suchen wo der Strom falsch abbiegt.

Denk dran der Arduino hat 5V am i²c und der PI 3,3 V aber das hast du sicher auf dem Schirm. Ich brauch das I²C für den MCP23017 damit ich Relais später schalten kann.

Wenn ich was habe werde ich es hier Posten.

Ich habe jetzt mal bei wiringPi und bei pigpio gelesen und wenn ich mir da das Thema Hardware PWM so durch lese gibt es wohl dann mit der ein oder anderen Zusatzhardware Probleme. Da ich aber nicht möchte das mein Prg zu viele Einschränkungen macht. Werde ich wohl eher auf Software PWM setzen müssen. Ich brauche das ja auch "nur" für den Lüfter da ist ein sauberes PWM nicht so wichtig Hauptsache ist das der Lüfter nicht immer voll dreht weil dann ist laut. Mal sehen ob ich das Ressourcen schonend hin bekomme.

Zitat:

---

Zitat von NumberFive

Ich habe jetzt mal bei wiringPi und bei pigpio gelesen und wenn ich mir da das Thema Hardware PWM so durch lese gibt es wohl dann mit der ein oder anderen Zusatzhardware Probleme. Da ich aber nicht möchte das mein Prg zu viele Einschränkungen macht. Werde ich wohl eher auf Software PWM setzen müssen. Ich brauche das ja auch "nur" für den Lüfter da ist ein sauberes PWM nicht so wichtig Hauptsache ist das der Lüfter nicht immer voll dreht weil dann ist laut. Mal sehen ob ich das Ressourcen schonend hin bekomme.

---

Stimmt, wiringPi und pigpio sind ja nur Wrapper um die "eingebauten" BCM-Funktionen für Hardware PWM, machen also beide nichts "neues". Für Software-pwm nutzt wiringPi nur POSIX pthread, kein C++ std::thread (wiringPi nutzt niemals C++ Funktionen, ausschließlich ANSI C).
Auch für I2C nutzt wiringPi nur Wrapper um BCM-Funktionen.

wiringPi sagt ja ganz klar das es C ist und sein will ergo ist es richtig so das es kein std::thread benutzt.

Wobei zu mindestens bei Debian mit g++ zur zeit std::thread das selbe ist wie pthread. Klar wenn sich das ändert muss man den Code nicht anpassen.

Beide Libs mach schon ein bisschen mehr als nur die BCM Funktionen zu Wrappen zum Beispiel das die PIN's immer die selbe Nummer habe. was bei der Implementierung hier nicht so ist Ergo muss man immer genau wissen was für ein PI das gerade ist.

so auf die schnell mal zwei klassen zusammen gehämmert auch mehr C als C++. Aber mein mcp23017 reagiert und schaltet die LED an und aus.

Oh das neue Forum ist schon zäh in der Benutzung. Angehängte Dateien darf ich nun scheinbar nicht mehr lesen ... :( und die Benachrichtigung über neue Beiträge ging auch nicht mehr.
<edit>Das alte Forum gibt es ja noch da darf ich auch die Datei herunterladen ... :)</edit>

Ich habe jetzt mal meine alte Klasse aufgeteilt. In die I2C Kommunikation und die Implementierung für die spezielle I2C Hardware wie Sensoren, Porterweiterungen, Wandler, usw.

https://git.hts-software.de/cgit.cgi...a-Api/tree/I2c

Sehr weit bin ich noch nicht gekommen ich hatte mit dem Gentoo Update auf dem Raspberry das Problem das er immer während dem Update abstürzte. Das lag an einer nicht ganz Stabilen Stromversorgung. Irgendwie das Netzteil kaputt gegangen.

Was ich nicht wirklich verstehe ist warum man neue Projekte wie wiringPi mit total veralteter Software Architektur überhaupt anfängt. Die Software Branche Programmiert noch wie vor 30 Jahren und Wundert sich das nichts vorangeht. Wegen den Ports noch also meine Pis haben unter Linux immer die gleichen Nummern. Nur zwischen verschiedenen Platinen weicht das ab. Also z.B. Gnublin und Raspi was aber normal ist un kaum zu verhindern.

also ich glaube jetzt verwechselt du was ja ich kann deine Kritik absolut folgen das was den C11 und C14 Standard bringt wir durch den C# hyp voll kommen übersehen. Auch das Thema Energie Effizienzen ich meine damit um das selbe zu Tun muss ich immer mehr Energie rein stecken weil Programmierer sich nicht die Finger schmutzig machen wohlen. Der GC der absolute Performens Killer.

Aber so was wie wiringPi in C zu schreiben macht schon sind gerade vor dem Hintergrund das bei Embedded systemen nicht immer der C++ Support geben ist C immer da ich ja einen Kernel bauen muss. Ok die ganz harten schreiben den auch in Assembler aber da bin ich dann raus.

https://www.codeproject.com/Articles...th-the-Pi-part

Das letztere zum PI glaube ich nicht so ganz den der PI hat mehr als ein Layout und da Ändern sich sehr wohl die Pin nummern je nach Revision der Platine.

https://github.com/DerKleinePunk/TryGPIOWithPI

Weil mir der Speicher zum Hochladen ausgeht und wenn es Problem bei Download gibt ist so vielleicht besser. Ich hoffe das für dich Ok sonst lösche ich das wieder kein Ding.

Das Forum scheint wirklich mit den Ur-Accounts Probleme zu haben ich fliege auch relativ häufig raus das nervig daran dann sind die Text weg.

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.

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.

Zitat:

---

Zitat von HaWe

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

Code:

---

  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);

---