ATmega8, Assembler- Programm fehler oder Taster entprellen?

Praktisch alle mechanischen Taster prellen. Es hilft also nichts, man 
muss sich etwas zum Entprellen einfallen lassen - das geht auch in 
Software.

Simon K. schrieb:
> Liegt das am Programm oder am Taster ?

 So etwas nennt sich Tasterprellen und dauert so bis 40-50mS.
 Wenn Taster gedruckt - LCD schieben, 50mS warten und dann erst auf
 losgelassenen Taster abfragen.

>   rcall  shift_left
 --- rcall  Delay_50mS
>  sbic  PINB, 0    ;S1=GEDRÜCKT

>  So etwas nennt sich Tasterprellen und dauert so bis 40-50mS.
>  Wenn Taster gedruckt - LCD schieben, 50mS warten und dann erst auf
>  losgelassenen Taster abfragen.
>
>>   rcall  shift_left
>  --- rcall  Delay_50mS
>>  sbic  PINB, 0    ;S1=GEDRÜCKT

Ja hab mal nen delay eingefügt. Jetzt schiebt er 1 Zeichen nach links 
und dann geht ca. 5-50mal drücken garnichts mehr, auch wenn ich 4-5 min 
warte.. nichts :D

Simon K. schrieb:
> Ja hab mal nen delay eingefügt. Jetzt schiebt er 1 Zeichen nach links
> und dann geht ca. 5-50mal drücken garnichts mehr, auch wenn ich 4-5 min
> warte.. nichts :D

 Aus einem anderen T:
spess53 schrieb:
> Abgesehen von solchen unwichtigen Informationen wie Taster L-/H-aktiv

 Okay, probieren:

links:
  sbic  PINB, 0    ;S1=GEDRÜCKT
  rjmp  links
  rcall  shift_left
  rcall  Delay_50mS
wait:
  sbis  PINB, 0    ;S1=UNGEDRÜCKT
  rjmp  wait
  rjmp  links

Marc Vesely schrieb:
> Aus einem anderen T:
> spess53 schrieb:
>> Abgesehen von solchen unwichtigen Informationen wie Taster L-/H-aktiv

Was soll mir das sagen ?

Marc Vesely schrieb:
> Okay, probieren:

Springt weiter mehrere schritte nach links mal beim drücken mal beim 
loslassen mal beides..

Simon K. schrieb:
> Springt weiter mehrere schritte nach links mal beim drücken mal beim
> loslassen mal beides..

 Delay verlängern oder anständiges Taster einsetzen.

Hast Du den Ziehwiderstand dort eingeschaltet, wo der Taster dran ist?

MfG Paul

Benni schrieb:
> Warum nennt hier keiner den Standard: einen Kondensator über den Taster
> löten.

 Wenn sein Taster mit 50ms Delay prellt, ist höchste Zeit für einen
 neuen.

Benni frog:
> Warum nennt hier keiner den Standard: einen Kondensator über den
> Taster löten.

Das ist nicht der Standard, das verursacht nur Sackgang.

MfG Paul

Das analoge Entprellen mit Kondensator, Widerstand (Pullup) und 
Schmidt-trigger  (= AVR Eingänge) ist wegen der relativ kleinen 
Hysterese am AVR nicht so einfach.

Man kann es aber auch gut ganz in Software machen - daa Delay ist schon 
ein möglicher Weg. 50 ms sind da schon recht lang, 5-10 ms sollten 
ausreichen. Das Delay wird man aber auch an beiden Flanken brauchen, 
also nicht nur beim Warten auf gedrückt, sondern auch beim Warten auf 
losgelassen - auch da können einige Taster prellen.

Ulrich H. schrieb:
> also nicht nur beim Warten auf gedrückt, sondern auch beim Warten auf
> losgelassen - auch da können einige Taster prellen.

 Ja, aber hier wird das weitgehend mit LCD schieben und Delay
 aufgefangen, es kann schlimmstenfalls beim loslassen nur 1 zeichen
 mehr geschoben werden, aber niemals mehrere hintereinander.
 Mit anständigem Taster natürlich...

Bau mal eine Schleife ein die ohne Taster jede (halbe) Sekunde ein Feld 
weiterrückt und am Ende entweder auf Start geht und weitermacht oder die 
Richtung ändert.

Nur mal um sicherzustellen ob es wirklich am Taster liegt.

Umgekehrt die Tasterfunktion benutzen um eine LED auf Knopfdruck zu 
invertieren: leuchtet, leuchtet nicht, leuchtet...?

Divide an Conquer: Zerlegen und Funktionen systematisch und unabhängig 
voneinander testen. Dann weiß man wenigstens mit Sicherheit in welcher 
Programmhälfte der Fehler liegt, ohne den ganzen Code Zeile für Zeile 
auf Bugs und Glitches analysieren zu müssen.

Okay mach ich mich gleich dran muss eben noch was erledigen

Mit einer Schleife von 0,5 s funkioniert es einwandfrei, muss also am 
Taster liegen.

Taster ist von Reichelt:
http://www.reichelt.de/RAFI-107-507/3/index.html?&ACTION=3&LA=446&ARTICLE=110864&artnr=RAFI+107.507&SEARCH=RAFI+107.507

Also neue kaufen oder was ?

Wie sieht denn deine Schaltung aus?

Der Pin mit dem Taster muss immer auf einem definierten Potential 
liegen, wenn der Taster "High" gibt, muss der Pin über einen 
Pull-Down-Widerstand auf GND liegen, andersrum über Pull-Up auf High, da 
kann man auch den internen Pull-Up verwenden.

Simon K. schrieb:
> Mit einer Schleife von 0,5 s funkioniert es einwandfrei, muss also am
> Taster liegen.

 LOL.
 Was ist das für ein Taster ?

?!? schrieb:
>> Was ist das für ein Taster ?
http://www.reichelt.de/RAFI-107-507/3/index.html?&;...

spess53 schrieb:
> Unsinn. Kein Taster prellt 0,5s.

 Kann mich dem nur anschliessen.

Carsten R. schrieb:
> Bau mal eine Schleife ein die ohne Taster jede (halbe) Sekunde ein Feld
> weiterrückt und am Ende entweder auf Start geht und weitermacht oder die
> Richtung ändert.
>
> Nur mal um sicherzustellen ob es wirklich am Taster liegt.

Darauf bezogen war das mit den 0,4sec.

M. S. schrieb:
> Wie sieht denn deine Schaltung aus?
>

Taster liegen an GND, interne PullUp's sind an, geben also wenn 
ungedrückt ein HIGH-Pegel.

Habe jetzt die Schnauze voll und mache morgen weiter.

Hatte von Busch&Jaeger auch mal die Aussage zu einem Taster von 500 mSek 
Prellen konnte ich aber nicht beobachten. Sehr gut sind diese Miniatur 
Hubtaster die hatte ich mal bei Reichelt bestellt. Muss mal schauen 
irgendwo habe ich mal das ganze gepostet.

hier habe ich noch mal ein Bild das ich mit dem Logicanalyzer auf die 
schnelle aufgenommen habe. War wie besagt dieser normale Licht Taster 
von den angegeben 500mSek war das tatsächliche Prellen beim Drücken 2 
msek lang. Beim loslassen (nicht auf dem Bild drauf) gab es gar kein 
Prellen.

Ok,

ich gehe mal davon aus das shift_left 100% unabhängig von dem Taster 
arbeitet und der Port-Pin definitiv nicht abgefragt wird. Ist das 
richtig?

Dann liegt der Fehler bei der Tastenroutine, also in dem Teil des Codes 
den wir auch haben. Habe es mir daher nun angeschaut mit der ersten 
empfohlenen Modifikation mit Delay.

Simon K. schrieb:
> Ja hab mal nen delay eingefügt. Jetzt schiebt er 1 Zeichen nach links
> und dann geht ca. 5-50mal drücken garnichts mehr, auch wenn ich 4-5 min
> warte.. nichts :D

Klicke nicht, sondern drücke den Taster einen Moment länger. 
Funktioniert es nun?

Carsten R. schrieb:
> Klicke nicht, sondern drücke den Taster einen Moment länger.
> Funktioniert es nun?

 LOL.
 Meinst du er kann schneller klicken als der uC abfragen kann ?

Ja. Das wäre möglich. Wenn du den gegenwärtigen Code gelesen hättest...

Carsten R. schrieb:
> Ja. Das wäre möglich. Wenn du den gegenwärtigen Code gelesen hättest...

 Bleib beim Kaffeeklatsch mit der Nachbarin.

Wie performant der Mikrocontroller auch sein mag ist irrelevant.
Wer mich kennt weiß, daß ich nie ohne Grund schreibe oder Frage.
Ich frage um die Möglichkeit zu überprüfen.

Lies einfach den Code und beantworte die Frage:

Wie schnell wird abgefragt?

Carsten R. schrieb:
> Wie schnell wird abgefragt?

 Schneller als irgendein Mensch klicken kann.

Falsch. Wie schnell?

@ Marc

Wir gehen wahrscheinlich von unterschiedlichem Code aus.

Carsten R. schrieb:
> Dann liegt der Fehler bei der Tastenroutine, also in dem Teil des Codes
> den wir auch haben. Habe es mir daher nun angeschaut mit der ersten
> empfohlenen Modifikation mit Delay.

Ich vermute Du betrachtest Deine zweite Modifikation, die sich anders 
verhält.

Simon K. schrieb:
> Ja hab mal nen delay eingefügt. Jetzt schiebt er 1 Zeichen nach links
> und dann geht ca. 5-50mal drücken garnichts mehr, auch wenn ich 4-5 min
> warte.. nichts :D

vs

Simon K. schrieb:
> Springt weiter mehrere schritte nach links mal beim drücken mal beim
> loslassen mal beides..

Ich habe bewußt die erste Variante ausgesucht und das auch gleich 
geschrieben. Ich wählte ihn wegen der beobachteten Eigenschaft um jene 
Frage stellen zu können, zwecks Eingrenzung, nicht um etwas blind zu 
behaupten. Das ist nicht meine Absicht. Es geht um Informationsgewinn.

Wer mich kennt weiß, daß ich nie etwas grundlos schreibe oder frage.

Der verlinkte Schalter scheint nicht gerade der beste zu sein trotz des 
hohen Preises. Meiner Meinung nach sind diese Taster gut die ab einem 
gewissen Druckpunkt schlagartig umspringen. Wie beim Knackfrosch. Bei 
dem verlinkten druckt man bestimmt nur 2 Kontakte zusammen die von einer 
schwachen Feder auseinander gedrückt werden.

http://commons.wikimedia.org/wiki/File:Calotte_en_flambement.png

Diese Hubtaster funktionieren ganz gut
http://cdn-reichelt.de/bilder/web/xxl_ws/C200/PHAP3301.png

Geh doch einfach mal das Programm im AVR Stuido durch, Build an Run und 
dann das Symbol für einzelschritt dann kann du den entsprechenden PIN 
anstoßen und beobachten wohin das Programm springt.

Viele Anfänger haben das gleiche Problem wenn Sie per Taste und einem µC 
eine LED leuchten lassen wollen, die LED geht meistens an und bleibt an 
weil das Programm gar nicht mehr prüft ob die Bedingung schon wieder 
hinfällig ist. Ich würde den Schiebevorgang erst starten wenn die Taste 
eine Mindestzeit gedrückt wurde und dann wieder losgelassen wird.
1. Taste einlesen,
2. wenn gedrückt 50mSek warten
3. wenn taste immer nochgedrückt beim nächsten loslassen schieben.

Wenn da jetzt kurze Peaks von ein paar mSek drin sind interessiert es 
das Programm garnicht.

Carsten R. schrieb:
> Ja. Das wäre möglich. Wenn du den gegenwärtigen Code gelesen hättest...

Sorry, das war unangemessen von mir. In dem Augenblick war mir nicht 
bewußt daß du selbst der Verfasser der Modifikation bist. Natürlich hast 
Du es dann gelesen.

Wir haben uns auf unterschiedlichen Code bezogen.

Simon K. schrieb:
> Also neue kaufen oder was ?

Warte mit der Bestellung noch einen Moment.
Abhängig von der Antwort auf meine Frage

Beitrag "Re: ATmega8, Assembler- Programm fehler oder Taster entprellen?"

kann man das möglicherweise auch einfacher lösen.

Carsten R. schrieb:
> Sorry, das war unangemessen von mir. In dem Augenblick war mir nicht
> bewußt daß du selbst der Verfasser der Modifikation bist. Natürlich hast
> Du es dann gelesen.
>
> Wir haben uns auf unterschiedlichen Code bezogen.

 Kein Problem.
 Das ist ja gerade das Problem im Forum, dass man meistens nicht weiss,
 was der TO geändert hat und was nicht.
 Geänderten Code posten, konkrete Frage stellen wäre besser...

Die beste Lösung zum Entprellen ist und bleibt ein Timerinterrupt.
In meiner Praxis hat sich eine 4-fach Abtastung mit 2 .. 50ms als 
ausreichend erwiesen.

Der große Vorteil einer solchen Lösung ist, man entwickelt sie einmal 
und setzt sie dann nur noch in jedes Projekt ein.

Peter Dannegger schrieb:
> Die beste Lösung zum Entprellen ist und bleibt ein Timerinterrupt.
> In meiner Praxis hat sich eine 4-fach Abtastung mit 2 .. 50ms als
> ausreichend erwiesen.
>
> Der große Vorteil einer solchen Lösung ist, man entwickelt sie einmal
> und setzt sie dann nur noch in jedes Projekt ein.

 Ja.
 In meiner Systimer routine habe ich 4 verschiedene Zähler die in
 Main auf einen bestimmten Wert gesetzt werden und bei Bedarf
 (Flag gesetzt) runtergezählt werden - 8Cycles verloren bei nicht
 gesetztem Flag, aber dafür universell und bewährt.

Da ist er ja. Auf Peter habe ich schon gewartet. Sei gegrüßt.

Leider noch keine Antwort. Daher nur Spekulation. Da nur ein 
Codefragment zu sehen ist, ist unklar ob die Displayroutine ebenfalls 
noch den Port abfragt und ob delay_50ms wirklich (nur) 50 ms wartet. Der 
Schaltplan ist ebenso unbekannt.

Meine aktuelle Hypothese lautet:

Originalcode : Taster prellt

Code mit Modifikation 1:
Da bei jedem Schleifendurchlauf gewartet wird, wird das Prellen 
ausgeblendet, aber ein kurzer Stups wird wegen dem Delay nicht oder nur 
sporadisch detektiert wenn die Abfrage mit dem Signal zufällig zeitlich 
zusammenfällt. Dabei geht es nicht darum wie schnell der Finger ist, 
sondern was der Taster darauf macht. Der interne Aufbau des Tasters ist 
da relevant. Ein längerer Tastendruck müßte funktionieren.

Code mit Modifikation 2:
Hier wird nur gewartet wenn ein Tastendruck erkannt wird. Ohne 
Tastendruck erfolgt das Polling sehr schnell. Jedoch scheint der Taster 
auch beim loslassen zu prellen. Das wurde bei Modifikation 1 ebenfalls 
abgefangen, da bei jedem Durchlauf gewartet wurde, so auch beim 
loslassen.

Der Taster scheint jedoch beim drücken wieder zu prellen. das wäre 
erneut zu prüfen, da es auch bei Modifikation 1 hätte passieren müssen. 
Eventuell subjektive Wahrnehmung da das Prellen unerwartet beim 
Loslassen wieder auftaucht.

Alternativ könnte es auch bei längerem Drücken zum "Prellen" kommen. Bei 
sehr kleinen Strömen können Taster "stottern". Wenn nur der interne 
Pull-up oder ähnlich hochohmige externe Pull-up-Widerstände verwendet 
werden liegt der Strom weit unter einem Milliampere. Das würde auch das 
"Prellen" beim Loslassen erklären.

Abhilfe:
Ein externer 1 kOhm Pull-Up-Widerstand sollte helfen.
Plus Umbau der Software:
Entprellung nach Dannegger oder jeweils ein Delay nach Pegelwechsel.

Letzteres ist quick&dirty. Das andere eleganter und leichter 
wiederverwendbar. Das kann man von quick&dirty nicht behaupten. Polling 
behindert die restliche Software, sofern da noch mehr als nur 
Interruptroutinen vorhanden ist.

links:
  sbic  PINB, 0    ;S1=GEDRÜCKT
  rjmp  links
  rcall  shift_left
  rcall  Delay_50mS
wait:
  sbis  PINB, 0    ;S1=UNGEDRÜCKT
  rjmp  wait
  rcall  Delay_50mS
  rjmp  links

Zum Vorpost noch:
displayroutine fragt den Port nicht ab.

Habe mal die Schaltung in der das LCD und die Taster integriert waren 
bei Seite gelegt und einen einfachen Aufbau auf Lochraster gemacht mit 
nem ATmega8, 5 Hubtastern (wie oben schonmal erwähnt) mit externen 
PullUp's und einem kleinen LCD.

Programm rein und siehe da, es funktioniert wesenltich besser als zuvor.
Ein Testerprellen ist nicht mehr bemerkbar nur, wie Carsten schon 
erwähnt hat, der Delay während der Schleifen sorgt hier und da für ein 
kleines stolpern/stottern.
Halte ich den Taster gedrückt wird ebenfalls wie gewollt nicht mehr 
weiter oder zurück gesprungen.
Werde nachher mal anfangen nen Timerinterrupt in das Programm einzubauen 
ich denke damit ist der Drops gelutscht.

Die grünen Taster habe ich in einem kleinen Tütchen mit der Aufschrift 
"Hat dir 2 Nächte Schlaf geraubt" ganz hinten in der Elektronik Krims 
Krams Kiste verschwinden lassen.

Danke an alle für die schnellen Antworten, war btw. mein erster Thread 
im Forum und freue mich auf weitere Diskussionen zum Thema Assembler, 
AVR.

MfG.
Simon