-         

Ergebnis 1 bis 6 von 6

Thema: Ein Stück C-Code - sieht richtig aus, aber es gibt ne Fehlfunktion

  1. #1
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.551

    Ein Stück C-Code - sieht richtig aus, aber es gibt ne Fehlfunktion

    Anzeige

    oder
    Rauhnächte, C und andere Mysterien

    Nachdem wir den Weltuntergang überstanden haben, müssen wir nun aufräumen.

    Aufräumen hatte bei mir u.a. auch mit ner geänderten Pinbelegung an einer RNControl zu tun, bei der ich den RC-5-Decoder vom Pollen an einem allgemeinen Eingangspin auf einen externen Interrupt umgelegt und softwareseitig entsprechend umgearbeitet hatte. Der Decoder funktioniert prächtig.

    Die Fernsteuerung hat bei mir noch (seit MiniD0) die Funktion, die Akkuüberwachung bei Bedarf/auf Wunsch beim Programmstart ausser Kraft zu setzen, um im Notfall noch Aktionen durchführen zu können. Dafür läuft als dritter Arbeitsschritt im main - nach der Portinitialisierung und einem delay-gesteuerten Reset-LED-Blinken die Abfrage des RC-5-Pinns. Bis dahin ist also kein anderes Modul aktiv, kein Interrupt, kein Watchdog, keine sonstige Controlleraktivität aktiviert. Wird zu diesem Zeitpunkt am RC-5-Eingangspin ein low erkannt, dann wird die Akkuüberwachung auf ADC=2 gestellt - also fast ausgeschaltet. Nochmal: es läuft noch kein Interrupt, kein sonstiger Schritt, kein Watchdog, kein garnix.

    Die genannte Pinänderung hatte ich beim Übergang auf den internen Interrupt vergessen und bin dieser Tage (am 26. Dezember) zufällig draufgekommen.

    Also wird der Code geändert, der früherer Anschluss von PC2 auf den aktuell auch tatsächlich benutzten PINB2 gelegt (was in der Interruptroutine bestens funktioniert):

    Code:
    // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    //      Abfrage ob ADC-Wert-Prüfung abgeschaltet werden soll
    //      ###>>>  Zum Abschalten IRGENDEINE Fernsteuerungstaste drücken
    /*
      ADC5MM        = 500;          // Setze ADCMiniMum auf MiniMalwert
      for (uint8_t k=0; k<1000; k++ )      // Eingang/SFH5110 abfragen => low ?
      {                             //   RC-5-Signal hängt am PB2
        if (!(PINB & (1<<2))) ADC5MM = 2;// Wenn Sensor auf LOW steht <=> IR ist on
      }                     // Ende von for ( i=0; i<1000; i++ )
      */
    // - - - - - - - - - - - - - - -
    Und schon schlägt einer der Rauhnacht-Geister zu. Das Programm bleibt hängen. Nach dem Auskommentieren - wie im Codezitat oben gezeigt - läuft das Programm wie üblich. Als Ergänzung noch ein drittes Mal folgendes: es werden davor a) die Pinne definiert als Ein-/Ausgang und mit/ohne Pullup, danach kommt die wait-gesteuerte Blinkerei (10 mal).

    Ich habe diesen Codeschnippsel völlig gelöscht, neu geschrieben, die Schaltung kontrolliert, den Kopf gekratzt, mich geärgert, mich gewundert - es hatte alles nix geholfen. Das Programm, das mit Kommentaren mittlerweile insgesamt an die tausend Codezeilen umfasst, läuft ohne diesem Schnippsel (ok, mit Auskommentierung) wie üblich, mit aktivem Schnippsel bleibt es zwischen diesem Codeteil und der ersten UART-Ausgabe hängen. Wo - ist EXAKT nicht nachgewiesen.

    Langer Rede kurzer Sinn (und um meinen Groll über die ganze Sache nicht allzu hoch kochen zu lassen): Ich habe die letzte Sicherung vom Tag davor genommen, neu eingespielt, die Pinabfrage wie oben skizziert eingefügt/geändert, kompiliert, geflasht - und es funktioniert.

    Nun bleibt eine unmystische Frage offen: gibt es irgendwelche Suchkriterien um solche Vorkommnisse aufzuklären? Klar, die *.lls durcharbeiten - 4720 Zeilen - irgendwie ist mir das zu viel Arbeit. VERMUTLICH liegt der Fallstrick schon in den ersten Abläufen, aber . . . wenn nicht? Simulator? Ich habe den Simulator vor Jahren mit Assembler erfolgreich benutzt, aber bereits dort die Problematik bei nur einem Interrupt eigentlich nicht in den Griff bekommen, ich habe kein ICE (und müsste mich da auch lange einarbeiten) - sprich: ich fürchte, dass ich erstmal mit dem Simulator und verwandten Hilfen nicht wirkliche Hilfe bekäme.

    Vermutlich passiert das dem einen oder anderen von Euch auch gelegentlich: nicht nachvollziehbare Fehlfunktionen. Vor ein paar Tagen hatte ein Kollege, der seinen Roboter mit nem ARM betreibt, mir geschrieben, dass er seit etlichen Stunden eine LED nicht angeknippst bekommt . . .

    Mich stört hinter "meiner" Störung das ungute Gefühl, dass es vielleicht eine Unsauberkeit im Restcode ist, eine Unverträglichkeit, die beim Husten eines Schmetterlings in China zur Fehlfunktion meines Roboters führt oder führen kann. Wie sucht man so etwas (wenn die eigenen C-Kenntnisse nicht wirklich umfassend und nicht annähernd perfekt sind). Oder - macht Ihr das so wie ich - alte Sicherung her, anpassen an die Änderungen seit der Sicherung - und wenns dann funktioniert - dann ists gut?

    Oder vielleicht die Frage einfach so: was überwiegt bei Euch? Die kritische, möglichst genaue Analyse auch dann, wenn der Code "ewig" lang geworden war (und wie macht ihr das?) - oder die experimentelle Lösung - wenns klappt ists gut?
    Ciao sagt der JoeamBerg

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    20.08.2008
    Ort
    Kandel
    Alter
    29
    Beiträge
    1.220
    uint8_t k < 1000? uint8_t erreicht maximal den Wert 255 und läuft dann über zu 0 ... Volia, eine Endlosschleife ist geboren.

    Edit: Zur Methodik
    "Hängen bleiben" kann eigentlich nur wenige Ursachen haben. Entweder wird die erwartete Funktionalität nicht ausgeführt weil sie übersprungen oder nicht mehr erreicht wird. Selten bleibt der Controller stehen (sleep!). Die ersten beiden Fälle erfordern also die Identifikation von Situationen, in denen Code umgangen wird oder in (fast) Endlosschleifen übergehen kann.
    Bei deinem Beispiel war es der letztere Fall mit dem zu kleinen Datentyp für den erforderlichen Wertebereich.
    Was die Fehlersuche angeht: Die Lokalisierung der Ursache kann durch Debugging-Ausgaben, Simulation oder Hardware-Debugging erleichtert werden. Es hilft auch, wenn der Ursprung des Problems durch weglassen unbeteiligter Komponenten eingegrenzt werden kann. Manche Versionsverwaltungssystem bieten außerdem Unterstützung bei der Fehlersuche in dem sie Hilfsmittel zum Auffinden des fehlerhaften Commits bieten (git bisect etc.).

    mfG
    Markus
    Geändert von markusj (28.12.2012 um 11:34 Uhr) Grund: Nachtrag Fehlersuche
    Tiny ASURO Library: Thread und sf.net Seite

  3. #3
    Erfahrener Benutzer Roboter Genie Avatar von HeXPloreR
    Registriert seit
    08.07.2008
    Ort
    24558
    Alter
    39
    Beiträge
    1.356
    mir fällt nur auf das "uint8_t k" eine byte-Variable ist. "k" aber bis < 1000 zählen soll - da ist doch ein dreifacher Überlauf drin, weil byte nur bis 255 zählen kann? Sie kommt also niemals bei <1000 an.

    Viele Grüße

    EDIT: zu lange drin rumgelesen-da war wohl einer schneller mit suchen und schreiben
    "Es ist schwierig, jemanden dazu zu bringen, etwas zu verstehen, wenn er sein Gehalt dafür bekommt, dass er es nicht versteht" [Upton Sinclair] gez-boykott

  4. #4
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    7.551
    ... "uint8_t k" ...
    Ach du liebe Zeit, nun ist mir das ziemlich peinlich.

    Zitat Zitat von HeXPloreR Beitrag anzeigen
    ... zu lange drin rumgelesen ...
    Das könnte mit ein Auslöser des Fehlers gewesen sein. Spät nachts noch schnell was hingewurschtelt, und wenn ich erst mal einen Fehler ein paar Mal überlesen habe, dann passiert mir das manchmal auch noch an Tagen danach.

    Danke. Jetzt bin ich immerhin beruhigt.
    Ciao sagt der JoeamBerg

  5. #5
    Erfahrener Benutzer Roboter Genie Avatar von HeXPloreR
    Registriert seit
    08.07.2008
    Ort
    24558
    Alter
    39
    Beiträge
    1.356
    Drei Dinge die ich bisher hier gelernt habe, aber ich bin ja auch noch ein Greenhorn

    1. Gehe das Programm durch als wäre es nicht Dein eigenes - bei einem fremden Programm hinterfragt man den Wertbereich der Variablen eher, weil man den Gedanken: "das passt, hab ich ja so geschrieben" eher nicht hat.
    Es ist dann mehr so: "Was wurde da gemacht?"

    2. Das was markusj sagte: Funktionen werden nicht ausgeführt-warum? Oder Bedingungen nicht erfüllt-warum?

    3. Durch "Indikatoren" setzen (LED: eintritt an-austritt aus;Terminalausgaben:start Funktion - ende Funktion) = Fehler lokallisieren - darauf ggf 1. anwenden.

    4. Mache einen Pause wenn es nach einer gewissen Zeit nicht läuft, oder nächsten Tag weiter - Bei mir ist es so, das ich ne runde Rad fahre, oder Staubsauge...und plötzlich kommt der Gedanke z.B. Variablen prüfen...zack, keine halbe Stunde später - Fehler gefunden oder nochmehr neue entdeckt

    Viele Grüße
    Geändert von HeXPloreR (28.12.2012 um 12:07 Uhr)
    "Es ist schwierig, jemanden dazu zu bringen, etwas zu verstehen, wenn er sein Gehalt dafür bekommt, dass er es nicht versteht" [Upton Sinclair] gez-boykott

  6. #6
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    20.08.2008
    Ort
    Kandel
    Alter
    29
    Beiträge
    1.220
    Zitat Zitat von oberallgeier Beitrag anzeigen
    Ach du liebe Zeit, nun ist mir das ziemlich peinlich.
    Wo gehobelt wird, fallen Späne

    Eine Anmerkung noch: Mit den richtigen Compilerschaltern bemängelt GCC den Fehler auch selbst:
    warning: comparison is always true due to limited range of data type
    Ich verwende dafür folgende Flags:
    -W -Wall -Wextra -Wundef -Wunreachable-code -Wstrict-prototypes -Winit-self
    Eine alte C-Weisheit sagt, dass Compiler-Warnungen später gerne Mal zu echten Problemen während der Programmlaufzeit werden, das hat sich hier wieder einmal bewahrheitet.

    mfG
    Markus
    Tiny ASURO Library: Thread und sf.net Seite

Ähnliche Themen

  1. Wie sieht euer PC aus(Leistung)
    Von scarred im Forum PC-, Pocket PC, Tablet PC, Smartphone oder Notebook
    Antworten: 261
    Letzter Beitrag: 09.09.2010, 19:48
  2. Antworten: 6
    Letzter Beitrag: 27.05.2010, 00:01
  3. fehlfunktion bei code
    Von Roboman93 im Forum Robby RP6
    Antworten: 20
    Letzter Beitrag: 18.07.2009, 23:39
  4. Wie sieht ein CV0 Videosignal aus
    Von blenderkid im Forum Robby RP6
    Antworten: 1
    Letzter Beitrag: 07.01.2008, 18:05
  5. Antworten: 20
    Letzter Beitrag: 07.02.2007, 20:58

Berechtigungen

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