C++ fstream GPIO Trigger/Interrupt

**alexander_ro** · 06.12.2018, 10:50

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** · 07.12.2018, 06:00

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** · 18.12.2018, 11:32

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** · 19.12.2018, 07:48

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.

**alexander_ro** · 19.12.2018, 10:09

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.

**NumberFive** · 21.12.2018, 13:10

es gibt noch einen Vorteil den man in meine Augen nicht unterschätzen darf. String vergleiche sind Teuer. Wenn das Level ein Enum ist kann man es mit Int vergleichen was viel Weniger kostet. auch ist es leichter zu sagen Verbose = Alles. Sonst muss du bei Loglevel Verbose eine Menge If's mache alle auf Strings und das wird man merken. Klar das Merkt man sicher nur wenn das Logging auf Off oder Error sitzt. Wenn das Level auf Debug ist wird der Unterschied nicht so Dramatisch sein weil das schreiben dann mehr Zeit frist.

Aber es ist deine Software aber so machen es Alle logging Frameworks die ich bis jetzt in der Hand hatte.

**alexander_ro** · 21.12.2018, 15:46

Wie viele Byte belegt denn ein enum?

Dafür sehe ich aber auch im Debugger gleich am Inhalt der Variable was Sache ist. Bei den enum wird immer nur eine Zahl angezeigt was die Bedeutet muss man dann suchen. Klar muss man vielleicht ein paar Byte mehr belegen. Die 64bit Prozessoren können aber so nur acht Byte auf einmal effizient vergleichen bei 32bit sind es immerhin 4 Byte. Klar können die auch ein Byte vergleichen aber das spart nicht wirklich Zeit. Normal findet das ja nur statt wenn etwas nicht nach Plan läuft alleine das nicht nach Plan laufen kostet schon Zeit. In Zeitkritischen Programmen sollte man so keine Ausgaben machen. Es ist auch ein Vorteil der Exceptions das die nur Zeit kosten wenn sie auftreten das gilt auch für die zur Behandlung nötigen Log Ausgaben. Stimmt aber schon es könnte in der Tat ein wenig Zeit und Speicher kosten viel wird es aber nicht sein.