C++ fstream GPIO Trigger/Interrupt

[alexander_ro]

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.

Das war mir ja nun auch schon aufgefallen.

Nein das Problem mit dem fd ist nicht gelöst weil das in meinem Sourcecode das ist was ich probiert habe aber nicht funktioniert.

fstream::rdbuf()->fd() das scheint nicht Standard zu sein und deshalb wurde es aus der libc++ wieder ausgebaut. Haben die ja eigentlich recht.

Die Funktion fileno kenne ich aber die braucht die gefüllte Datenstruktur FILE die bekommt man von der C Funktion open aber nicht vom fstream. Das ist das Problem.

[sast]

Das fileno nicht geht, habe ich inzwischen auch gelesen, weil sich fstream und FILE unterscheiden. Die einzige Gemeinsamkeit ist, dass sie intern im Unixsystem über fds abgewickelt werden. Deswegen sollte es irgendwie möglich sein, an den Filedescriptor zu kommen. Aber wie schon gesagt, verbiegst du dich total um dann doch nur zu pollen. Wenn fstream das Event nicht direkt anbietet nützt das nun mal nichts.
Was steht denn in dem fstream? Eventuell kann man das im Interval vergleichen, wenn es zB nur ein Byte oder Wort ist.

[Ceos]

okay für mich kurz zur info, es geht darum dem GPIO ein signal/interrupt zu entlocken wenn ein GPIO sich ändert?

ich weis dass man eine file mittels mmap in den speicehr mappen kann und so zumindest den zugriff stark vereinfachen kann

obendrein wären da noch die linuxwerkzeuge inotify oder wenn der kernel das nicht hat, dnotify, damit kann man ohne die file zu lesen prüfen ob sie geändert worden ist, ob das mit device files auch funtkioniert konnte ich aber auf die schnelle nicht herausfinden, eventuell wäre das ein ansatz?


EDIT: ---------

habe gerade sogar gelesen dass interrupt unterstützung vom kernel verfügbar sei, nur noch nicht wie ich ddran komme (wie üblich alles in python)

[sast]

alexander_ro möchte unbedingt fstream nehmen. Da liegt die Schwierigkeit.

[Ceos]

okay dann bin ich weider raus, PS wiring pi hat sogar unterstützung für kernel GPIO interrupts zur info

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