C++ fstream GPIO Trigger/Interrupt

[alexander_ro]

WiringPi ist meines Wissens C und eher weniger C++ auch wenn C vollständiger Sprachbestandteil von C++ ist.

Das Rad neu erfinden in dem Sinn würde ich nur wenn ich das in C und Funktionsbasiert machen würde wie eben WiringPi es macht.

Ob man aus dem User Space oder Kernel Space pollt ... der Unterschied könnte nicht größer sein. Wenn stimmt was geschrieben steht ist epoll die schnellste Variante und eine Kernel Schnittstelle. Das ich es jetzt anders zu machen versuche ist nicht unbedingt Performance mein erstes Ziel. Sondern nicht Funktions- sondern Objektorientier programmieren die Klassen leicht anwendbar zu machen und Fehlertoleranz, Fehleranalyse und Fehlerhandling besser zu machen.

Über das proc fs die GPIO zu konfigurieren und zu benutzen ist nicht die schnellste Version aber aus Kernel sicht vollkommen in Ordnung. Ein Unix Grundsatz wenn nicht vielleicht sogar einer der wichtigsten alles ist eine Datei und genau auf diese weiße anzusprechen. Memory Mapped IO wäre die schnellste Version ... auch wieder wenn es stimmt was geschrieben steht. Ich habe es bisher nicht ausprobiert. Man spart sich hier den Filesystem Overhead.

"Das wäre zumindest der schöne weg." => Das wäre der übliche Weg ... darauf können wir uns einigen.

Compiler Option c++11 benutze ich im Moment.

Von der Architektur her sehe ich nicht wirklich einen Unterschied zwischen der C API und WireingPi.

http://www.cpptips.com/fstream Das ist das gleiche wie der erste Vorschlag vom schorsch_76.
Wie bereits oben geschrieben funktioniert das bei mir nicht. Soweit mir bekannt haben die libc++ Entwickler alles nicht Standardkonforme entfernt was eigentlich sehr löblich ist.

Zum Standard muss ich sagen ich bin mir zwar nicht ganz sicher aber relativ ... jedes Moderne Betriebsystem unterstützt solche Sachen wie poll auf die eine oder andere Art. Das glaube ich ist nicht der Grund warum es nicht vorhanden ist. Den Streams konnte man vor c++11 nur char* als Dateinamen übergeben ich hatte nie verstanden warum nicht auch einen std::string. Kaum wartet man einige Jahre und schon gibt es c++11 und man darf auch std::string übergeben ...  

Ja stimmt das mit dem filesystem aus c++17 sollte ich mir anschauen. Wollte ich auch schon aber immer wieder vergessen ...  

[HaWe]

soweit ich weiß, ist Linux (samt Kernel-Funktionen) in C geschrieben, nicht in C++, und der kernel besitzt ja die GPIOs - aber ich bin da absolut kein Fachmann.
Wenn es dir nur darum geht, im Userspace auf GPIOs zuzugreifen, würde ich shedepe in jedem Falle Recht geben, dass das mit wiringPi sehr einfach und failsafe möglich ist.
Wenn du aber schnellere Funktionen, die direkt den kernel nutzen, verwenden möchtest, wäre auch pigpio eine sehr gute Quelle, denn sie sind großenteils noch deutlich schneller als die von wiringPi.

Ich selber verwende pigpio nicht, mir langt die wiringPi Performance, aber wenn du im RaspberryPi.org Forum nachfragst,
https://www.raspberrypi.org/forums/v...832e3a42a7309e
wirst du sicher sehr schnell sehr professionelle Hilfe bekommen: denn hier sind auch die Original-Autoren der beiden Libs (Henderson, Joan) sowie Mitarbeiter und Entwickler des Pis präsent und werden dir möglicherweise direkt antworten.

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

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

[NumberFive]

das C schnell als C++ habe ich nie gesagt. Und ich finde es Ok wenn C Programmierer weiterhin C machen auch das wurde Modernisiert und besser guten C Code als schlechter C++ Code.
Das die Spracherkennung Zuhause Funktioniert und nicht auf dem Gerät ist klar hat aber weniger den Grund der Rechenleistung der Mobileingeräte. Wobei wir hier noch das Thema alt Geräte ins Feld führen könnte.
Schon mal Probiert ein Modernes Smartphone mit 8 Kernen wirklich aus zu lasten und dabei in der Hand zu halten ? Auch der Akku hält das nicht lange durch.
Aber wir kommen zu Weit vom Thema ab. Versuchen wir unsere Software zu unseren Bedingungen zu machen und so die Welt ein bisschen besser. Nur rum Kriteln bringt uns alle nicht weiter.
Das einzige was mir echt zu denken gibt ist das Thema keine Zeit um Software machen zwar gibt es in immer mehr Sachen Software aber bei der Entwicklung wird 0 Zeit für die Software eingeplant. Software ist ja oft nur
Gentoo auf dem PI finde ich echt heftig den das Kompilieren auf der SD Karte mach doch nicht wirklich Spaß wie viele Karten hast du schon durch ?

Ich finde Debian schon ganz Ok und ich habe das auf Desktop und PI dann klappt es ganz gut mit dem Transfer der Software. Desktop Testen und dann auf den PI Portieren so weit nötig. Wobei ich fast nix habe was bis dato Portiert werden musste. Neu Compilieren natürlich.