Entprellen..schon alles versucht..Atmega zu schnell?

Widerstände vergrößern dürfte den Effekt nur verstärken, lass die mal so 
und mach den Kondensator größer.

An der Softwarelösung würd ich aber noch arbeiten, schätze du baust da 
Delays mit ein. Lass das mal und strick dir was mit den Timern zusammen, 
nachdem du sowieso multiplexen tust hast du schätzungsweise eh einen 
Timer der ständig läuft.

Nachtrag: Hast du Wechselschalter?
http://www.mikrocontroller.net/articles/Entprellung

> Softwaremäßige entprellung habe ich auch schon probiert..taugt nichts,
> da ich Multiplexe und die Softwarelösung zu "lange" dauert.
Die Softwareentprellung nach P. Dannegger funktioniert bombensicher ganz 
ohne jegliche Delays und bei mir in einem Orgelpedal sogar mit 40 
Tastern. Such mal hier im Forum danach und du findest z.B. den 
Beitrag "Tasten entprellen - Bulletproof"

Oder sieh dir das an: Entprellung

Suche Hilfe schrieb:
> Softwaremäßige entprellung habe ich
> auch schon probiert..taugt nichts,

Dann hast Du es nicht richtig gemacht.
SW-Entprellung per Timerinterrupt belastet die CPU besonders wenig und 
ist besonders störsicher und flexibel.


> da ich Multiplexe und die
> Softwarelösung zu "lange" dauert.

Was dauert daran zu lange?


Peter

Peter Dannegger schrieb:
> Was dauert daran zu lange?
>
>
> Peter

Peter,
ich denke diese Frage kann "Mann" sich sparen. Wenn er es verstanden 
hätte, würde die Frage So nicht existieren. Evtl würde es helfen den 
Multiplex mit dem Polling zu synchronisieren voraus gesetzt der Mux geht 
wirklich rasend schnell (was ich nicht glauben will).
 Aber wenn er die Grundlagen schon verweigert....

Was du oben meintest ist nicht Schmitt Trigger, du brauchst entweder ein 
Flip-Flop, oder ein Mono-Flop, wenn dass mit dem SW entprellen nichts 
ist

Patrick Koch schrieb:
> Was du oben meintest ist nicht Schmitt Trigger, du brauchst entweder ein
> Flip-Flop, oder ein Mono-Flop,

Das braucht er alles nicht, ein paar Zeilen sinnvoller Code im 
Timer-Interrupt reichen völlig zu.

> wenn dass mit dem SW entprellen nichts
> ist

Warum soll das nichts sein? Das funktioniert immer und überall und 
kostet kaum Rechenzeit. Man muss es nur richtig machen.

Suche Hilfe schrieb:

> versucht (Turtorial -> Entprellung). Die Delay war zulange..

Da ist das Zauberwort. delay

Vergiss die ganzen vermeintlich einfachen Entrellfunktionen, die auf 
delays basieren. Das ist Müll.

>  Würde gerne mal die SW-Lösung von P. Dannegger ausprobieren..wie habe
> ich diese einzusetzten?

Im Artikel aus dem du sie her hast, ist ein Testprogramm. Dort sieht man 
sehr gut, wie sie verwendet wird.

Suche Hilfe schrieb:
> Ich steuere vier 7-Segmentanzeigen an. Ein Transistor hat eine
> Periodendauer von 140us (7,14kHz).

Ich hoffe mal, per Timerinterrupt.

7kHz ist recht heftig, 700Hz sollten dicke reichen.

Aber egal, in den Timerinterrupt packst Du noch nen Zähler 
(8Bit-Variable) rein, der dann etwa alle 10ms Die Entprellroutine 
ausführt. Oder nimm nen 2. Timer.

Und in der Mainloop erfolgt die Abfragefunktion (get_key_press), wann Du 
willst.


Peter

@Basti
Für zu Hause kannst man das so machen, zumal Du die Bauelemente liegen
hast. Viele Leute hier arbeiten aber für Firmen und da ist das Gejaule
groß, wenn die einen Kondensator und einen Widerstand zuviel in der
Schaltung verbauen.

Die Routine von Peter Danegger funktioniert aber tadellos. Man braucht
eine Weile, um sie zu verstehen, weil er dort Register "hochkant"
benutzt, aber da muß man erst mal drauf kommen.

MfG Paul

Basti schrieb:
> Software mache ich das eigentlich nie.

Genau.
Effiziente und zuverlässige Lösungen sollte man möglichst vermeiden.


Peter

Weine nicht, wenn Dein Taster prellt, DAMDAM, DAMDAM
nimm ein Schütz, das sich selber hält, DAMDAM,DAMDAM

Elko, LED, Platine bricht,
aber der Kontroller nicht...

;-)
MfG Paul

In dem Thread ist nun das immer wiederkehrende Thema kommentiert worden. 
Natürlich ist es teilweise ermüdend es immer wieder neu zu erklären, das 
ist aus meiner Sicht aber kein Grund überheblich und abwertend zu 
antworten.

Natürlich gehr es per Hardware. Die Flip-Flop Methode ist auch 
sicherlich die stabilste, aber es geht halt auch mit Software. Wenn man 
beim Kontaktprellen davon aus geht das jedes Prellen irgendwann mal zu 
Ende ist, dann kann man auch mit einem Mikroprozessor den Kontakt sicher 
"entprellen".

Die Methode die Peter vor langer Zeit mal beschrieben hat ist da sehr 
effizient. Sie belastet den Prozessor kaum. Sie funktioniert mit jedem 
Input und erwartet keinen Interrupt Eingang, man kann damit auch einen 
Analogeingang verwenden, wenn es die Schaltung erfordert oder nichts 
anderes mehr frei ist. Voraussetzung ist ein Timer, der mit konstantem 
Takt läuft. Das ist hier der Fall, weil es eine gemultiplexte Anzeige 
gibt. Die Sofware die innerhalb der Timerroutine läuft muss natürlich 
innerhalb der Timer Zeitspanne beendet sein. Delays innerhalb dieser 
Routine sind tödlich und somit verboten.

In meinem schnell zusammen geschusterten Digramm ist der Interrupt durch 
Markierungen auf dem Zeitstrahl symbolisiert. Bei jedem Interrupt gibt 
die Multiplex Anzeige des Displays eine neue Ziffer aus. Das geht 
unabhängig von allem Anderen immer so weiter. In der Interrupt Routine 
wird auch der Port ein gelesen, verglichen und das Ergebnis in Form 
eines Ereigniszählers gespeichert. Dabei ist es egal ob eine 0 oder eine 
1 gelesen wurde. Entscheidend ist das es der gleiche Wert war wie beim 
vorherigen Einlesen. Wenn der Zähler dann über einen definierten 
Schwellwert klettert wird der gespeicherte Wert vom Eingang als wahr an 
genommen.

Das ist alles. In dem man den Schwellwert erhöht, erhöht man die 
Wartezeit für das Entprellen. Die Basiszeit für die Entprellzeit ist der 
Takt des Timers.

Weil das alles kaum Zeit kostet und nichts mit aktiven Software delays 
zu tun hat, gab es hier in paar Kommentare in der Richtung. Weil man die 
Entprellzeit im Prinzip bis ins unendliche (masßlose Übertreibung) 
ausdehnen kann, wurde auch behauptet das man alles per Software 
entprellen kann. Der Software Aufwand ist wirklich gering. Meiner 
Meinung nach schlägt das jede Hardware Lösung, ob es nun ein Tiefpass, 
ein Flipflop oder ein spezieller "Entprell-Chip" ist. Peter hat das 
Ganze in Assembler sehr effiezient programmiert. Das macht es eventuell 
für den einen oder anderen schwer verständlich, aber man kann das 
natürlich in C, C++ oder Basic aufwändiger machen.

Auch wer es bisher nie in Software gemacht hat und bei dem Hardware 
immer funktioniert hat, Relais sind da eine echte Herausforderung. Ich 
persnlich schlage mich damit nicht mehr herum. Einen Timer habe ich fast 
immer mit laufen, um definierte Zeitabstände für Messungen zu haben oder 
eben Displays zu multiplexen. Der Code für die Entprellung fällt da 
überhaupt nicht ins Gewicht.

@Peter; sei bitte nicht so sehr bissig in Deinen Kommentaren. Nicht 
jeder ist in dem Thema so fit wie Du. Ich verstehe das es anfängt zu 
nerven, aber es gibt Dinge die sterben nie aus ...

Ach noch was ... das kam auch schon öfter ... ein Prozessor kan einfach 
NIE zu schnell sein um etwas zu entprellen! Das zeigt deutlich die 
"Delay Denke" und die führt einfach nicht zu einem zufieden stellenden 
Ergebnis.

Paul Baumann schrieb:
> Weine nicht, wenn Dein Taster prellt, DAMDAM, DAMDAM
> nimm ein Schütz, das sich selber hält, DAMDAM,DAMDAM
>
> Elko, LED, Platine bricht,
> aber der Kontroller nicht...
>
> ;-)
> MfG Paul


LOL!!!!

wo kann ich das .mp3 runterladen????


Harry

Suche Hilfe schrieb:

> Wie bringe ich den die Funktion von P. Dannegger zum laufen? Wie kann
> ich da festlegen, an welchem PIN meine Taster hängen?

Nochmal:
Schau dir die C Routinen im Artikel "Entprellung" an.
Versteif dich nicht darauf, dass im begleitenden Text alles drinnen 
steht. Oft genug muss man sch einfach nur den Code ansehen, dann wird 
einem vieles klarer. Im gegenständlichen Fall sind alle #define 
interessant. Den Inhalt der ISR brauchst du nicht analysieren, den 
übernimmst du einfach so wie er ist.
Im Beispiel main() ist ein Timer Setup gezeigt inklusvie Anmelden der 
ISR. Im weiteren ist in main() gezeigt, welche Funktionen aufzurufen 
sind.

Normalerweise müsstest du damit klar kommen, wenn du ein wenig mitdenkst

> Wie kann
> ich da festlegen, an welchem PIN meine Taster hängen?

Der Code fängt an mit:

1

#define KEY_DDR         DDRB

2

#define KEY_PORT        PORTB

3

#define KEY_PIN         PINB

4

#define KEY0            0

5

#define KEY1            1

6

#define KEY2            2

7

#define ALL_KEYS        (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

8

9

#define REPEAT_MASK     (1<<KEY1 | 1<<KEY2)       // repeat: key1, key2

10

#define REPEAT_START    50                        // after 500ms

11

#define REPEAT_NEXT     20                        // every 200ms

Also: Was wirst du wohl ändern müssen, wenn deine Tasten an einem 
anderen Port / anderem Pin sitzen.

Hi,

genau das hatte ich vermutet. Du wirst mit einer "linearen 
hintereinander" Programmierung keinen Erfolg haben. Deine Gemultiplexte 
Anzeige wird z.B. unterschiedlich Hell werden, je nach dem was Du tust.
Meiner Erfahrung nach geht es nur wenn Du eine Interrupt Routine 
schreibst, die mit konstantem Takt läuft. Du baust in der "Main" 
Funktion nur eine minimale Schleifem die den Mikroprozessor schlafen 
legt. Alles was Du an Funktionalität hast packst Du in die Interrupt 
Routine. Die Haupschleife tut nichts.
Du musst hier in Zeitscheiben denken, nicht seriell. Aus meiner Grafik 
kannst Du das erkennen. Wenn Du den Code später erweiterst wird auch 
Deine Anzeige nicht dunkler oder heller, so lange Du dafür sorgst das Du 
alle Aufgaben innerhalb eines Timer-Takes erledigen kannst.
Und mache Dir einen Alarmmerker; sobald Du anfängst ein Delay ein zu 
bauen stimmt etwas nicht mit dem Ablauf. Dann denke noch mal drüber nach 
wie es ohne Delay geht. Ich wette es geht immer ohne ...

Suche Hilfe schrieb:
> Hallo nochmal alle zusammen,
>
> was würde passieren, wenn mein Taster entprellt ist, der "Zählimpuls"
> jedoch länger dauert, als der Ablauf meines gesammten Codes?


Zeig den Code

Ich habe da eine Vermutung
Du zählst meiner Meinung nach nicht Flanken sondern Pegel. Und das geht 
natürlich klar in die Hose.

Wenn du das richtig machst, stellt sich nämlich die Fragestellung gar 
nicht. Wenn überhaupt, dann hat man höchstens das Problem, dass Pulse zu 
schnell sind als das man sie mit dem µC noch mitbekommt.

> Ich dachte, dass ich mich mit meinem Projekt am Ende befinde, einige
> Hinweise von euch haben jedoch meine Einstellung etwas geändert.

LOL
Abgesehen davon, dass ein Projekt nie wirklich 100% fertig ist, klingen 
deine Fragestellungen eher so, als ob du zwar vielleicht eine Lösung für 
das gerade anstehende Problem hast, die so recht und schlecht 
funktioniert. Aber ein Heftpflaster auf einem Loch im Autoreifen ist 
nicht wirklich ein Ersatz für eine fachmännische Lösung

> Vielleicht sollte ich ja meinen Code komplett überarbeiten.
> Ich Multiplexe z.B so:
>         PORTC = ziffer[z2];
>   PORTB |= (1<<PB1);
>   _delay_us(500);
>   PORTB &=~(1<<PB1);
>
> ..und das für alle vier Anzeigen.

Was du da hast, sieht zwar aus wie mulitplexen, wenn man nicht zu genau 
hinschaut. Aber in Wirklichkeit ist es Murx

(Ich hoffe du verzeihst mir die schonunglose Ausdrucksweise. Aber Murx 
muss man auch Murx nennen dürfen)

> Ich dachte, dass ich mich mit meinem Projekt am Ende befinde,
Der Scherz des Tages:
Meine Software ist fertig... ;-)

Der Witz des Tages:
Meine Software ist fehlerfrei... :-/

> Ich dachte, dass ich mich mit meinem Projekt am Ende befinde,
Am Ende kann man auch sein, wenn es nicht mehr weitergeht...  :-o

Poste doch mal den ganzen Code, das hier sieht schon sehr 
verbesserungsfähig aus...

OK Vergiss diese debounce Funktion sofort wieder.
Die ist, aufgrund der delays, sowieso Müll.

Das ist das eine
Das andere ist, wie ich es vermutet habe:
Du zählst nicht Pulse.

Einen Puls erkennt man daran, dass sich der Pinzustand ändert! Dazu muss 
man sich aber einen vorhergehenden Pinzustand merken und nur dann wenn 
sich der verändert, dann hat man die Flanke eines Pulses entdeckt

1

int main()

2

{

3

  ...

4

5

  uint8_t oldValue, newValue;

6

7

  ...

8

9

  oldValue = 0;

10

11

  while( 1 ) {

12

13

    newValue = ( PIND & (1 << PIND6) );

14

15

    if( newValue != oldValue ) {      // am Pin hat sich was getan

16

      if( newValue )                  // Ist er jetzt auf 1 (dann muss er vor Kurzem noch auf 0 gewesen sein,

17

                                      // sonst wären wir nicht durchs erste if gekommen)

18

                                      // dann haben wir die aufsteigende Flanke eines Pulses gefunden

19

20

        Puls++;                       // den Puls daher zählen

21

22

      oldValue = newValue;            // und den jetzigen Zustand merken, damit beim nächsten Schleifendurchlauf

23

                                      // eine Veränderung des Pins erneut erkannt werden kann

24

    }

25

26

    ....

27

  }

so zählt man Pulse. Indem man feststellt, wann sich der Zustand des 
Eingangs verändert.

Allerdings hat man jetzt ein Problem. Wie du schon weist prellen Taster. 
Dein µC ist jetzt schnell genug (bei dir durch die vielen delays 
wahrscheinlich nicht, aber die kommen ohnehin noch weg), dass der µC 
jeden einzelnen Preller als einen Puls ansehen würde.

Und genau da kommt die Entprellung in der ISR ins Spiel. Die macht 
nämlich beides gleichzeitig: sie entprellt und kümmert sich auch darum, 
dass du jeden Tastendruck nur ein einziges mal gemeldet bekommst.

Suche Hilfe schrieb:
> @Karl heinz Buchegger
>
> "Puls++;"  ist das dan quasi meine Zählvariable für den Zählerstand?
> --> Was du gepostet hast wäre also meine neue Tastenabfrage?

Nein!

Ich wollte dir nur grundsätzlich zeigen, wie man Pulse richtig erkennt.

1

  while( 1 ) {

2

    if( PIND & (1<<PD6) )

3

      Puls++;

4

  }

ist nun mal keine korrekte Pulserkennung. Aber genau darauf, mit ein 
paar delay gewürzt, läuft deine Debounce Lösung hinaus

Deine neue Tastenabfrage findest du im Artikel "Entprellung" und zwar 
bei den "Komfortroutinen in C"

> Die Delays zwischen den Schaltzuständen der Transistoren benötige ich
> zur darstellung der Anzeigen (ohne Delay ist das zu schnell und die
> Anzeigen sind nahezu dunkel)

Mach erst mal die Tastenabfrage richtig, ehe das Multiplexing auf eine 
vernünftige Grundlage gestellt wird und ebenfalls in genau den gleichen 
Interrupt hineinwandert.

(kann das Anzeige Multiplexing jemand anderer von den Regulars 
übernehmen? Ich muss um ca. 3 Uhr weg)