C++ fstream GPIO Trigger/Interrupt

Schade deine Meinung warum man keine Opensource Entwickler finde hätte mich jetzt schon Interessiert. Egal.

Um einfange GUI zu machen könnte man auch über Gimp, SVG Dateien nach denken. Und dann einen "Treiber" der das SVG auf dem Display zeichnen. Herausforderung an dem Punkt ist dann das erkennen wann jemand geclickt hat und auf was. Das kenne ich von meiner eigenen GUI Entwicklung das wir Irgend wann Tricki. Schluss endlich Funktioniert sie so das von der SDL einfach Zeichen Flächen zu Verfügung gestellt werden also Quasi Controls und so die GUI zusammen gebaut wird. Ich hatte am Anfang die Aberwitzige Idee ich könnte die GUI als Lib bauen und nebenbei mit entwickeln aber das habe ich schon lange auf geben.
An der Verzeichnis Strucktur kann man es noch erkennen aber das war's dann auch. Das Projekt wäre alleine nie zu machen.

https://behindthesciences.com/electr...-pi-in-python/
Das ist Quasi so wenn ich das richtig verstanden habe das Display ist ein Bild und das wird dann "einfach" via SPI zu Display gesendet. Wenn man jetzt immer von einen Einfachen Bitmap ausgeht kann für die Graphic power auch auf so was wie Cairo oder so zurück greifen das muss man ja nicht selbst bauen.

Schade das du nicht verstehst das man an dem PI ein zweites Display gut brauchen kann. Bei mir geht es einfach um das Display welches bei machen Autos zwischen Tacho und Drehzahlmesser ist. Das dir sagt in 500m Rechts zum Beispiel. So das ich nicht den Blick auf das Große Display in der Auto Mitte machen muss.
Klar man könnte auch das ganze Armaturenbrett zum Display machen es gibt da auch geniale Lösungen von Geforce zum Beispiel oder gar ein Headup Display aber das ist nicht zu machen. Zu mindestens nicht für mich auch kommt dann schnell das Thema TÜV auf.

Eine zweite Anwendung wäre zum Beispiel am HDMI Leinwand und das Steuerdisplay als 3,5 Zoll am PI also ich denke da kann man schon bedarf erkennen.
Kodi drauf und so Media Wiedergabe ansteuern per Display und Ausgeben auf HDMI ok hier bräuchte man dann noch ein Kodi addon.

Der Elektor Link funktioniert bei mir nicht.

Zu mindestens bei mir geht es nicht um aufwendiges GUI und umleiten der Console oder sonst was. Ich möchte einfach was um "Bilder" anzeigen zu können. wenn ich HaWe richtig verstanden habe ist das sehr ähnlich nur möchte zusätzlich ein event wenn man mit dem Finger eine bestimmte Fläche Berührt.

Wir driften ordentlich von Thread Thema ab...

Die Kurzfassung ist das Deutschland ein reiches Konsumland ist. Man hat es nicht nötig etwas selber zu machen. Das gilt zumindest für die Meisten und daher hat selber machen hier so einen arme Leute Beigeschmack. Was ja nun bei weitem nicht der Fall ist. Es gibt definitiv nichts Wertvolleres als ein Handgefertigtes Einzelstück. Es gibt Untersuchungen wo z.B. viele 3D-Drucker benutzt werden. Nicht besitzen sondern wirklich benutzen. Das ist nicht Deutschland interessanterweise sind es eher ärmere Länder. Bei denen werden dann damit Ersatzteile für Mensch und Technik gebaut. Es gibt hier auch Unterschiede in den Städten in Berlin die eher eine arme Stadt ist wird sehr viel gemacht. Dort findet man immer Leute die auch Mitmachen. München ist eher eine Reiche Industriestadt hier wird nur ganz wenig gemacht ... man hat es einfach nicht nötig und sitzt lieber jeden Tag vor der Glotze und lauscht dem Täglichen Fernseh Nonsens. Dabei geht es beim selber bauen nicht unbedingt darum billiger zu bauen sondern anders und besser als der Industrieschrott der sehr oft auf dem Markt ist.

Ich habe doch nie geschrieben das ich zwei Displays für unnötig halte nur das man den HDMI nicht braucht. Es bleibt ja dann immer noch der Anschluss an dem das Orginal Display angeklemmt wird und dann kann man beliebige Displays mit z.B. SPI verwenden. Eine GUI ist immer nichts anderes als ein Pixelbild zu dem verwaltet wird welche Regionen anklickbar sind. Was Du aber gar nicht selber machen und Programmieren musst da Du ja auf einem Linux Rechner arbeitest. Alles was Du brauchst ist einen Kernel Treiber für jedes Display. Der Kernel kann beliebig viele Displays verwalten. Du musst dem bei der Programmierung nur sagen wo die Ausgabe hin soll. Das sollte aber die von Dir benutzte SDL auch können. Man verwaltet das am leichtesten so wenn man so tut als sei alles ein Window auch Butten und so. Dann gibt es Windows die fixe positionen in anderen haben und welche die man verschieben kann.

Das der Elektor Link nicht geht kann sein das der im Mitgliederbereich ist. Aber das wichtige der Hersteller der Display mit funktionierendem Treiber hat habe ich ja extra angegeben.

Ich würde an zum anzeigen von Bildern die Möglichkeiten des Kernels nutzen. Die Programmierung wird dann unabhängiger und den Teil des Projekts pflegen andere für Dich.

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.

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>

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.

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.

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.

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.

Zitat:

---

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.

Ich wollte der Log Klasse noch einen Stream operator dazu bauen damit man den dann wie den std::cout benutzen kann. Man könnte dann den Loglevel mit einem Streammanipulator einsetzen. So was wie zum Beispiel den std::hex.

Code:

---

pIntLog << hts::debug << "Ganz wichtige Meldung"

---

Das wäre dann glaube ich schöner aber das kann man ja immer noch machen. Es gibt vieles das ich an meinen Klassen gerne noch anderes machen würde aber kann man leider nicht alles auf einmal machen. Wie man diese Streammanipulatoren baut muss ich mir auch erst noch mal anschauen. Die Variante mit den Funktionen schadet auf jeden Fall nicht wenn die in der Klasse vorhanden ist. Die enum finde ich nicht so gelungen sparen aber speicher das stimmt schon. Ich müsste dann in der Klasse eine Übersetzung machen zwischen dem enum und dem Log-Status der ein String sein muss oder ein Array. Bei mir werden nicht einfach alle Level unter dem in Log-Status angegebenen ausgegeben sondern man muss jeden angeben den man im Log haben möchte. Ausnahme ist wenn man alle haben will dafür habe ich den Log-Status on der alle Loglevel an das Logziel schreibt.