C++ fstream GPIO Trigger/Interrupt

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

[NumberFive]

Ok jetzt müsste man definieren wo Lib und so anfängt und aufhört Natürlich wäre es falsch bzw komisch wenn jetzt zur Lib noch eine Konfig gibt. Da gehört es in den Lib aufruf. Ich hatte schon gedacht das das Nutzende Programm die werte weiter gibt. Schluss endlich sieht man das ja auch am Construtor deiner/meiner Klasse das hier der Pfad übergeben wird. Aber hier jetzt auch noch über "gutes" Design einer API zu Diskutieren wird Interessant den auch da gibt es nicht nur eine Meinung.

https://stackoverflow.com/questions/...ocess-on-linux
Damit habe ich neben top die CPU Last an gesehen und was soll ich sagen nichts ergo kein Dummer drin.

Zum Thema LED Test:
Mein Problem ist die LED's die da sind habe ich keine Werte zu, den das war so ein Alles Drin pack von Vilros den ich mal zu Weihnachten geschenkt bekommen habe. Ergo kann ich den Vorwiederstand nicht ausrechnen an 5V. 5V Deshalb da ist ein TBD62083A zwischen PIN und Lüfter. Klar ich könnte jetzt wieder alles auseinander bauen und die LED am Pin direkt betreiben aber auch dann müsste ich nicht was das für eine LED ist.
Meine Elektronik Sammlung ist im Moment sehr bescheiden da ich lange nichts mehr gemacht habe und vor Jahren mal aussortiert habe weil habe ja eh keine Zeit...
Das ich noch mal Anfange hätte ich so nicht gedacht. Wollte ja nur mal eben eine CarPC bauen mit Standardteilen und jetzt sitze ich da und mache Unteranderem das hier und Controller Software (ATMega) fürs Netzteil.

[HaWe]

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.

da gebe ich dir völlig Recht -
nur leider wird C/C++ ja überhaupt nicht von der raspberrypi.org supportet, sondern, erbärmlicherweise, ausschließlich Python (sogar Adafruit bietet für seine Produkte nur Python Treiber für den Pi an, keine in C/C++, obwohl sie für Arduinos vorhanden sind)
- alles andere sind libs und Tools von ± Privatnutzern, die hier etwas für die Community zur Vereinfachung bereit gestellt haben
(und GPIO-Steuerung samt deren dev trees ist ja auch nichts, was irgend etwas mit dem "normierten" C seit Kernighan und Ritchie oder Stroustrups C++ zu tun hat.)

[alexander_ro]

LED sind sehr ähnlich den größten Unterschied macht die Farbe. Da muss man nicht wirklich wissen was es genau für eine ist. Im Netz gibt es LED Rechner da wählt man die Farbe aus und bekommt brauchbare Werte vorgegeben. Man kann ja dann zur Sicherheit immer noch mit einem bisschen größeren Widerstand zum testen anfangen. Ein Labornetzgerät wäre da hilfreich aber nicht unbedingt nötig.
https://www.elektronik-kompendium.de...au/1109111.htm

Bibliotheken sind meist leicht zu erkennen weil sie eher allgemein gültige Dinge zur Verfügung stellen. Anwendungen sind dann die Teile die ein Bestimmtes Problem für den User lösen. Also eher spezielle Dinge. Aber ich sehe jetzt kein Problem warum ein Bibliothek keine Schnittstelle anbieten sollte um Konfig Dateien zu lesen. Logisch die sollte dann die Anwendung benutzen und wie Du schon meintest z.B. per Konstruktor an die Bibliothek übergeben. Aber mit der Bibliothek gelieferte Programm Beispiele könnten dann auch gleich ein Muster Config für die unterstützten Platinen auch anbieten.

Arduino C/C++ kann man aber gut als Beispiel benutzen um dann eine Version für den Raspi zu schreiben. GPIO ist auf jeder mit Linux laufenden Platine eigentlich nur ein Filesystem Zugriff. Abgesehen von den Namen der Devicefiles ist das auf allem mit Linux Kernel der gleiche Ablauf. C++ hat seit C++17 auch die Möglichkeit auf das Filesystem zuzugreifen. Mit fstream konnten ja Dateien schon immer gelesen und geschrieben werden. fstream kann man auch für die Zugriff auf Devicefiles benutzen.
https://en.cppreference.com/w/cpp/experimental/fs

Ich habe jetzt für meine I2C Klasse erst mal noch die Log Klasse fertig gebaut. Man muss jetzt zuerst ein Log Objekt erzeugen und beim Konstruktor der I2C Klasse mit übergeben. Je nachdem welche der Log Klassen man erzeugt ist dann das Log Ziel die Standard Ausgabe, eine Datei oder Syslog. Eine LogNoLog Klasse entfernt soweit möglich den Code aus der Klasse. Das erledigt die Optimierung des Compilers muss man natürlich dem Compiler sagen das er Optimieren soll.
https://git.hts-software.de/cgit.cgi...a-Api/tree/Log
https://git.hts-software.de/cgit.cgi...a-Api/tree/I2c

[HaWe]

Arduino C/C++ kann man aber gut als Beispiel benutzen um dann eine Version für den Raspi zu schreiben. GPIO ist auf jeder mit Linux laufenden Platine eigentlich nur ein Filesystem Zugriff. Abgesehen von den Namen der Devicefiles ist das auf allem mit Linux Kernel der gleiche Ablauf.

Arduino C++ lässt sich schlecht als Vorlage zu Linux C++ libs benutzen, da die Arduino-Libs zu viele spezielle Arduino-Funktionen benutzen (i2c, UART, SPI, avrgcc, Arduino String, kein File system etc.) - das Umschreiben können nur Könner, ich z.B. nicht. Selbst wiringPi funktioniert völlig anders als Arduino Wiring. Aber manche Könner haben tatsächlich portierte Versionen geschrieben, ohne dass ich die aber auch nur annähernd verstehe.

[alexander_ro]

Ich glaube Du stellst Dir das schwerer vor als es ist. Das schwierige ist die Hardware Programmierung die erledigt aber der Kernel für Dich. Um ein I2C, SPI oder UART zu verwenden musst Du nicht wie bei Arduino (ohne Lib) in Hardware Registern herum schreiben das erledigt ja bereits der Kernel für Dich. Du musst nur das Devicefile öffnen und dann die Daten zu dem an der jeweiligen Schnittstelle hängendem Geräte schreiben. Ich vermute mal Du hast schon unter Linux Text in eine Datei geschrieben. Mit den Hardware Schnittstellen geht es genauso nur das der Text nicht auf der Platte oder SD-Karte landet sondern über die Schnittstelle beim angeschlossenem Gerät.

Das interessante in einem Treiber für einen I2C Chip wo z.B. nur ein Arduino C++ Treiber vorhanden ist ist nicht das wie die Daten über die I2C Schnittstelle kommen sondern welche Daten der zum Beispiel für eine Porterweiterung dem Chip sendet um den Port als Ausgang zu benutzen und ein-/ausschalten. Das kann man mit ein bisschen suchen schon herausfinden.

[HaWe]

Ich glaube Du stellst Dir das schwerer vor als es ist. Das schwierige ist die Hardware Programmierung die erledigt aber der Kernel für Dich. Um ein I2C, SPI oder UART zu verwenden musst Du nicht wie bei Arduino (ohne Lib) in Hardware Registern herum schreiben das erledigt ja bereits der Kernel für Dich. Du musst nur das Devicefile öffnen und dann die Daten zu dem an der jeweiligen Schnittstelle hängendem Geräte schreiben. Ich vermute mal Du hast schon unter Linux Text in eine Datei geschrieben. Mit den Hardware Schnittstellen geht es genauso nur das der Text nicht auf der Platte oder SD-Karte landet sondern über die Schnittstelle beim angeschlossenem Gerät.

Das interessante in einem Treiber für einen I2C Chip wo z.B. nur ein Arduino C++ Treiber vorhanden ist ist nicht das wie die Daten über die I2C Schnittstelle kommen sondern welche Daten der zum Beispiel für eine Porterweiterung dem Chip sendet um den Port als Ausgang zu benutzen und ein-/ausschalten. Das kann man mit ein bisschen suchen schon herausfinden.

haha, naja, wenn du meinst...
Die Erfahrung zeigt, dass es die wenigsten hinkriegen, die so was brauchen...
ich werde dich mal ansprechen, wenn ich wieder mal einen Raspi Driver für ein Gerät suche, für das es nur Arduino Driver Libs gibt

[NumberFive]

Ich habe jetzt für meine I2C Klasse erst mal noch die Log Klasse fertig gebaut. Man muss jetzt zuerst ein Log Objekt erzeugen und beim Konstruktor der I2C Klasse mit übergeben. Je nachdem welche der Log Klassen man erzeugt ist dann das Log Ziel die Standard Ausgabe, eine Datei oder Syslog. Eine LogNoLog Klasse entfernt soweit möglich den Code aus der Klasse. Das erledigt die Optimierung des Compilers muss man natürlich dem Compiler sagen das er Optimieren soll.
https://git.hts-software.de/cgit.cgi...a-Api/tree/Log
https://git.hts-software.de/cgit.cgi...a-Api/tree/I2c

Die Idee hier einen Logger zu übergeben ist ja super aber warum benutzt du eigene Loglevels ? Und nicht die die jeder Kennt Ok security kann ich mir noch ganz gut vorstellen das man das brauchen könnte.
Ich bleibe bei https://github.com/muflihun/easyloggingpp das Funktioniert für mich ausreichend und hat auch die Möglichkeit den Logger an eine so / dll weiter zu geben.

    START_EASYLOGGINGPP(argc, argv);
    if(utils::FileExists("loggerback.conf")) {
        // Load configuration from file
        el::Configurations conf("loggerback.conf");
        // Now all the loggers will use configuration from file and new loggers
        el::Loggers::setDefaultConfigurations(conf, true);
    }

Und auch eine Möglichkeit eine Config als Datei zu übergeben. Also das was für eine Lib angesprochen wurde.
Das überall ein TestModul gibt finde ich ja super hast du dich mal mit UnitTest beschäftigt das ist was ich unbedingt noch machen will aber in C++ ist das nicht ganz so Easy wie mit C# und Windows.
Ich will die dann auch gleicht mit dem CMake script laufen lassen. Aber bis dahin ist noch ein weiter weg. Auch ein Build Server wäre Cool.

Aber jetzt erstmal auf Funktion Programmieren. Im Auto habe ich der Zeit nur ein Loch das auch nicht so doole.
Wenn ihr Lust auf Device Treiber habt:
https://www.adafruit.com/product/1983 das Fliegt hier noch rum ich hätte es gerne als "PiTFT as Raw Framebuffer Device" die Touch Funktion ist nicht unbedingt notwendig. Als Routen anzeige direkt vorm Lenkrad. Leider bekomme ich nichts zu sehen auf dem Display. Und müsste auch wissen welche Pins gebraucht werden den das man es auf Stecken kann nutzt mir gar nichts da ich es ja absetzen will.

Ja Träume habe ich viele aber so wenig Zeit und alleine ist es schon ein Monster Projekt.

[alexander_ro]

Ich kann schon helfen so einen Treiber um zu bauen aber ich mache das aber nicht alleine. Da muss der betreffende schon mit machen ...

Nur der Security ist ein eigener Loglevel die anderen benutzt der syslog. https://de.wikipedia.org/wiki/Syslog
Ich habe nur viel weniger davon als der Syslog. Man kann die aber ja relativ leicht noch ändern. Ich werde mal schauen wie ich mit denen zurecht komme.

Das geht zwar Richtung Unittest was ich da gemacht habe ist aber nur eine einfache Art weil mir jede Menge nötige Testfälle fehlen. Eigentlich habe ich das gemacht das jemand der so eine Klasse verwenden will zumindest einfache Beispiel hat wie das von mir gedacht war.

Da Du ein Debian als Basissystem hast würde ich an Deiner stelle Debian Pakete machen. Das was Du da für einen Build Server brauchst ist schon vom Debian Projekt gemacht worden.

Ich benutze das Orginal Raspi Touch Display. Darauf kann man mit OpenGL sogar 3D-Grafik ausgeben. Es belegt auch kaum zusätzliche Ports da es den eigenen Display Anschluß der Raspi benutzt (nicht den HDMI den anderen). Ein weiterer großer Vorteil ist das es ohne jede weitere Programmierung alles kann was man braucht. Ich benutze mit meinem noch eine Bluetooth Tastatur mit Touchpad. Dann kann man mit dem arbeiten wie mit einem normalem Computer. Sehr praktisch das ist ...
Wegen der OpenGL Ausgabe habe ich auch schon mal ein Beispiel Programmiert. Es kann nicht viel Rendert nur Text auf einer Fläche und kann Tastatur eingaben lesen. Das Programm kann man aber nicht Innerhalb einer anderen Grafischen Oberfläche starten. Man muss vom Desktop mit strg + alt + f1 zu einem Terminal wechseln und es da starten.
https://git.hts-software.de/cgit.cgi...a-Grafik/tree/

Ich schau mir das an mit dem Display von Dir aber das was Du willst geht nicht mit allen Displays.
<Edit>
Das Display ist doch für einen Raspberry gemacht. Wenn Du es an einer anderen stelle haben willst kannst Du es ja mit Kabel verbinden. Schaltplan gibt es soch auch dafür. Dort müsste stehen welche Ports benutzt werden.
</Edit>

[NumberFive]

Ich glaube du hast mich nicht richtig verstanden.

Wäre mir neu das Raspberry Display und HDMI gleichzeitig gehen. Open GL kommt ja von Graphik Chip und davon hat der PI nur einen. Ich will aber zwei Displays das kleine und das Große per HDMI. Wenn du den Schaltplan so gut verstanden hast kannst du mir ja sagen welche Pins ich brauche das "nur" das Display angeschlossen ist und die Hintergrund Beleuchtung. Tasten und Touch brauche ich nicht.

Da das aber nur ein nettes gimik ist muss das wohl warten. Wahrscheinlich passt das mit den anderen Sachen am GPIO eh nicht zusammen und muss neu gedacht werden. Ich brauche ja auch ein Paar für andere Dinge Drehgeber, I²C für die Relais, Serial für Netzteil. Ich habe schon Displays für den I²C gesehen vielleicht ist das ein weg. Aber da ist es ja auch nicht mit dem Display alleine getan da braucht man ja auch ein paar Chips drum rum.

https://github.com/adafruit/Adafruit_STMPE610
Wenn ich das richtig deute hat das Ding zwei Schnittstellen SPI und I²C
https://github.com/adafruit/Adafruit_ILI9341
Das müsste der Display Teil sein


Ich glaube nicht das es so einfach ist als Debian Packet auf genommen zu werden um dann die Infrastruktur mit nutzen zu können. Dafür ist das Zeugs viel zu unfertig. Wo ich noch keine Zeit für hatte sind die ganzen Public Build server die Nutzen kann vielleicht ist ja da was passendes dabei.

Bitbucket Pipelines ist auch so was und da da das Repos liegt sollte ich mir das ansehen aber 50 Minuten pro Monat sind halt auch schnell auf gebraucht.