Hallo In der Fachhochschule haben wir einen kleinen Roboter, der vorne einen Taster hat. Der hängt an INT0 von einem mega32. In der Interruptroutine fährt der Roboter erst rückwärts und dreht sich dann - dauert ca 1s. Das Problem ist, dass die Interruptroutine immer 2x ausgeführt wird. (Der Taster hängt über einen Pullup an 5V und ich warte auf eine fallende Flanke). Am Anfang der Interruptroutine habe ich den INT0 schon deaktiviert und am Ende INTF0 im GIFR gelöscht, hilft aber nichts. Kann es sein, das der Controller während er die Interruptroutine aus- führt, eine weitere fallende Flanke speichert? Gruß triple2448
Ja, die Abarbeitung des Interrupts(zurückfahren und drehen)dauert ca 1s , danach sollte nichts mehr prellen.
mit dem entprellen ist das so eine sache. Hatte ein ähnliches problem. Wie ist er bei dir entprtellt?...
So wie du es beschieben hast wird der Interrupt zweimal ausgeführt da er zweimal angestossen wird und das warscheinlich durch Tastenprellen. Wie schaut den das Tastenentprellen bei dir aus?
Wie oben gesagt: Wenn eine fallende Flane auftritt springt der in die Interruptroutine, deren "Abarbeitung" wegen Warteschleifen ca 1s dauert, alle weiteren Flanken sollten dabei unter den Tisch fallen. Zur Sicherheit lösche ich das INTF0-Flag. Wenn die routine verlassen wird ist der Roboter schon längst weg von der Wand und deswegen prellt da auch nichts mehr
Wie löschst Du das INTF0-Flag? Nur sicherheitshalber: Um es zu löschen, musst Du eine "1" schreiben, es also setzen.
Muss ein tolles Programm sein das in der Interruptroutine eine Warteschleife hat, aber du wirst schon wissen was du machst. Ich würde statt Interrupt vergewaltigen und unterdrücken lieber den Taster entprellen.
Ich habe noch nie Taster entprellt und meine Programme funktionieren trotzdem. Was mache ich falsch? Über den Sinn und Zweck eines 1-sekündigen Interrupts läßt sich sicherlich streiten, aber vielleicht läßt sich auf diese Weise relativ einfach die Funktion eines Interrupts erklären? Kooperatives Multitasking kommt dann ein Jahr später.
Ich habe anfangs auch keine Taster entprellt, habe sie aber gepollt, also im Timer-Interrupt abgefragt. Das funktionierte recht gut. Aber mit der (ressourcenschonenden) Entprellung nach Peter Dannegger funktioniert es besser... Dass man an einer FH mechanische Taster an einen Interrupt-Eingang hängt, kann ich irgendwie nicht verstehen. Sowas Unsinniges macht man ja nichtmal als einfacher Bastler. Oder hat das didaktische Gründe, um zu zeigen, wie man es nicht machen soll? Gleiches gilt für Warteschleifen in einer ISR. Das ist Gift für jedes Programm... ...
könnte es daran liegen, dass du in der int routine den int zwar sperrst, aber dass bei erneutem EXT INT das flag gesetzt wird, dass ein weiterer INT aktiv war? evtl solltest du mal das EXT INT Flag in deiner INT Routine löschen gruss
@Hannes Warum darf ein Taster nicht an einem externen Interrupteingang hängen?
Das wurde hier im Forum schon zigmal durchgekaut. Einfach mal etwas herumstöbern und lesen... ...
@Hannes: Das verstehe ich in der Tat auch nicht. Ein mechanischer Taster am Interrupt-Eingang ist doch gar kein Problem. Ein 10nF-100nF Kondensator parallel zum Taster ist übrigens weitaus Ressourcenschonender, da brauchts gar keine Entprellungssoftware. Und eine Tastaturmatrix frage ich per Timer-Interrupt ab - da entfällt die Entprellung dann auch. @Jens D.: Er sperrt nicht den Interrupt, sondern löscht das zugehörige Flag (INTF0).
Eine universelle Entprellung im Timerinterrupt hat schon erhebliche Vorteile: Man fügt sie einmal ein und schon ist sämtliche Entprellung Schnee von gestern, d.h. man braucht nie wieder darüber nachdenken. Dagegen ist eine Entprellung über Interrupts und Programmlaufzeiten immer neu zu überdenken, bei jedem neuen Projekt und bei jeder Programmänderung. Prinzipiell ist es aber möglich und ich will niemanden hindern, jedesmal neu Gehirnschmalz zu investieren oder solche Fragen zu stellen: "Ich habe beide Interrupts belegt und brauche nun aber noch eine 3. Taste". Wie kommt es nun zu der Doppelauslösung ? Ganz einfach, der erste Preller entert den Interrupt, der löscht das Interruptflag und die folgenden Preller setzen es wieder. Sobald also der Interrupt nach 1s wieder freigegeben wird, muß also der Handler nochmals durchlaufen werden, damit das durch die Preller gesetzte Flag wieder gelöscht wird. Es ist vollkommen wurscht, wann die Flanke erkannt und das Flag gesetzt wurde. Wenn der Interrupt erst nach einem Jahr freigegeben wird, wird eben erst nach einem Jahr auf den Flankenwechsel reagiert. Man braucht auch nie den Interrupt freigeben, man kann das Flag auch pollen und per Software rücksetzen. Um nun solche uralten Ereignisse zu ignorieren, löscht man das Flag per Software direkt bevor man den Interrupt wieder freigibt.
1 | GIFR = 1<<INTF0; // Flag löschen |
2 | GICR |= 1<<INT0; // Interrupt freigeben |
Peter
@Hannes ... komische Antwort, naja ... Die Forensuche gibts ja wohl nicht mehr und das was ich bekomme, wenn ich die aktuelle Suche benutze, ist nicht wirklich brauchbar. Also wenn der einzige Grund ist, dass es schon mal gekaut wurde, dann hänge ich meine wichtigen Kontakte weiterhin scham- und bedenkenlos an die externen Interrupteingänge, wie ich es mal an der FH gelernt habe. Bisher hatte ich keine Probleme damit.
am unteren Ende der Seite steht immer "ältere Beiträge>>>" oder so ähnlich. das hilft manchmal auch. Eigentlich schade, dass Andreas die Forensuche abgeschaltet hat, wobei ich mit Hilfe der google-Suche auch schon Sachen gefunden habe...
> ... komische Antwort, naja ... Stimmt... Aber aufgrund der deaktivierten Suchfunktion finde ich das auch nicht mehr. Es war aber nicht nur einmal, sondern ziemlich oft. Leider nicht am Betreff erkennbar. Wenn du deine Taster weiter an die externen Interrupt hängst, ist das nicht meine Sache, ich muss ja deine Geräte nicht kaufen. Ich mache es aber nur dann so, wenn ich den AVR mit dem Taster aus dem Power-Down-Mode holen muss. Und dann auch nur zum Wecken aus dem "Tiefschlaf", die eigentliche Abfrage und Entprellung der Taster übernimmt dann die Timer-ISR. Damit ist man dann alle Sorgen los. Hast du dir die Entprellroutine überhaupt man angesehen (und analysiert)? Oder diskutierst du über (gegen) etwas, was du garnicht kennst? ...
@Hannes Ich wusste gar nicht dass ich überhaupt über die Entprellroutine diskutiert habe?! Ich wollte doch gar nichts von der Routine?! Ich wollte doch bloß wissen warum man Taster nicht an die externen Interrupts anschließen soll?? Wieso muss ich jetzt dafür angepisst werden?
Sorry, wenn du das als "Anpissen" empfindest... Aber die einfach erscheinende Frage: > Warum darf ein Taster nicht an einem externen Interrupteingang > hängen? kann man nicht mal schnell mit 12 Zeilen beantworten, dazu ist die Materie zu komplex. Daher empfand ich deine Frage als (bewusst naiv formulierte) Provokation. Da muss du sich also nicht wundern, wenn darauf verwiesen wird, sich mal im Forum etwas umzusehen. Denn das Thema ist wirklich oftmals bis zum Abwinken diskutiert worden. Übrigens: Der Taster "DARF" am Interrupt hängen, er "SOLLTE" es (meiner Meinung nach) aber nicht ohne zwingenden Grund. Suche mal in der Artikelsammlung nach "Entprellung" und verfolge mal die dort aufgelisteten Links, dann verstehst du, was ich meine, ohne dass ich das alles nochmal "für dich persönlich" aufschreiben muss. ...
@Hannes Das ist mir zu hoch. Erst erklärst Du meine Dozenten zu Trotteln, dann ist Dir meine Frage zu trival oder naiv für die komplexe, mehr als 12-zeilige Antwort, drum wirfst Du mir Unkenntnis der Entprellroutine vor, die ich gar nicht in Abrede gestellt habe, dann machst Du meine Produke madig die Du gar nicht kennst ... Da komm ich nicht mit und es ist auch nur Zeitverschwendung. Scheinbar geht es nur um das Entprellen.
@Cerberus: Solange der Controller sowieso läuft, kann man den Taster meistens auch im Rahmen eines Timer-Interrupt pollen (ms-Bereich). Soviel Zeit hat man immer. Wie Hannes schon schrieb, kann man einen Controller per Interrupt aufwecken. Dafür muß man den Taster dann and den INT-Pin hängen. Warum fragst du deine Dozenten nicht mal danach, wieso sie Tasten an einen INT-Pin hängen? Offensichtlich führt das ja zu Problemen, wie Bastian sie hat.
@Rahul Es ist nur eine Frage der Betrachtungsweise. Bastians Problem ist, dass er den Taster nicht entprellt hat. Ich finde es spielt keine Rolle, ob es ein Interrupt-Eingang ist. Der Fehler fällt nur schneller und regelmäßiger auf, denn das Problem besteht auch bei jedem anderen Eingang, sofern ein mechanischer Schalter im Spiel ist. Ich halte mich weiterhin an die Grundlagen der digitalen Schaltungstechnik. Nur weil man in der Software der uCs grobe Nachlässigkeiten der Hardware "wegschminken" kann, ist das doch kein Grund sowas zur Maxime zu erheben mit der Einschränkung, das man externe Interrups nicht an mechanische Schalter anschließt.
@cerberus, "Nur weil man in der Software der uCs grobe Nachlässigkeiten der Hardware "wegschminken" kann" Was ist daran nachlässig, Hardware durch ein paar Zeilen Software zu ersetzen ? Die Hardware (Kondensator) muß ich jedesmal einlöten, kostet also bei jedem Gerät. Die Software muß ich nur einmal schreiben und kostet dann nix mehr. Wenn ich also Hardware durch Software einsparen kann, dann tue ich das auch. Peter
@peter Wenn das so geplant ist, kann das doch ok sein. Ich habe es mal anders gelernt und das macht für mich mehr Sinn als die generelle Softwarelösung, womit ich nicht sagen will das die Softwarelösung schlechter oder besser ist. Ich möchte niemanden von meiner Methode überzeugen. Das Hühnerfutter macht die Schaltung nicht wirklich teuer und schützt nicht nur vor den den Prell-Impulsen. Ich baue Industrietechnik und was würden meine Kunden wohl sagen, wenn ich ihnen sage, dass sie die Readkontakte oder Maschinentaster in der Software entprellen sollen? Sowas kann ich nicht verkaufen.
@thkais <<Ein 10nF-100nF Kondensator parallel zum Taster ist übrigens weitaus Ressourcenschonender, da brauchts gar keine Entprellungssoftware. Und eine Tastaturmatrix frage ich per Timer-Interrupt ab - da entfällt die Entprellung dann auch.>> Falsch...ein Kondensator parallel zum Taster ist für denselben alles andere als schonend...es sei denn man hängt noch einen Widerstand dazwischen. Bei jedem Drücken fließt ein ein ziemlich hoher Entladestrom über den Taster...dieser killt mit der Zeit die Kontakte. Übrigens: Sinn eines Mikrocontrollers ist es Hardware zu sparen. Mit einer Entprellroutine kann man sich das ganze o.g. R-C-Gerödel sparen und spart somit auch Platz auf der Platine und Arbeit(wie Peter schon sagte). @cerberus Du machst mehr Theater ums Prinzip als um das wirkliche Problem: nämlich dass der Taster prellt. Zu Deinen Dozenten: Die haben meistens keine Praxiserfahrung..woher denn auch? Die haben das Zeug von deren Dozenten beigebracht bekommen und haben es eben so weitergegeben....Schade. Daniel
@cerberus, "Ich baue Industrietechnik und was würden meine Kunden wohl sagen, wenn ich ihnen sage, dass sie die Readkontakte oder Maschinentaster in der Software entprellen sollen?" Sie würden sagen: "Aber das ist doch normal, daß man immer damit rechnen muß, daß alle Signale von außen gestört sein können". Anders könnte man doch gar nicht zuverlässige Systeme programmieren. Einen Industrieprogrammierer, der nicht mal entprellen kann, würde ich feuern oder nen Besen in die Hand drücken, der hat einfach seine Hausaufgaben nicht gemacht. Peter
@Daniel: Für viele Kontakte ist dieser Strom sogar notwendig, um sie überhaupt funktionsfähig zu halten. Die zwangsläufig entstehende Oxidschicht wird "weggebrannt", der Kontakt gereinigt. Ist ein häufiges Problem: Kontakte funktionierten wunderbar in Relais- und Schützschaltungen, wurden die gleichen Kontakte an eine SPS angeschlossen, sind sie nach einem vierteljahr nicht mehr funktionstüchtig (kommt natürlich aufs Kontaktmaterial an). Zeig mir einen Kontakt, der durch den hohen Entladestrom des Kondensators zerstört wurde, und ich zeige Dir 100, die durch einen zu geringen Strom nicht mehr funktionieren (kann Dich totwerfen mit den Dingern, aus einer Rückrufaktion - da wurde anstelle Gold- eine Wolframbeschichtung geliefert). Mit "ressourcenschonend" meinte ich übrigens Softwareaufwand (geht aus dem Kontext der vorhergehenden Postings hervor). @Peter (1. Posting): Genau das wirds sein. In diesem Spezialfall würde also das Rücksetzen des Interrupts am Ende der Wenderoutine das Problem lösen. Wenn auch nicht sehr sauber. Die Abfrage in einem Timer-Interrupt ist auf jeden Fall universeller.
@Peter << Sie würden sagen: "Aber das ist doch normal, daß man immer damit rechnen muß, daß alle Signale von außen gestört sein können". >> Das ist doch nicht wirklich Peter Dannegger, oder? Und ist Peter nicht registrierter user?
@tex "Das ist doch nicht wirklich Peter Dannegger, oder?" Was stört Dich daran ? Wenn man immer beachtet, daß die Welt draußen nunmal rauh ist, dann kann man wesentlich zuverlässiger entwickeln. Ich habs nicht immer so gehalten und wurde dafür mit Tagen vorm Oszilloskop bestraft, um Störungen auf die Spur zu kommen und dann nachträglich alle möglichen und unmöglichen Abschirmmaßnahmen dranzupfrimeln. Die Debouncerroutine entprellt nicht nur, sondern unterdrückt auch Spikes. Auch wenn ich ne prellfreie digitale Quelle habe, die aber über ne längere Leitung an die Steuerung angeschlossen ist, dann lasse ich das Signal erstmal durch den Debouncer laufen, damit es frei von Spikes ist. Der Kunde findet das nämlich gar nicht so lustig, wenn er z.B. den Lichtschalter betätigt und die Steuerung spielt durch diesen Schaltimpuls verrückt. Halte mal nen Oszilloskoptastspitze in die Luft und gucke Dir mal an, was da so an Elektrosmog durch die Gegend wabert. Und wenn überall RFID, Blauzahn, UMTS usw. umherfunken, wirds nur noch schlimmer. 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.