Hallo allerseits Ich bin im Moment dabei, mir für den AVR eine 1-Wire Routine zuschreiben. Dabei wird ein Master eingesetzt (Tiny 15) und ein Slave (90S2313). Die Routinen stehen schon. aber beim Testen des Reset-Befehls bin ich leider auf folgenden Effekt gestossen: Wenn ich vom Master kontinuierlich einen Reset-Befehl schicke, so soll der Slave dem Master antworten. Das tut er aber nur manchmal! Wenn ich den Bus zwischen den beiden in schneller Folge (von Hand) unterbreche, kommt es nämlich irgendwann dazu, dass der Reset nicht mehr angenommen wird! D.h., auch wenn dann der Bus nicht mehr unterbrochen ist, wird der Reset entweder vom Slave nicht quittiert oder vom Master nicht erkannt! Woran kann das liegen? Kommt da einer der beiden Controller aus dem Takt? Ich hab die Betriebsspannung der beiden µC natürlich mit einem Kondensator abgeblockt. Gruß, Steffen
Softwarefehler. In Deinen Routinen fehlt die entsprechende Fehlertoleranz (z.B. Time-Out Erkennung).
Hallo thkais Wie meinst Du das denn genau? Welche Fehlertoleranz, die für den Bus oder die für mein eigenes Programm? Die Routinen sind so geschrieben, dass sie sich nicht aufhängen, sollte der Bus nicht reagieren - klar, ist ja auch das Reset-Signal. Ich vermute deshalb, Du meinst eher letzteres. Da würde natürlich der Watchdog helfen. Aber ich verstehe nicht, wie es überhaupt zu dem Fehler kommen kann! Wenn ich den Fehler schon auf meinem Experimentier-Board hinbekommen kann, wie sieht das denn erst später im Einsatz aus? Ich kann doch nicht jedes Mal mit dem Watchdog resetten, da bekomme ich ja Datenchaos! Gruß, Steffen
Ok, der Baustein hängt sich tatsächlich auf, und zwar der Empfänger. Aber wie meinst Du das mit "Softwarefehler"? In meinen Routinen hab ich keine einzige Schleife drinnen, in denen er sich aufhängen kann! Nicht eine, die einzige die drin ist, ist im Hauptprogramm und das ist eine Endlosschleife! Dann ist der auftretende Fehler ein Hardwarefehler! Aber kann das sein, kann es am Baustein selbst liegen?
Ohne das Programm zu sehen, kann natürlich keiner Deinen Fehler finden ! Die Resetbedingung besteht ja darin, das eine bestimmte Low-Zeit gesendet wird. D.h. Du must einfach nur die Zeit von der letzten 1->0 Flanke bis zur 0->1 Flanke messen. Eine Delayschleife verbietet sich daher. Du must ja bei jeder 1->0 Flanke von vorn beginnen. Peter
Wenn es ein Hardwarefehler sein sollte, müßte der Controller sich komplett aufhängen. Am einfachsten ist es in diesem Fall, innerhalb der Empfangsroutinen ein Pin zu toggeln, dann kannst Du mit Oszi oder LED sehen, daß sich irgendwas tut - oder eben nicht. Ich dachte auch schon oft, daß irgendwo etwas mit der Hardware nicht stimmt - aber zu 90% wars die Software. Du wirst nicht umhin kommen, genauer zu analysieren, was da los ist. Ohne genaue Kenntnis der Hard- und Software kann man natürlich nur allgemeine Hinweise geben. So ein klein wenig habe ich mit meinem Posting da auch drauf hinweisen wollen ;-)
Ja, genau mit der LED hab ich auch herausgefunden, dass der Empfänger sich aufhängt. Dass die Hardware nicht stimmt, halte ich selbst auch für unwahrscheinlich. Aber anders kann ich mir den Fehler (noch) nicht erklären, außerdem hat der Baustein schon unter meinen Versuchen "gelitten". Ich hab den Source-Code für die Empfangsroutinen angehängt (ohne die erwähnte Test-LED). Es sind zwei Interrupt-Routinen. Der Code funktioniert so, wie Du, Peter, es auch vorgeschlagen hast. Den Pegelwechsel messe ich mit einem Input-Capture (obere Routine), bei einem Reset nehme ich die Reset-Antwort danach bei einem Compare-Match zurück (untere Routine). Ich bin schon gespannt, was ihr dazu sagt! Viele Grüsse, Steffen
Bingo! Ich hab den Fehler gefunden: Wenn er im State "Senden" war, hat er jede High->Low Flanke genommen, und es als Sendetrigger interpretiert. Deshalb hat er dann auch das Reset-Signal als Trigger gesehen, weil er nur auf die Flanke geachtet hat und das eigentliche Signal ignoriert hat. Es war also ein Software-Fehler. Das stimmt aber auch nur zum Teil!! Denn wenn er nicht im State "Senden" war, hätte er einwandfrei funktionieren müssen. Und in meinem Test-Programm, habe ich ihn NICHT in diesen State versetzt. Irgendwie ist er also von selbst (?) dort hingekommen? Wie kann das sein?!? Gruß, Steffen
@Steffen: Kleiner Tip: Du musst bei der Fehlersuche davon ausgehen, dass Du den Fehler gemacht hast, und nicht andere. Die Wahrscheinlichkeit, dass der Fehler nicht bei Dir liegt, ist weit unter 0,01%. Das ist ein rein menschlich, psychologisches Problem, dass beim Programmieren sehr dominant auftritt. Daher beim Fehlersuchen immer mit der Einstellung: "Ich habe einen Fehler gemacht, und ich werde ihn nun finden" suchen, niemals mit der Einstellung "Da kann kein Fehler sein". Mit der falschen psychologischen Einstellung, kannst Du keine Fehler finden. Das ist übrigens durch viele Studien zum Thema Softwarequalität belegt. Nur wenn Du diese menschliche Schwäche kennst, und auch akzeptierst dass Du sie auch hast, so wie ich sie habe, so wie sie jeder Mensch auf dieser Erda hat, nur dann schafst Du es, diese Schwäche auszutricksen. Was auch immer sehr gut hilft, ist jemanden Fremden, Dein Programm mündlich zu erklären. Funktion für Funktion, Zeile für Zeile.
Hallo Michael Du hast vermutlich Recht. Ich bin nur noch nicht so lange dabei, als dass ich wüsste, wie wahrscheinlich Fehler auf Seiten der Hardware sind! Es gibt hier ja viele Möglichkeiten, angefangen bei der Schaltungstechnik (fehlende Abblock-Kondensatoren etc.) über ESD-/EMV-Probleme bis hin zu Produktionsfehlern. Trotzdem hast Du mir mit Deiner Einschätzung am Ende noch mehr weitergeholfen :-) Nachdem ich mir nun zum x-ten Mal das Problem vorgenommen hatte, ist mir eingefallen, dass meine Test-Unterbrechungen des Busses vom Empfänger möglicherweise als Empfangsbits interpretiert werden (Fehler #1). Aus dem Reset wurde so ein Datenbyte zusammengesetzt und den Rest hat mein Testprogramm geregelt. Dort hatte ich nämlich programmiert, dass er sein empfangenes Datenbyte sofort wieder zurücksendet. So hat er seinen State auf "Senden" geschaltet und konnte nicht mehr auf einen Reset reagieren (Fehler #2)! Vielen Dank für Deine Antwort, Michael! Natürlich gilt dieser Dank auch den anderen!! Gruß, Steffen
"Was auch immer sehr gut hilft, ist jemanden Fremden, Dein Programm mündlich zu erklären. Funktion für Funktion, Zeile für Zeile." Das kann ich bestätigen. Derjenige muß nicht mal Ahnung haben, bloß zuhören. Man kann auch jemandem sein scheinbar supergut funktionierendes Programm erklären. Meistens wirds dann aber etwas peinlich, weil man dabei haufenweise Fehler entdeckt und sich zum Schluß echt wundert, warum es überhaupt funktioniert hat (ist mir heute grad passiert). Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.