C++ fstream GPIO Trigger/Interrupt

[NumberFive]

Deutschland das Land der Dichter und Denker, Ingenieure...

Ok das mit dem Display habe ich jetzt auch verstanden. Wo bei ich sage den HDMI braucht man schon alleine wegen dem Sound und auch wegen der Auflösung das Waveshare hat 1024 x 600 Punkte also 16:9 nicht 4:3 aber egal. Mag ja sein das der Kernel beliebig viele Displays kann aber so einfach wie du schreibst ist es nicht. Ja die SDL kann auch mit einem Framebuffer Device um gehen aber eben nur mit einem Display.
Die SDL kann nicht einmal so und dann noch mal so zu mindestens nicht in einem Process. Und auch X-Server kann das nicht immer habe nämlich das Problem gehabt das ich zwei Monitore an meinen Rechner wollte und habe nach 2 Wochen aufgeben.

Ja Linux ist gut und kann viel aber eben auch nicht alles.

[alexander_ro]

Also mein Alien mit Gentoo kann das. Ich kann den internen Monitor und einen externen am VGA Port gleichzeitig benutzen. Der funktioniert dann als Verbreiterung des Desktop.

Bei den PC Grafikkarten muss es der Treiber unterstützen. Die kann man als Framebuffer Device benutzen sollte man aber nicht weil es dann keine Hardware Beschleunigung gibt.

Klingt für mich wie wenn es gehen könnte: https://stackoverflow.com/questions/...splays-in-sdl2

<edit>
Man muss unterscheiden zwischen den alten X-Servern und den neuen die bereits auf der mit Wayland geschaffenen Infrastruktur arbeiten. Da hat sich in den letzten Jahre viel verändert und das macht die Informationen im Netz recht unübersichtlich weil man manchmal schwer feststellen kann von was der Autor schreibt.

Hier gibt es eine kleine Übersicht: https://de.wikipedia.org/wiki/Direct_Rendering_Infrastructure
</edit>

[NumberFive]

Selbst wenn das wirklich gehen würde was ich noch nicht glaube genau wegen der Treiberschicht das eine ist der Nativtreiber für den PI von der SDL der andere wäre der "Einfache" Framebuffer Treiber. Und das es ein Problem gibt sieht man ja sonst würde es den Eintrag ja nicht geben.

Klar kann es sein das ich das Problem habe das die zwei Grafikkarten von Treiber her nicht vertragen und es deshalb nicht ging. Aber Ergebnis ist das selbe. Auch möchte ich nicht wissen wie Langsam das alles wird wenn ich den X-Server dazu zwinge in den FB Modus zu gehen.

Ich denke man muss schon unterscheiden Meldet ein Treiber 2 Monitore oder habe ich 2 Treiber an 2 Monitoren.

[alexander_ro]

Für den Kernel ist es ein Unterschied ob zwei Monitore an einer Grafikkarte oder zwei Grafikkarten mit je einem Monitor. Auch ob es ein einfacher Framebuffer ist oder echte Grafikkarte mit Hardwarebeschleunigung. Aber für den Anwender macht es keinen Unterschied. An dem Display das Du z.B. über SPI anschließt kannst Du OpenGL 3D Grafik ausgeben. Das ist halt langsamer aber es geht. Mesa unterstützt OpenGL auf einfache Framebuffer Devices.
Ist zwar schon älter aber immer noch richtig: https://www.linuxwiki.de/FrameBuffer

Warum hast Du eigentlich in Deiner I2C Klasse das schreiben/lesen der Daten nicht mit read/write gemacht sondern direkt mit der Kernel Schnittstelle. Hat das irgendwelche Vorteile?

Ich habe an meiner weiter gebaut ist aber noch nicht so wie ich es haben wollte. Aber wie ich gesehen habe hast Du das ja schon selber erledigt dann kann ich mir ja Zeit lassen.

[NumberFive]

Zum Thema Monitore habe wir einfach sehr Unterschiedlich Meinungen / Erfahrungen. Ich sage nicht das es falsch ist was du sagst ! Wenn ich jedoch so ein einfacher Display habe möchte und das was es gibt ist vom Andrio zum Beispiel dann kann ich es einfach direkt an bin als zu waren das mir jemand ein FB Treiber schreibt. Klar dann funktioniert die Software nur genau damit.
Zum Anderen ich kann dir nur sagen wie es war mit 2 Graphickarten immer nur eine Aktiv mit eine Dual Karte sofort beide Monitor mit Bild.

Zum I²C und Kernel Funktion da will ich ehrlich sein das habe ich gefunden und es Funktioniert. Es mit den C++ Funktionen zu schreiben habe ich einfach nicht Probiert.

Ich habe am 15. einen Termin und möchte ich halten drum muss ich zur Zeit massiv auf Funktion Programmieren was sicher nicht nur Gut ist für die Software.

[alexander_ro]

Jetzt habe ich das mit dem I2C soweit fertig. Da momentan nur den LM75 Temperatursensor mit I2C habe gibt es auch nur für den eine Klasse zur Hardware Unterstützung. Ich habe mir ein Platinchen bestellt mit einem 16-bit Wandler auch mit I2C dazu werde ich jetzt mal noch so eine Hardware Klasse bauen. Ich habe wieder wie immer die ungeliebte Fehlerbehandlung eingebaut. Ich finde es halt sehr lästig wenn es Fehler gibt und das Programm schweigt sich darüber aus wo er aufgetreten ist ...

https://git.hts-software.de/cgit.cgi...a-Api/tree/I2c

Ja stimmt schon es kommt darauf an was man mit den Displays machen will. Wenn es ein Linux Rechner ist Suche ich halt nach Möglichkeit eines zu finden das vom Kernel unterstützt wird.

[NumberFive]

Ich finde es halt sehr lästig wenn es Fehler gibt und das Programm schweigt

Da kann ich dir nur zustimmen noch besser sind try catch die alles fangen und nichts sagen.
Sieh ganz nett aus dein Code.

pIntLog->setLogLevel ("Debug");
pIntLog->sendMessage ("Call: I2c::I2c ("" + strIntDevFile + "", ..., pLog)");

Daran werde ich mich so schnell nicht gewöhnen aber das ist Künstlereiche Freiheit LOG(DEBUG) << "Da ist eine Debug ausgabe" finde ich da einfacher. Auch ist für mich das Loglevel kein String sondern ein enum.