C++ fstream GPIO Trigger/Interrupt

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

[alexander_ro]

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.

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]

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]

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.

[NumberFive]

ich habe mir jetzt nicht den Assembler Code für String vergleiche an gesehen und muss dir glauben das der Processor da mehrere Zeichen gleichzeitig vergleichen kann. (Wäre echt mal Interessant sich das in der Tiefe anzusehen).
Tatsache ist aber das für das Wort "Debug" ein 32 Bit Processor nach deiner Aussage schon nicht mehr reicht. Mir ist auch ein Rätsel wie du es machen willst wenn ich das Level auf Debug stellen das dann die Anderen Levels raus geschrieben werde ohne das ein if grab daraus kommt. If Level < LoglevelEBUG finde ich irgendwie einfacher zu lesen.

Auch wenn man jetzt eine Funktionsbeschreibung per Intellisence bekommt ist doch besser da steht als Type Loglevel als String oder Int da weiß man gleich was man da nehmen muss.

Also der Debugger unter Window Zeigt mir dann auch die Enums bei Linux sieht man es mal und einmal nicht habe noch nicht raus bekommen woran das Liegt.

enum class AppEvent : Sint32{
    ChangeUiState,
    CloseButtonClick,
    PlayButtonClick,
    MusikStreamStopp,
    MusikStreamError,
    MusikStreamPlay,
    AlbenClick,
    TitelClick,
    PlaylistClick,
    FilelistClick,
    CloseGuiElement,
    NewGeopos,
    BackendConnected,
    BackendDisconnected,
    MapMenuOpen,
    LongClick,
    Click,
    ClosePopup,
    OpenMapTextSearch,
    MediaFileUpdate,
    RemoteControl
};

std::ostream& operator<<(std::ostream& os, const AppEvent c) {
    switch (c) {
        case AppEvent::ChangeUiState: os << "ChangeUiState";    break;
        case AppEvent::CloseButtonClick: os << "CloseButtonClick"; break;
        case AppEvent::PlayButtonClick: os << "PlayButtonClick"; break;
        case AppEvent::MusikStreamPlay: os << "MusikStreamPlay"; break;
        case AppEvent::MusikStreamStopp: os << "MusikStreamStopp"; break;
        case AppEvent::MusikStreamError: os << "MusikStreamError"; break;
        case AppEvent::AlbenClick: os << "AlbenClick"; break;
        case AppEvent::TitelClick: os << "TitelClick"; break;
        case AppEvent::PlaylistClick: os << "PlaylistClick"; break;
        case AppEvent::FilelistClick: os << "FilelistClick"; break;
        case AppEvent::NewGeopos: os << "NewGeopos"; break;
        case AppEvent::BackendConnected: os << "BackendConnected"; break;
        case AppEvent::BackendDisconnected: os << "BackendDisconnected"; break;
        case AppEvent::MapMenuOpen: os << "MapMenuOpen"; break;
        case AppEvent::LongClick: os << "LongClick"; break;
        case AppEvent::Click: os << "Click"; break;
        case AppEvent::ClosePopup: os << "ClosePopup"; break;
        case AppEvent::OpenMapTextSearch: os << "OpenMapTextSearch"; break;
        case AppEvent::MediaFileUpdate: os << "MediaFileUpdate"; break;
        case AppEvent::RemoteControl: os << "RemoteControl"; break;
        default:  os << "AppEvent not in list";
    }
    return os;
}

Das man Kritische Processe nicht Loggen können muss kann ich nicht nachvollziehen. Ich Arbeite mit Systemen die 365/24 zu Verfügung stehen sollten und wenn das mal nicht so ist wollen alle wissen was war. Da haben mir die Log schon hofft wertvolle hinweise geliefert. Auch ist es so das ich die anzubinden Systeme nicht einfach ins Büro holen kann und für jeden neue Anbindung in der Welt rum fahren ist meinem Arbeitgeber schnell zu Teuer (mache ich auch nicht mehr gerne) ergo bleibt nur das Logging.

Aber lassen wir das du machst deine Software ich meine. Gerade bei C++ gibt es nicht nur eine Lösung für eine Sache und da spiele ganz schnell auch noch andere Sachen mit rein (Umgebung, Testbarkeit).
Eine Frage habe ich aber doch noch hast du dich schon mal damit beschäftigt wie man bei einer Exception in C++ an einen CallStack ran kommt ? das ist für mich der einzige echte Vorteil von C# oder Java.