Werte AVR-Experten, in dem im Anhang gezeigten Programmausschnitt soll der Int0 erst wieder freigegeben werden, wenn H-Pegel am Eingang PB3 anliegt. Dies dauert jedoch erstaunlich lange ca. 2 (zwei) Sekunden bzw. besser formuliert, muss der H-Pegel 2 Sekunden lang anliegen. Weiß jemand, warum dem so ist? Zu erwähnen ist noch, dass der Eingang doppelt belegt ist, die beiden Signale sind jedoch über Dioden entkoppelt. Es liegt immer nur das eine oder das andere Signal an. Rein elektrisch sind die Signale auch sauber und erreichen die normalen L- bzw. H-Pegel. Bin für jede Hilfe dankbar. Enrico
Hi also, ich kann mit deinem Programmausschnitt nicht besonders viel anfangen... Ich sehe keine geschlossene ISR, keine Stackdeklarierung, habe keinen Hinweis, welcher µC. Also, so wird's nix mit der Hilfe... Um trotzdem vielleicht eine kleine Hilfe zu geben, versuche es mal mit folgender Vorgehensweise: Wenn nicht unbedingt notwendig, keine Eingänge in Interrupt erwarten. Polling reicht in den meisten Fällen völlig aus. Die Routine dazu in deiner Programmschleife am Anfang aufrufen. Dann die Bearbeitung. Zum Schluß die Ausgabe. Möglichst kleine Routinen schreiben und gut dokumentieren. Ach ja, wenn du in Assembler programmierst und eine RS 232 zur Verfügung hast, benutze mehr Variablen. Dann kannst du mit OpenEye auf die Werte zugreifen und nachvolziehen, was da falsch läuft. OpenEye ist ein PC Programm, welches dir die Möglichkeit gibt, auf den Variablenbereich zu schauen. Kostet nix, weil ich es mal für mich geschrieben und es dann hier irgendwo zur Verfügung gestellt hab. Gruß oldmax
Hallo oldmax, zuerst danke für den Kommentar. Die eine oder andere Sache werde ich in Zukunft berücksichtigen. Der µC-Typ steht im Betreff. Vielleicht war der Programmausschnitt noch zu groß. Natürlich gibt es eine ISR. Das eigentlich für mich wichtige passiert um das Sprungziel Abfrage3 herum. Meine Frage zielte allein darauf ab, warum der Interupt Int0 erst nach ca. 2 Sekunden anliegen von H-Pegel an Eingang PB3 wieder freigegeben wird. Der µC hat einen Takt von 2,4Mhz. Da sollte das Erkennen das H-Pegels doch wesentlich schneller erfolgen. Es ist garantiert auch nicht so, dass er da mit einem anderen Interupt beschäftigt ist. Die sind nämlich alle abgeschaltet. Gruß Enrico
Enrico Buss schrieb: > Hallo oldmax, > > zuerst danke für den Kommentar. Die eine oder andere Sache werde ich in > Zukunft berücksichtigen. Der µC-Typ steht im Betreff. Vielleicht war der > Programmausschnitt noch zu groß. Eher zu klein. Denn dein Programmausschnitt kann keine 2 Sekunden Verzögerung erklären. Da es diese Verzögerung aber gibt, muss daher das Problem woanders sein. Zb. ist PB3 auf Eingang geschaltet mit einem Pullup? Wird der Pullup irgendwo irrtümlich ausgeschaltet/eingeschaltet? Wie sieht deine Aussenbeschaltung exakt und konkret aus? Deine Fehlerbeschreibung klingt für mich nämlich nach einem Kondensator der irgendwo geladen wird und das Signal verzögert. Aber ich kann diese Hypothese weder beweisen noch widerlegen, weil du mir nichts gibst, womit ich arbeiten könnte. > H-Pegels doch wesentlich schneller erfolgen. Es ist garantiert 'garantiert' glaub ich erst, wenn ich es selber gesehen habe. Wenn du wüsstest, wie viele 'garantiert richtigen Inputs und trotzdem falsche Ergebnisse, also muss die Berechnung fehlerhaft sein' sich im Nachhinein als 'trotz Garantie doch falsche Inputs' herausgestellt haben.
Wenn der Programmablauf in deinem Codeschnippsel linear ist, hängt die Schleife Abfrage3 vom Eingabepin PB3 und der Schleife um Abfrage2 mit Eingabepin PB4 ab. Hast du das Signal an PB4 berücksichtigt? Kannst du an PB2 erkennen ob Abfrage2 überwunden wurde? Der INT0-Interrupt wird erst nach der erfolgreichen Kontrolle des PB3 (und PB4) eingeschaltet und hängt selbst wieder vom Pin INT0 (PB1) ab. Hast du das Signal an PB1 berücksichtigt?. Mittlerweise wären bereits die Timings für drei externe Signale (PB1, PB3, PB4) und ein internes Signal (PB2) fürs Debuggen nützlich... hast du einen Logikanalysator? Aus dem Codeschnippsel geht auch nicht die Schaltung hervor. Bist du sicher, dass du die Pullup-Situation im Griff hast?
Abfrage3: sbis PinB,PB3 ;überspringe naechsten Befehl, wenn Ausgang PB3 gesetzt rjmp Abfrage3 ldi rmp,(1<<ISC01) ; Interrupt INT0 bei fallender Flanke out MCUCR,rmp ldi rmp,(1<<INT0) ; externen INT0 einschalten out GIMSK,rmp Du sperrst den Interrupt solange du den Taster gedrückt hältst, damit der Interrupt erst dann wieder ausgeführt wird, wenn die Taste losgelassen und erneut gedrückt wird. Richtig? Das Problem ist, daß nach dem Loslassen der Taste, diese wie verrückt prellt und erneut einen Interrupt während des Loslassens ausführt. Du musst den Taster entprellen. dann geht das auch. mfg.
Also, ein wenig zur Erläuterung. An den Eingängen PB3 und PB4 sind Initiatoren und an PB3 zusätzlich eine Lichtschranke verschaltet, die bestimmte Positionen einer Mechanik abfragen. Die Pull-Ups sind extern verbaut, da ursprünglich eine diekrete Schaltung verwendet wurde. Ein weiterer Taster an int0 gibt den Programmablauf frei, indem die ISR ein bestimmtes Bit in einem Register setzt und damit das Hauptprogramm nicht mehr übersprungen wird. Der Int0 soll wirklich erst dann wieder freigegeben werden, wenn die Mechanik in Ruhestellung ist (siehe oben). Es sind außer den Siebkondensatoren keine weiteren verbaut. Der Taster ist über ein Monoflop entprellt. Vielleicht fällt ja noch jemandem was ein. Der Programmablauf funktioniert, sowohl in der Simulation als auch praktisch. Nur die 2s stören. Das der Ablauf korrekt ist, kann man sehr schön an der Mechanik erkennen. Grüße Enrico
Poste das komplette Programm. Ansonsten kannst Du keine Hilfe erwarten.
Knut Ballhause schrieb: > Poste das komplette Programm. Ansonsten kannst Du keine Hilfe erwarten. Und die Schaltung. mfg.
Das Programm läuft in der Simulation mit vorgegebenen Signalen (Stimuli) korrekt? Ansonsten: Messen, messen, messen. Entweder trödelt das Programm nicht dort wo du vermutest oder deine Signale sind anders als du vermutest. Vielleicht auch beides.
Die Schaltung ist bei dem erwähnten Problem höchstwahrscheinlich nicht schuld, da die Pulse am Controller sauber ankommen, laut OP.
Hi Nun, wenn du Inis dran hängen hast, werden diese wohl kaum prellen, trotzdem kann auch ein Ini Schaltwechsl haben. Egal, wenn du dieses Signal für eine Reaktion nur einmal brauchst und dann erst beim nächsten Wechsel der Signallage, dann bietet sich eine Flankenauswertung an. In der Initialisierung lädst du dir die Eingänge in eine Variable, nennen wir sie mal old_In. In der ISR liest du ja die Eingänge erneut und nun machst du mit der alten Signallage eine XOr-Verknüpfung. Im Ergebnis stehen nur die geänderten Bits zwischen alter und neuer Signallage. Eine folgende Und-Verknüpfung mit dem aktuell gelesenen Status ergibt ein Flankenbit für den Wechsel von 0 nach 1, eine Und mit dem alten Status einen Wechsel von 1 nach 0 . Danach legst du den aktuellen Status in die Ablage für die nächste Abfrage. Im Hauptprogramm fragst du dann die Flankenbits ab, leitest deine Bearbeitung abhängig davon ein und setzt dieses nach Bearbeitung zurück. So mach ich es jedenfalls und das funktioniert bestens. Gruß oldmax
Ich habe mal aus Spaß an der Freude die Doppelbelegung des PB3 entfernt. Nun funktioniert der Programmablauf tadellos. Scheinbar habe ich mir mit der Doppelbelegung selber einen gemacht. Jetzt muss ich mir nur was einfallen lassen, wie ich den einen Eingang wieder unterbringe. Werde wahrscheinlich einen AVR mit ein paar mehr Eingängen nehmen. Verstehen kann ich die Sache trotzdem nicht, da die Pegel sauber waren, keine Störimpulse drauf waren und die Impulse auch zeitlich weit gnung auseinander sind. Was soll's. Trotzdem was gelernt. Vielen Dank nochmal für die Tipps. Enrico
Enrico Buss schrieb: > Scheinbar habe ich mir mit > der Doppelbelegung selber einen gemacht. Enrico Buss schrieb: > Zu erwähnen ist noch, dass der Eingang doppelt belegt ist, die > beiden Signale sind jedoch über Dioden entkoppelt. Meine Glaskugel sagt, Du hast den Pullup vergessen. Sperren beide Dioden, floatet der Pin lustig vor sich hin. Peter
Bitte 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.