C++ fstream GPIO Trigger/Interrupt

[alexander_ro]

Stimmt schon das der Kernel in C geschrieben wird. Soll das nun heißen das deshalb jeder der unter Linux Software schreibt das auch in C tun muss?

Das ich es nicht mache wegen der Performance habe ich ja vorher schon mal geschrieben. Ich will ein C++ Objekt haben das die GPIO Funktionen steuert. Klar kann ich ein Objekt um die WiringPi basteln aber Zwiebel Software ist auch nicht so mein Ding wenn ich nicht muss versuche ich zu vermeiden das ich eine Schicht um die nächste Hülle.

In dem Raspiforum finde ich auch nur poll dafür. Die werden nicht anders reagieren als hier und nicht beim Problem helfen wollen sondern mir einreden wollen das ich es machen soll wie es alle machen.

[HaWe]

Stimmt schon das der Kernel in C geschrieben wird. Soll das nun heißen das deshalb jeder der unter Linux Software schreibt das auch in C tun muss?
...
In dem Raspiforum finde ich auch nur poll dafür. Die werden nicht anders reagieren als hier und nicht beim Problem helfen wollen sondern mir einreden wollen das ich es machen soll wie es alle machen.

nein, ich meinte damit nur: wenn der kernel mit Funktionen auf GPIOs zugreift, die über ein C-Programm programmiert wurden, dann spricht sicher nichts dagegen, dafür ebenfalls eingebundene C-Funktionen als Subset von C++ mit wrappern zu verwenden.
Ich habe auch nicht gemeint, dass dafür auch schon Lösungen im Raspiforum präsentiert wurden, sondern dass du möglicherweise sehr gute neue Vorschläge bekommen wirst, falls du dein Problem dort neu postest, denn dort sind ja sehr viele extrem versierte C(++) Programmierer unterwegs, die auch die speziellen Raspi-GPIO-Funktionen sehr gut kennen.

[shedepe]

Auch wenn ich sonst nicht so häufig HaWe zustimme muss ich ihm doch diesmal Recht geben, wenn vllt auch aus anderen Gründen.

Nun fangen wir zum Einen damit an wie man unter Linux mit dem Kernel interagieren kann: Zum Einen kann man einen Syscall machen. Das sind bestimmte Funktionen die Daten in den Kernel, bzw. daraus bewegen und auf Kernelebene irgendetwas damit machen. Zum anderen kann man auch das Dateisystem unter /proc lesen und schreiben -> Das ruft im Hintergrund aber auch nur irgendwo wieder ein paar tolle Funktionen auf.

Zum Anderen du nennst es Zwiebelsoftware, andere Leute nennen das einen guten Stil der Softwareentwicklung wenn man ein bestehendes Interface kapselt um es seinen Ansprüchen anzupassen. Weil man verhindert damit den tpyischen "Reinvent the wheel" Effekt (http://dl.acm.org/citation.cfm?id=554798 - Gibt es sogar Veröffentlichungen dazu und spart sich eine Menge arbeit. Gibt sogar mindestens ein Softwarepattern dass sich damit beschäftigt (z.B: der Adapter oder der Wrapper). Falls dich das immer noch nicht überzeugt, seeehr viel Software die man irgendwo antrifft am PC basiert darauf dass man zum einen ein einfach C Interface entwickelt hat und dann in der Sprache seiner Wahl ein Frontend drauf gesetzt hat (Was glaubst du wie die ganzen managed Sprachen C# / Java usw. implementiert sind).

Und ein letzter Grund noch warum es durchaus Sinn mach das C interface zu wrappen. Du hast ja inzwischen vllt festgestellt, dass es zwei verschiedene Methoden gibt die GPIOs anzusteuern. Wenn du deinen Wrapper sauber baust, kannst du mit einer Zeile Code auswählen ob du die eine (wiringPi) oder die andere (pigpio) verwenden willst, ohne dass deine SOftware ein anderes Interface verwenden müsste.

Mein Einschätzung dazu ist, dass es wesentlich unsauberer ist Dateisystem zugriffe zu wrappen als bestehenden C Code.

[HaWe]

ich meinte das mit den C++ wrappern um C Funktionen herum auch so wie shedepe es schrieb, wenngleich er es auch deutlich präziser formuliert hat.
Ich vergaß allerdings oben zu erwähnen, dass ich wiringPi gerade deswegen auch gern verwende, weil es einerseits einen fd beim öffnen zurückgibt (anstatt einen FILE* handle) und außerdem intern immer berücksichtigt, um welche Art von files es sich handelt, auf die man zugreift - inkl. Sonder-Routinen z.B. für serielle Kommunikation, u.a. wenn es um Besonderheiten wie Puffer etc. geht: ich kann mich dunkel erinnern, dass diese Tatsache auch im Raspberrypi.org C++ Forum das ein oder andere Mal diskutiert wurde.
(Nur zur Vervollständigung, auch wenn es nicht direkt zur Lösung des TOP-Problems führt)

[alexander_ro]

Das Problem an dem Raspiforum ist auch noch das die immer in so einer unverständlichen Sprache schreiben ...
Englisch ist nicht so meine Sache ... wie ich immer sage: Fremdsprachen sind mir genau das ... Fremd ...

Euer erster Vorschlag war ja: (Mein C++) + (Wiring Pi oder was auch immer) + (Kernel/C API) = Zwiebel
Euer jetziger Vorschlag: (Mein C++) + (Kernel/C API) = (gute Software )

Standard C++ Objekte in eigenen Objekten zu benutzen ist jetzt sicher keine Unsaubere Programmierung. Datei System Zugriffe aus Standard C++ Objekten sind Plattformunabhängig und damit in jedem Fall WiringPi oder was auch immer vorzuziehen. Standard C Funktionen oder C++ Objekte sind aus diesem Grund immer wenn es geht zu bevorzugen.

Nichts destotrotz war ich ja der Meinung das das fstream das kann ich es nur nicht gefunden habe. Das klären zu wollen ob es ein Standard Objekt nicht kann was ich brauche halte ich durchaus für Sinnvoll. Damit tue ich ja was jeder sagt ich Versuche das Rad nicht neu zu erfinden und Standard Objekte zu benutzen.

Die Muster Mania ist nicht so mein Ding nur weil jeder Sklavisch nach Mustern schreit und ohne Sinn und Verstand oft auch da verwendet wo die nicht dafür taugen ist es noch lange keine gute Software. Wrapper gab es schon sehr lange vor den Chaoten mit dem Muster Tick. Die schreiben sich zwar deren Erfindung auf die Fahnen aber die Konzepte waren alle schon vorher erfunden. Soweit ich weiß haben das ja die Ami erfunden für die ist es auch nichts neues das die alles Klauen und einen neuen Namen drauf kleben und es als ihr Geistiges Eigentum verkaufen. Trotzdem alles nur geklaut ...

[HaWe]

ich persönlich meinte:
du verwendest nur wiringPi für GPIOs und fileIO, wenn es dir nicht auf Performance ankommt, und ggf. pigpio zusätzlich, falls es dir um eine höhere Performance geht. Beide Libs nutzen native C Funktionen bereits in ihrem Rahmen optimal, und man muss IMO gar keine weiteren nativen und/oder Kernel Funktionen selber heranziehen. Die wiringPi/pigpio Funktionen können dann über OOP Methoden in die Klassen/Objekte eingebunden werden. Ob das so richtig formuliert ist und ob shedepe das ggf auch so oder anders meinte, weiß ich nicht.

[alexander_ro]

Das hatte ich schon so verstanden und das ist auch richtig so. Nur warum sollte ich nicht gleich die C-Funktionen benutzen in meinen eigenen C++ Objekten?
Von der Performance reicht mir im Moment der Zugriff über das Filesystem.

Die C Funktionen sind ja Standard libc. Wenn ich die benutze laufen meine eigenen C++ Objekte auf allen Platinchen die ein Linux/UNIX als OS verwenden (z.B. Gnublin). Ich habe es jetzt nicht überprüft aber ich vermute mal das WiringPi nicht auf jedem Linux Platinchen läuft sondern auf die besondere Hardware des Raspberry zugeschnitten ist. Wäre doch für meine C++ Objekte das bessere Konzept wenn die auch auf != Raspberry auch laufen würden?

Das was ich Probiert habe mit dem fstream geht nur so weit wie ich es schon habe zum Port aus und ein schalten. Das mit den Triggern scheint so nicht mehr machbar zu sein was ich schade finde aber gut kann man nicht ändern.

[NumberFive]

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.

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