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)