C++ fstream GPIO Trigger/Interrupt

[HaWe]

ganz dumme Frage, vlt völlig abwegig, denn ich bin kein C++ Programmierer - aber kann man einen Pointer erzeugen, der auf fstream zeigt?
edit,
egal welcher ptr Typ, könnte auch ein void* sein, in der Art

void* vptr;
vptr = (void*)&fstream; // ???

wenn das ginge, dann könnte man per typecasting evtl doch sein fd über fileno() bekommen...?

int fd = fileno( (FILE*) vptr);

[alexander_ro]

@Ceos: Ja stimmt es geht darum einen GPIO zu benutzen wie einen Interrupt. Ja stimmt inotify sollte auch gehen braucht aber so weit ich auf die schnelle gesehen habe auch den Filedeskripte (fd) den ich wenn ich einen fstream benutze aber nicht habe. Ich hatte erst epoll gefunden damit geht das auch nur mit fd. Es stimmt schon das ich einen fstream benutzen wollte aber so wie es aussieht geht das nicht was ich merkwürdig finde aber auch nicht ändern kann. Was ich nicht benutzen wollte ist Raspberry spezifische Software wie WiringPi. Weil das Kernel und Standard C lösen können und dann ist es kompatibler für andere Platinchen mit Linux. Was ich auch nicht möchte ist eine lib benutzen die letztendlich auch nur Kernel und C benutzt und ich dazu wieder einen Wrapper bauen. Die Software wird nicht besser nur weil man Software Schichten stapelt.

@sast: Das stimmt jetzt so nicht ganz. Das war die Ursprüngliche Idee (fstream oder steam allgemein) es scheint aber damit nicht zu gehen dann werde ich das halt umbauen auf Kernel und C Funktionen. War halt ein Versuch wenn man aber nicht mal was probiert was nicht jeder schon macht gibt es auch nie einen Fortschritt.

@HaWe: Zu so etwas ähnlichem hatte schorsch_76 schon einen Link gepostet. Das sieht aber sehr Merkwürdig aus und nicht so wie wenn man das wirklich tun sollte und ja man kann wie in C von allem in C++ auch einen Pointer bekommen. Den mag der Compiler nicht automatisch in alles andere konvertieren. Aber wenn man mit einem explizitem Cast dem Compiler sagt er soll die Klappe halten und tun was der Programmierer sagt. Dann quetscht der jeden Datentyp in einen anderen egal ob es geht oder nicht. Das sieht der Compiler schmerzfrei weil er es ja dann schriftlich (Cast) hat das der Programmierer am verlorenen Kommunikationssatelliten Schuld ist ...

Ich habe mal gesucht bei C++17 und der dort neuen filesystem Objekte konnte da aber auch nichts entdecken das aussah wie etwas das ich bräuchte. Das finde ich auch merkwürdig. Weil ja filesystem extra eine Funktion hat mit der man feststellen kann ob die Datei ein socket ist. Aber gerade bei einem Socket wäre es ja sehr wichtig eine Funktion zu haben die einem Mitteilt wenn neue Daten zum abholen da sind. Aber vielleicht wollten die sich das für den nächsten Standard aufheben damit die später auch noch was neues einbauen können.

[HaWe]

du hast Recht, ich fand die Idee auch zuerst - sagen wir: - verwegen.
Dennoch, nach dem Motto "alles ist ein File" und "Pointer sind auch nur Speicher-Adressen" war meine Idee schlicht
fstream ist ein file,
FILE ist ein file,
jeder File hat eine Adresse,
jeder File (zumindest FILE) hat einen File Descriptor,
also warum nicht mit dem Pointer vom einen auf den Wert vom anderen Pointer verweisen, genau wie man mit einem void* auf den Wert eines int* oder auf ein char* oder float* verweisen kann und umgekehrt.
Probiers doch einfach mal aus, mehr als 35 EUR wird es schlimmstenfalls nicht kosten

PS,
notfalls, falls gpp streikt, bliebe immer noch -fpermissive :P

- - - Aktualisiert - - -

PS,
eventuell ließe sich das oben gesagte sogar noch etwas "obfuscated" zusammenziehen:


int fd = fileno( (FILE*)&fstream );

[alexander_ro]

Ich habe das mal so probiert:

std::cout << fileno ((FILE*) &fileIntPortValue) << std::endl;

Da bekomme ich abwechselnd 0, 1 oder -1. Was eigenltich nicht stimmen kann weil ja stdin, stdout und stderr bereits die Filenummern 0, 1, 2 belegen.

[HaWe]

ok, wär' ja auch zu schön gewesen, aber immerhin, auch wenn es Unsinn war, fand ich war es wenigstens einen Versuch wert
(wobei ich aber auch zuwenig von C++ verstehe, um zu sagen zu können, ob (FILE*) &fileIntPortValue wirklich dasselbe ist wie (FILE*) &fstream)
edit,
war blöd formuliert, ich meinte ob fileIntPortValue die echte Adresse ist, wo im fstream die file Daten aktuell anfangen.

[alexander_ro]

Ja probieren kann man das immer.

Von der Theorie her könnte so etwas schon gehen. Der Pointer zeigt ja auf das erste Byte der Variable vom Typ fstream im Speicher. Wenn jetzt die Datenstructur FILE am Anfang des Speicherbereichs den fstream belegt steht könnte man es einfach benutzen wie wenn es ein FILE wäre. Ich weiß aber nicht ob es überhaupt dem Programmierer möglich ist fest zu legen welche Daten einer Klasse im Speicher am Anfang liegen.

// int ist der Datentyp, Nummer der Name der Variable damit der Programmierer die Benutzen kann.
int Nummer;

// fstream ist der Datentyp, fileIntPortValue der Name der Variable.
// C++ Objekte werde einfach wie interne Datentypen benutzt
fstream fileIntPortValue;

Damit man ein C++ Objekt benutzen kann muss man immer eine Instanz davon erzeugen und das macht man genauso wie bei internen Datentypen in dem man eine Variable definiert. Ein Pointer auf den Datentype ist ja nicht möglich das ist auch bei den internen Datentypen wie int nicht möglich.

[Ceos]

Weil das Kernel und Standard C lösen können und dann ist es kompatibler für andere Platinchen mit Linux

Was ich darüber so gelesen habe, brauchst du Kernelunterstützung um "echte" Interrupts zu bekommen, daher erwähnte ich das mit Wiring Pi und der Unterstützung am Rasppbery Pi, aber ohne Kernelunterstützung kannst du wohl maximal so schnell werden wie der Kernel dir für das GPIO-device ein udate macht und dann über inotify ein signal geben lassen. Aber ob es auch andere wege gibt habe ich leider keine Ahnung.

Inotify brauch übrigens keine FDs sondern nur den Pfad zur überwachenden Datei/Ordner (achtung bei änderungen an dateien im ordner selbst werden nicht zwingend signale vom ordner-notifier ausgegeben, das ist wohl vom dateisystem abhängig)

[alexander_ro]

GPIO sind ja keine echten Interrupt. Deshalb bezeichne ich die auch immer als Trigger das kommt besser hin. Ein echter Interrupt muss von der Hardware auch als solcher unterstützt werden und echte Hardware Interrupt macht der Kernel selber die Steuerung. Kann so ein Ereignis aber auch wieder an den Userspace weiterreichen. Ich weiß nicht ob der Raspi an seinem Stecker einen echten Hardware Interrupt herausführt. Bei den AVR gibt es so was aber auch dort kann das nicht jeder Port.

Man kann aber so tun als ob ein GPIO ein Interrupt ist das ist dann ein Software Interrupt so zu sagen. So ähnlich wie das auch bei PWM ist die kann man in Hardware haben und in Software Simulieren.

Inotify kenne ich jetzt nicht so gut ich weiß auch nicht wie schnell das ist weil es relativ kompliziert aussieht. Für diesen Zweck würde ich jetzt eher epoll oder poll benutzen. Wenn man dem glaubt was geschreiben steht ist epoll schneller als poll, Dabei geht es ja eigentlich nur darum das das warten auf ein Ereignis möglichst wenig Rechenzeit verbraucht.

Hier hatte ich das her: http://opensourceforu.com/2011/04/ge...-with-inotify/
Der benutzt fd für den inotify init. Das hatte ich übersehen das es kein File fd ist.

[edit]
inotify hat aber einen Nachteil gegenüber poll/epoll man muss ja selber in einer Schleife lesen ob eine Nachricht da ist. Dann kann man genauso gut in einer Schleife prüfen ob der Port sich geändert hat. inotify würde ich jetzt mal sagen ist erst dann interessant wenn man mehrere Dateien überwachen muss.
[/edit]

[Ceos]

GPIO sind ja keine echten Interrupt. Deshalb bezeichne ich die auch immer als Trigger das kommt besser hin. Ein echter Interrupt muss von der Hardware auch als solcher unterstützt werden und echte Hardware Interrupt macht der Kernel selber die Steuerung. Kann so ein Ereignis aber auch wieder an den Userspace weiterreichen. Ich weiß nicht ob der Raspi an seinem Stecker einen echten Hardware Interrupt herausführt. Bei den AVR gibt es so was aber auch dort kann das nicht jeder Port.

genau daher mein nachsatz, wiringPi kann genau das auf raspberrys

aber was das inotify angeht, versuchs makl mit folgender webseite (englisch, ich weis) https://www.ibm.com/developerworks/l...ify/index.html

in der erklärung sieht das relativ simple aus, du macht das init, dann ein add_watch auf die datei (also den pfad) und auf die eventqueue (die du vom add_watch bekommst) ein read, das so lange blockt bis die datei sich tatsächlich ändert und das event gesendet wird. Aus der queue siehst du dann welches event, führst dein read auf der datei aus, holst das ergebnis und löst ggf. ein signal oder einen callback aus. Optimal läuft das natürlich nur als multithread aber ich habe auch gelesen dass inotify angeblich selber in der lage sein sollte signals auszulösen, wenn cih finde, reich ich's nach

[HaWe]

wenn ich den OP recht verstanden habe, will er ja kein wiringPi, und wiringPi Sourcecode ist zwar kein Hexenwerk und ist auch bereits auf jedem neueren Raspbian via apt fertig installiert und einsehbar, aber wegen des Raspi device trees ist es dennoch nicht unbedingt zu anderen Linux kompatibel, noch nicht mal unbedingt zu anderen Debians (z.B. nicht zu ev3dev, auch eine Debian distri.).