- LiTime Speicher und Akkus         
Seite 10 von 10 ErsteErste ... 8910
Ergebnis 91 bis 96 von 96

Thema: C++ fstream GPIO Trigger/Interrupt

  1. #91
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    31.01.2004
    Ort
    36399
    Alter
    49
    Beiträge
    1.562
    Anzeige

    Praxistest und DIY Projekte
    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.
    P: Meine Tochter (06.11.07) und https://www.carnine.de
    M: Träumen hat nix mit Dummheit zu tun es ist die Möglichkeit neues zu erdenken

  2. #92
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    10.04.2005
    Ort
    Bad Aibling
    Beiträge
    212
    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.

  3. #93
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    31.01.2004
    Ort
    36399
    Alter
    49
    Beiträge
    1.562
    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.

    Code:
    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
    };
    Code:
    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.
    P: Meine Tochter (06.11.07) und https://www.carnine.de
    M: Träumen hat nix mit Dummheit zu tun es ist die Möglichkeit neues zu erdenken

  4. #94
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    10.04.2005
    Ort
    Bad Aibling
    Beiträge
    212
    Der 64 Bit Prozessor arbeitet am schnellsten wenn er 64 Bit Wörter vergleicht. Dafür gibt es auch entsprechende Befehle die auch für String vergleiche taugen. Bei kurzen Strings und einem 32 Bit enum wird der Unterschied daher in der Schnelligkeit nicht so groß sein. Der GCC kann Dir den Assemblercode zugeordnet zu den C++ Sourcecode ausgeben. Da findet man das dann relativ leicht was er daraus macht. Erklärungen zu den Assembler befehlen findet man bei ARM.

    Wenn Du bei mir als Logstatus Debug angibst dann wird nur Debug ausgegeben. Wenn Du Debug und Error ausgeben willst musst Du auch beides angeben. Die Log Klasse hat einen Logstatus (was soll ausgegeben werden) die LogMeldung einen Loglevel (Priorität diese Log Meldung). Das soll so sein. Logisch muss man einen if machen den muss man aber bei einem enum auch machen.

    Der Linux Debugger macht das nur wenn er entsprechend konfiguriert wurde. Früher konnten die das gar nicht.

    Du hast jetzt einfach die Zeit bei dem Kritisch unterschlagen ...
    Zeitkritische Programmteile sollten kein Log ausgeben. Jedes Log auch vom syslog ist sehr teuer was Zeit betrifft.

    Du hast da sicher recht das die Verwendung eines Strings ein bisschen Zeit kostet. Fast immer wird aber die Log Meldung so nur im Fehlerfall ausgegeben. Sehr oft für der Fehler zum sofortigen Programm Abbruch. Ich war aus Sicherheitsgründen schon immer der Meinung ein Programm sollte im Fehlerfall Infos Sammeln ausgeben und sich möglichst anständig beenden. Wobei ein exit schon problematisch ist weil dann keine Destruktoren mehr aufgerufen werden.

    Wie sieht das denn mit dem Callstack bei den anderen aus?
    Wenn ich einen brauchte habe ich den gdb bemüht. Des Programm starten zum Beispiel einfach bis zum Absturz laufen lassen. Dann kann man sich einen Callstack ausgeben lassen. In der Ausgabe des strace kann man den verfolgen. Oder wenn man die Erstellung eines Dump einschaltet kann man mit gdb diesen öffnen und ebenfalls den Callstack anzeigen lassen. Im Ideal Fall kann man es aus den Log Meldungen sehen.

  5. #95
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    31.01.2004
    Ort
    36399
    Alter
    49
    Beiträge
    1.562
    Sorry aber das man mehr als ein Loglevel angeben muss geht wirklich an allem vorbei was ich so kenne. Normal gebe ich das Max an was ich sehen will.

    Um ein Programm bis an den Punkt des Absturtz laufen lassen zu können brauche ich entweder gute User oder ein haufen log. Ich kenne nur immer wieder die Aussage Was hast gemacht als es Abgestürtzt ist ? Nichts ist einfach abgestürzt. Im Job Kontext sind jetzt gerade am Testen das immer Intern das Debug Level an ist aber nur bei Auftreten von einer Warn oder Error eintrag der Speicherbuffer geschrieben wird. Da kostet zwar Ram aber man kann sehen was kurz vor der Warn oder Error Meldung war ohne die ganze Zeit die Platte als Bremse zu haben. Wenn wir davon ausgehen das Logging nicht in eine Datenbank geschrieben wird was sich Natürlich in einfachen Systemen einfach nicht lohnt. Bei größeren Systeme schon aber das habe ich im Job leider noch nicht durch setzten können (im Job).

    Bei den Dingen die Ich programmiere ist das Laufen lassen bis zum Crash definitiv nicht möglich weil wie gesagt andere Programme / Hardware die "User" sind und die sind nicht Transportiert bar.

    https://tuxthink.blogspot.com/2012/0...log-level.html
    https://www.linuxquestions.org/quest...-crond-273547/
    https://logging.apache.org/log4cxx/l...1_1_level.html

    Loglevel immer Int
    P: Meine Tochter (06.11.07) und https://www.carnine.de
    M: Träumen hat nix mit Dummheit zu tun es ist die Möglichkeit neues zu erdenken

  6. #96
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    10.04.2005
    Ort
    Bad Aibling
    Beiträge
    212
    Ich habe nie behauptet meine Log Klasse würde sein wie andere wäre sie das wäre es nicht sinnvoll eine neue zu bauen. Mich hat das schon oft genervt das man oft Loglevel einschalten muss die ich nicht haben will nur weil der zwischen den anderen liegt. Also ich will genau das sehen was für den Zweck wichtig ist und sonst nichts. Das macht das Log nur unübersichtlich und das wichtige wird dann übersehen. Da helfen Tools zum Auswerten auch nur bedingt.

    Wenn man in Programmen Fehler sucht die andere Testen sollte man einen Speicherdump erzeugen lassen. Dann kann man ganz leicht die Ursache der Problems finden. Hat man seine Hausaufgaben gemacht bei der Fehlerbehandlung ist das aber fast nie nötig weil dann in der Log Meldung steht was wo passiert ist. Das einzige was sich etwas Widerborstig anstellt sind Speicherlecks aber für die Problemfälle unter den Problemfällen gibt es den Dump. Auch die Nutzung der Compiler Makros die einem Programmzeile und Dateiname in eine Log Meldung schreiben können sind von echtem Wert beim Fehlersuchen. Das Programm mit strace starten kann man auch für andere User einrichten und die Ausgabe liefert weitere Infos die helfen können. Sollte ein Programm sich nur Aufhängen und nicht Abstürzen muss man sich zwar zu dem User hin bewegen kann aber dann mit dem gdb auch einen noch laufenden Prozess Debuggen. Das ist immer sehr hilfreich wenn ein Programm hängt und keinerlei Kommentar abgibt was schief läuft. Also Möglichkeiten an Informationen zu kommen gibt es viele da sind die eigen Debug Meldungen nur ein kleiner Teil und oft nicht hilfreich weil die letzten Meldungen vor aufhängen/Absturz so nicht mehr im Log auftauchen.

    Ja aber selbst ein int ist schon viel zu groß für die paar Loglevel ...

Seite 10 von 10 ErsteErste ... 8910

Ähnliche Themen

  1. Benötige Hilfe zu AT32U3C und GPIO
    Von xrzr im Forum AVR Hardwarethemen
    Antworten: 1
    Letzter Beitrag: 10.11.2015, 19:54
  2. Respberry Pi GPIO mit C++ und QT
    Von Basti1204 im Forum Raspberry Pi
    Antworten: 0
    Letzter Beitrag: 06.03.2013, 00:01
  3. [ERLEDIGT] Raspberry Pi GPIO
    Von Kampi im Forum Raspberry Pi
    Antworten: 4
    Letzter Beitrag: 04.11.2012, 23:45
  4. GPIO-Register Ansprechen
    Von kmrish im Forum Microcontroller allgemeine Fragen/Andere Microcontroller
    Antworten: 7
    Letzter Beitrag: 14.07.2011, 10:45
  5. schmitt-trigger an interrupt
    Von Bluesmash im Forum Sensoren / Sensorik
    Antworten: 2
    Letzter Beitrag: 19.06.2005, 23:46

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiTime Speicher und Akkus