mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Taster an Int0


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe das Forum nach Entprelltipps für Taster durchsucht und auch
einiges gefunden.

Jetzt vielleicht eine dumme Frage:

Wenn ich einen Taster an INT0 (ATTiny12) benutze und der Interrupt bei
steigender Flanke ausgelöst werden soll, muss ich dann den Taster noch
entprellen?

Meiner (noch formbaren) Meinung nach müsste doch der Interrupt bei der
ersten steigenden Flanke ausgelöst werden, egal ob danach der Taster
noch prellt, oder?

Ich lasse mich aber auch belehren.

Danke, Michael.

Autor: Jürgen Berger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
natürlich, durch das Prellen kann es sein, dass deine Interrrupt
Routine mehrfach durchlaufen wird.

Gruss
Jürgen

Autor: Hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der ersten Flanke und bei der nächsten und nächsten und .....

Autor: pripri (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo michael,
guckst du hier
http://www.mikrocontroller.net/wiki/Entprellung
mfg ip

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Quick&dirty Lösung: Pullups aktivieren, 10-100nF parallel zum Taster

Autor: Quark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde auch die Entprellroutine von Peter D.
nehmen.

Farge:
Was passiert denn, wenn ich als erstes in der ISR den
Int. sperre und vor dem reti das Int.-Flag lösche;
natürlich dann den Int. wieder freigebe?
In der Zeit müsste sich das Prellen doch erledigt haben?
Natürlich wird jetzt jdede noch so kleine Störung einen
Tastendruck Int. auslösen.

Quark

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich nehme für Tasten überhaupt keinen Interrupt. Alle 10ms mal
vorbeischaun, ein Timer läuft doch sowieso in fast Programm.

Autor: ...HanneS... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig...

Das Problem ist nur, dass es immer wieder welche gibt, die sich wehren
wie die Zicke am Strick, einen Timer zur globalen Programmsteuerung
einzusetzen.

...

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja,

Danke erstmal für die angeregte Diskussion.

Der Interrupt soll deswegen genommen werden, damit der Tastendruck den
Tiny auch aus dem Sleepmode weckt.

Oder hat da jemand eine bessere Methode?
Da würde ich nämlich auf die Timerlösung umschwenken...

Das "Projekt" sieht folgendermassen aus:
Taster soll LED 5 oder 10 Sekunden einschalten. Wenn in dieser Zeit der
Taster nicht gedrückt wird, soll die LED ausgehen und der Sleepmodus
aktiviert werden.(Welcher mit dem nächsten Druck auf den Taster wieder
verlassen werden soll.


Gruß, Michael.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi,
da ich genau an diesen Punkt mich auch gerade befinde, schreibe ich
auch mal ein paar zeilen dazu.
Ich habe genau wie Michael vor per externem Interrupt, über einen
Taster, den µC in den schlafmodus zu versetzen und ihn auch daraus
wieder zu wecken. Dazu habe ich den Port auf "eingang" und internem
"pull up" konfiguriert und den Taster auf der anderen seite an Masse
geschlossen(Low-level interrupt). Bei meinem ATmega169, mit 4MHz
getaktet, (*1) ist hierbei laut Datenblatt zu beachten, daß der zum
wecken verwendete externe Interrupt INT0 nur durch "LOW Level
detection" asynchron aufgerufen werden kann. D.h., daß gerade mal im
"idle" Modus der benötigte Takt "I/O clk" für eine
Flankengesteuerte Interrupterkennung vorhanden ist. Beim ATmega169
heißt das (*1), alle sleep modies erfordern eine Level gesteuerte
Interrupterkennung.
Leider hat dies auch zur Folge, daß der Interrupt fortwährend erkannt
wird wie ein "Low Level" vorhanden ist, sprich: der Taster gedrückt
ist. Dazu habe ich als Experiment mal nur eine globale Variable in der
ISR inkrementieren lassen "int_counter++;" und sie dann ausgeben
lassen. Ergebnis: durch ein normales Taster betätigen, wird die ISR
rund 10000 mal aufgerufen. Hierbei spielt das Taster Prellen eher
weniger die Rolle, dafür ist das entstehende Problem, der immer wieder
aufrufen der ISR, aber umso gravierender.
Zur Lösung fallen mir nur 2 Ansätze ein:
a) das verhindern des wiederholten Aufrufes der ISR , oder
b) das verhindern des wiederholten Codeausführen in der ISR .

Ich habe mich für zweiteres entschieden. Dazu später evtl. mehr.

mfg Sebastian

(*1): wahrscheinlich bei den anderen AVRs auch
ISR: Interrupt Service Routine, Interrupt handler

Autor: ...HanneS... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn man den Low-Level-Int "nur" zum Wecken nimmt??

Also der AVR macht seine Arbeit, gesteuert vom Timer-Int. Wenn er
hinterher ist und nix mehr anliegt (Erkennung folgt weiter unten),
löscht die "Gute-Nacht-Prozedur" das Int-Flag für Ext-Intin GIFR ,
aktiviert danach den Int in GIMSK und schickt den AVR schlafen.

Bei Tastendruck wird der AVR geweckt und die zugehörige ISR aufgerufen.
In dieser wird der ext-Int erstmal wieder deaktiviert (GIMSK). Das Flag
in GIFR wird dann vor dem nächsten Aktivieren erst wieder gelöscht.

Dann kann der Timer wieder arbeiten und in seinen nächsten "Runden"
die Taste sicher erkennen und entprellen und das zugehörige Flag für
das Hauptprogramm setzen. Weiterhin zählt der Timer ein weiteres
Register runter, das bei Erreichen von 0 die "Gute-Nacht-Prozedur"
aufruft. Dieses Register wird von allen aktiven Teilen des Programms
gelöscht (oder auf einen definierten Wert gesetzt, falls 256
Warterunden zu "verschwenderisch" sein sollten), so dass es nur dann
0 werden kann, wenn 256 (oder so) Timerrunden stattgefunden haben, in
denen das Hauptprogramm nix mehr zu tun hatte.

Somit hat man eine sauber entprellte Taste und kann den AVR trotzdem
schlafen schicken.

Da der Schlafmodus ja zum Stromsparen genutzt wird, kommt nun die
Frage, ob denn auch der Analogcomparator deaktiviert wurde...

...

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hört sich ja interessant an.
Aber wenn ich das aber richtig verstanden habe, dann kann ich - während
meine LED-Prozedur läuft - keine weiteren Tastendrücke (sprich
Interrupts) erkennen, sondern erst, wenn die Prozedur durchlaufen wurde
und der AVR auf den Schlafmodus wartet ?!?

und ja ... er wurde... er wurde... ;)

Autor: ...HanneS... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Während dein Programm (was immer es auch tut) läuft, löscht es immer
wieder das Register, was zum "Einschlafen" Null werden muss. Daher
kann der AVR nicht pennen gehen, solange "Arbeit anliegt". Und
solange tuckert auch der Timer und kann mit einer in dem Timer-ISR
laufenden Entprellroutine weitere Tastendrücke abfragen.

Erst wenn dein Programm fertig ist wird der "Einschlafzähler" nicht
mehr gelöscht und kann ablaufen.

Wenn dann schonmal eine Timer-ISR periodisch aufgerufen wird, dann kann
sie auch die gesamte LED-Steuerung übernehmen. Dinge wie Lauflicht,
Ausgabe von Zuständen über blinkende LEDs usw. mach ich grundsätzlich
in der Timer-ISR. Viele meiner Programme haben als Main nur RJMP main,
da das gesamte Hauptprogramm in der Timer-ISR läuft.
Dort kann man auch ein weiteres Zählregister mitlaufen lassen, welches
darüber entscheidet, welche Programmteile in der jeweiligen "Runde"
ausgeführt oder übersprungen werden. Damit erreicht man eine
"Zeitscheibe", die die anliegenden Arbeiten halbwegs gleichmäßig
verteilen kann. Z.B. Multiplexen eines mehrstelligen
LED-Zifferndisplay, Tastaturabfrage, PWM-Erzeugung ADC-Auslesen... -
Alles in der Timer-ISR, aber alles zu seiner Zeit. Sollten
zeitaufwendige Berechnungen nötig sein, dann kann man diese im
Hauptprogramm (zwischen den ISR-Aufrufen) ausführen, gesteuert über
Flags, die von der Timer-ISR gesetzt werden und vom Hauptprogramm nach
Erledigung des Jobs wieder gelöscht werden.

...

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@CrazyHorse:
"ich nehme für Tasten überhaupt keinen Interrupt. Alle 10ms mal
vorbeischaun, ein Timer läuft doch sowieso in fast Programm."

Es gibt auch Leute, bei denen alle Timer mit anderen Dingen beschäftigt
sind. Die Idee, asynchrone spodradisch auftretende Vorgänge mit einem
Interrupt zu behandeln, ist guter Programmierstil. Genau für so etwas
sind Interrupts schließlich da! ;)


Gruß, Michael

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, danke. So langsam dämmerts.
Ich werde wohl mein Programmdesign komplett überarbeiten müssen, aber
das scheint mir doch sinnvoll zu sein.

Nochmal eine Frage zum externen INT0:

(Ich kenne nur den Tiny12, denke aber, dass das bei den "größeren"
genauso ist...)
Ich hatte vor, den ext. INT über die steigende Flanke zu triggern.
Sebastian (s.o.) hat einen Low-level. Macht das einen Unterschied?
Gibts da Vor- oder Nachteile?
Bei Sebastian müsste doch der INPUT dann (Wenn der Taster nicht
gedrückt ist) an Vcc liegen, oder?
Nimmt der AVR dann im Schlafmodus hier auch Strom auf?

Danke und Gruß, Michael.

Autor: ...HanneS... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Flanke kann nicht wecken, da Flanke Takt voraussetzt. Takt ist aber
abgeschaltet wenn der AVR schläft...

Du musst also den Low-Level nehmen.

Da der AVR Spannung hat, nimmt er keinen zusätzlichen Strom auf, wenn
Pins auf H liegen.

...

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@MSE
Über "guten Programmierstil" kann man sicher streiten.
Externe Ints sind für mich wertvolle Resourcen, die ich nicht an einen
Taster verschwende (den hier beschriebenen Fall zum Aufwecken nehme ich
davon mal aus).
Ich baue ein Programm meist folgendermassen auf:
Ein Timer (der Timer0) liefert den Grundtakt für das gesamte Programm,
welche Zeit man dafür nimmt, hängt vom konkreten Fall ab. Daraus leite
ich über Zähler in der main diverse Aktionen aus, im einfachsten Fall
ist das ein linearer Ablauf in main.
while (!timer_ready);   //wird vom Timer0-Int gesetzt
timer_ready=0;
.
.
.Der Rest der Programms
Vorteil der Sache: definierte, konstante Abarbeitungszyklen, auch nach
Änderungen im Programm. Das ist mir wichtiger als min. mögliche
Programmlaufzeit.
Und in dem Zuge frage ich auch  Schalter/Taster mit ab, die
Prozessorbelastung dafür ist minimal. Wie du das siehst, ist mir
herzlich egal, ich bin damit immer gut gefahren. Und es ist ja auch
kein Dogma - wenn es wirklich mal so schnell wie möglich sein muss,
kann man es ja auch weglassen. Aber eigentlich ist es immer so, dass
der MC sowieso irgendwo warten muss.

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@CrazyHorse:
Bei mir wartet der MC oft nicht sondern arbeitet durch. Es kommt auf
die Anwendung an, was gerade am günstigsten ist. Dein Ansatz hat sicher
in vielen Fällen Vorteile.

Gruß, Michael

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sag mir mal ein Beispiel, in welchem du 100% Auslastung hast. Ich kann
mir keins vorstellen bzw. würde zu dem Schluss kommen, dass ich den
falschen MC/zu geringe Taktfrequenz/zu hohe Programmlaufzeit habe.

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du hast recht, 100 % sind es nicht. Er hat aber trotzdem gut zu tun.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, ~90% komme ich auch manchmal, das ist aber schon fast der
Grenzwert, den ich noch tolerieren würde, ich mag es nicht, im
Grenzbereich zu arbeiten, kleine Erweiterungen können dann das ganze
Design kippen.
Und wenn die Abarbeitung der main max. 9ms dauert, was spricht dann
dagegen, die mit 10ms zu synchronisieren? Baue ich noch Kleinkram ein,
bleibt es bei den 10ms, zur Not könnte ich problemlos auf 15 oder 20ms
wechseln. Oder aber aufteilen, wenn grössere Berechnungen anzustellen
sind. In den ersten 10ms läuft eine Berechnung, beim nächsten Mal die
andere. Es gibt auch Fälle, bei denen die Laufzeit von Programmteilen
abhängig ist von den Eingangsparametern, das kann auch sehr unschöne
Effekte hervorbringen
Allgemeingültig kann man das alles nicht sagen, es gibt sicher Fälle,
wo man davon abweichen muss, ist aber relativ selten. Wie gesagt,
persönliche Vorlieben tun auch einiges zur Sache, mir persönlich ist
ein geordnetes Zeitregime viel Wert.
Und zur Anzahl der Timer: 10.000ende von Projekten mussten sich mit
einem Timer (Standard-8051, der 2. ging meist für die serielle
Schnittstelle drauf) zufrieden geben, und das ging und geht auch heute
noch. Insofern bin ich mit dem AVR mit freiem Timer1 und (meist
vorhanden Timer2) gut bestückt, wenn der Timer0 das Programm steuert.
Und nebenbei kann er ja weiterhin übliche Timeraufgaben übernehmen, das
entfällt ja deswegen nicht.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@HanneS : ok. Low-level-int

nur um da nichts falsch zu machen:
Ich gebe also (Beim TINY12) die Vcc auf Pin 6 (IN2) und 8 und schalte
den internen Pullup dazu.

Dann Taste ich die Vcc gegen Masse und der AVR erwacht.
Alles richtig so?


Nochmals Danke. Das ist alles sehr aufschlussreich für mich.
Michael.

Autor: ...HanneS... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Quatsch! - hätte ich beinahe gesagt...

Du legst Vcc auf Pin 8, dein interner Pullup zieht den Int-Eingang auf
H, dein Taster beim Betätigen auf L.

Würdest du da Vcc anlegen, würde dein Taster einen Kurzschluss
verursachen.

...

@Crazy: Es gibt Controller, deren Rechenzeit zu 100% ausgelastet ist.
Und zwar mit Warteschleifen, da man sich vor der Verwendung eines
Timers drückt (kennichnich, essichnich...)

;-)

...

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, Danke! Das hätte bestimmt schön gekokelt...
Wie sieht denn dann das ganze aus, wenn man statt eines Schließers
einen Öffner nimmt?

Dann sollte doch der interne Pullup abgeschaltet sein, damit er nicht
direkt an Vcc liegt, sondern nur, wenn der Öffner in Ruhestellung ist,
oder?
Dann müsste man einen externen Widerstand zwischen Vcc und Öffner-Pin6
packen. Aber wie kommt dann die Masse ins Spiel?

Ich hoffe, dann habe ichs gerafft...

Gruß, Michael.

Autor: ...HanneS... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der Schalter/Tester einen Pegelwechsel verursachen soll, dann muss
durch den geschlossenen Kontakt Strom fließen. Strom kostet meist Geld,
also wäre es töricht, den Strom im unbetätigten Zustand zu verheizen.

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@CrazyHorse:
Da wir neulich darüber sprachen:
Ich habe jetzt ein Problem, bei dem der Controller 24 h am Tag fleißig
vor sich hin arbeiten soll und alle paar Tage wird vielleicht einmal
eine Taste betätigt. In so einem Fall scheint es mir nicht
unvernünftig, die Eingabe über einen Interrupt zu detektieren und nicht
irgendwelche Polling-Abfragen durchzuführen, die zu 99,99% der Laufzeit
stets mit negativem Ergebnis enden.


Gruß, Michael

PS: Ich will damit nichts gegen die von Dir aufgeführten Konzepte
sagen, die lesen sich durchaus schlüssig und sind bestimmt bei Geräten,
die häufig bedient werden, nicht verkehrt!

Autor: Santa Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>der Controller 24 h am Tag fleißig
>vor sich hin arbeiten soll und alle paar Tage wird vielleicht einmal
>eine Taste betätigt. In so einem Fall scheint es mir nicht
>unvernünftig, die Eingabe über einen Interrupt zu detektieren und
nicht
>irgendwelche Polling-Abfragen durchzuführen, die zu 99,99% der
Laufzeit
>stets mit negativem Ergebnis enden.

Solange eine Abfrage praktisch überhaupt keine Rechenleistung benötigt,
wie das bei Tastenpolling der Fall ist (*), ist es doch völlig wurscht,
wie groß der Anteil an positiven und negativen Ergebnissen ist!?

(*) Abschätzung: Tasten mögen alle 10 ms abgefragt werden; die
Abfrageroutine hat 50 Instruktionen --> ca. 100 Taktzyklen --> bei 8
MHz Systemtakt ist die Routine innerhalb 12.5 µs abgearbeitet.  12.5 µs
/ 10 ms = 0.00125.  Ergebnis: Das Tastenabfragen kostet stolze 0.125 %
der gesamten Rechenleistung.

Autor: ...HanneS... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig... Aber:

Er möchte doch den Controller in den Tiefschlaf versetzen um Strom zu
sparen (Batterie). Deshalb auch der Low-Level-Int zum Wecken.

...

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich zitiere mich mal selbst:
"Externe Ints sind für mich wertvolle Resourcen, die ich nicht an
einen
Taster verschwende (den hier beschriebenen Fall zum Aufwecken nehme
ich
davon mal aus)."

@MSE:

-Du musst den Schalter entprellen  (dann wartest du in der ISR und
blockierst die restlichen Ints??)
-ansonsten kann dir ein einziger Tastendruck ganz viele Interrupts
auslösen (was dann wiederum einen Timer oder Warteschleifen verlangt,
um die zu umgehen).
-was machst du, wenn ein 2. oder 3. oder noch mehr Taster hinzukommen?

Summa summarum: nichts gewonnen, Vorteile verspielt, schlechtes
Geschäft gemacht.
Und, wie schon gesagt, kann doch jeder machen, wie er will, solange es
funktioniert. Ich will dich nicht bekehren, aber deine Lösung hat keine
Vorteile.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.