Entprellen Taster

[Marten M. (mcgonahy148)]

Zu dem Beitrag [[Beitrag "Entprellen für Anfänger"]] hab 
ich ne Frage wie das abläuft. Ich habe es in eine .h-Datei ausgelagert 
und ruf sie in meinem Programm dann auf die debounce-function. Nur bei 
jedem Reset meines Controllers wird das Debounce einmal ausgeführt?!

[Karl H. (kbuchegg)]

Marten Mcgonahy schrieb:
> Zu dem Beitrag [[Beitrag "Entprellen für Anfänger"]] hab
> ich ne Frage wie das abläuft. Ich habe es in eine .h-Datei ausgelagert
> und ruf sie in meinem Programm dann auf die debounce-function. Nur bei
> jedem Reset meines Controllers wird das Debounce einmal ausgeführt?!

Zeig den restlichen Code.
(Ausserdem ist diese debounce Lösung eine schlechte Lösung)

[ich (Gast)]

Bau einen Kondensator an dein Taster und lass den Murks mit der 
Softwarelösung

[Karl H. (kbuchegg)]

ich schrieb:
> Bau einen Kondensator an dein Taster und lass den Murks mit der
> Softwarelösung

Autsch.
Das tut weh.

(Das genaue Gegenteil ist der Fall: Die Kondensator-Lösungen sind Murks)

[ich (Gast)]

>(Das genaue Gegenteil ist der Fall: Die Kondensator-Lösungen sind Murks)

Bitte um Aufklärung :-)

[Stefan B. (stefan)]

Offtopic:

*Open Call: send us your Debounce code*
http://hackaday.com/2010/10/13/open-call-send-us-your-debounce-code/

[Info (Gast)]

Mehr Bauteile = -Platz +Gewicht +Fehlerquelle +Zeit -Flexibilität 
+Alterung +Geld

[Stefan B. (stefan)]

ich schrieb:

> Bitte um Aufklärung :-)

http://www.mikrocontroller.net/articles/Diskussion:Pollin_ATMEL_Evaluations-Board

"Die beiden AVR Pollinboards haben eine Hardwareentprellung der Taster. 
Leider kann es passieren, dass beim Drücken der Taster in diesen 
Schaltungsteil (d.h. den Kondensator, Ed.) so viel Strom fliesst, dass 
der Mikrocontroller abstürzt!"

[Karl H. (kbuchegg)]

Info schrieb:
> Mehr Bauteile = -Platz +Gewicht +Fehlerquelle +Zeit -Flexibilität
> +Alterung +Geld

Exakt.
Oder kriegst du von deiner Kondensatorlösung zb einen automatischen 
Autorepeat für Lau mit. Oder wie löst du das 'Problem' einen Tastendruck 
auch dann zu registrieren, wenn das Programm gerade anderweitig 
beschäftigt ist?


Die debounce-Lösung mit dem _delay ist keine gute.
Aber im Entprellen-Artikel ist eine Lösung für einen Timer-Interrupt die
* so gut wie keine Rechenzeit verbraucht
* Tastendrücke auch dann registriert, wenn das Programm anderweitig
  gerade beschäftigt ist
* Auf Wunsch kurze von langen Tastendrücken unterscheidet
* einen Autorepeat auf Tasten legen kann

Und das alles in noch nicht einmal 2 Handvoll Anweisungen, die weniger 
als 1% Rechenzeit benötigen.

[ich (Gast)]

>> Mehr Bauteile = -Platz +Gewicht +Fehlerquelle +Zeit -Flexibilität
>> +Alterung +Geld

>Exakt.
>Oder kriegst du von deiner Kondensatorlösung zb einen automatischen
>Autorepeat für Lau mit. Oder wie löst du das 'Problem' einen Tastendruck
>auch dann zu registrieren, wenn das Programm gerade anderweitig
>beschäftigt ist?

- Platz: naja ein C in 0603 fällt nicht wirklich ins Gewicht, weder vom 
Platz noch von der MAsse
- Fehlerquelle: Der taster selbst ist eine sehr viel größere 
Fehlerquelle
- Zeit: Die Software für Entprellung dauert ja wohl länger als ein C 
einzulöten
- Felxibilität: Wenn man das Programm geschrieben hat ist man auch 
festgelegt. Man muss halt vorher mal rechnen.
- Alterung: Der Taster ändert seine Eigenschaften DEUTLICH mehr als ein 
C
- Geld: im einstelligen Cent Bereich. Softwareentwicklung (5 Minuten) 
bei Lohnkosten 50€ pro Stunde um die 4€ (kann man argumentieren wenn es 
Millionenfach gebaut wird)

Wenn das Programm anderweitig beschäftigt ist, ist die 
Softwareentprellung auch keine Lösung, wenn das Programm grad was 
anderes tut.

[Karl H. (kbuchegg)]

ich schrieb:

> Wenn das Programm anderweitig beschäftigt ist, ist die
> Softwareentprellung auch keine Lösung, wenn das Programm grad was
> anderes tut.

[ ] du kennst die Dannegger-Entprellung und hast sie schon
    mal in Aktion erlebt bzw. benutzt
[ ] du kennst sie vom hörensagen
[ ] du kennst sie nicht



> - Zeit: Die Software für Entprellung dauert ja wohl länger als
>  ein C einzulöten

Nö.
Wie lange dauert es wohl
#include "xyz.h"
zu schreiben?


(OK. das ist jetzt ein bischen zu sehr verkürzt. Den Timer-Init Code 
muss man noch einkopieren)

> - Felxibilität: Wenn man das Programm geschrieben hat ist man auch
> festgelegt. Man muss halt vorher mal rechnen.

Mit Flexibilität ist zwar auch Anpassbarkeit gemeint. Aber hauptsächlich 
welche Möglichkeiten der Benutzung bzw. Benutzerführung sich dadurch 
ergeben.

[ich (Gast)]

>Wie lange dauert es wohl
>#include "xyz.h"
>zu schreiben?

Und automatisch weis der Compiler wo der Taster angeschlossen wird...

>Mit Flexibilität ist zwar auch Anpassbarkeit gemeint.

Was gibts da anzupassen? Oder gibst du nach 5 Jahren ein Softwareupdate 
raus, weil du denkst dass die Taster mitlerweile stärker prellen?

[x] du kennst sie nicht

Dennoch sind 80% eurer Arggumente in meinen Auge Quatsch

[Peter D. (peda)]

ich schrieb:
> - Zeit: Die Software für Entprellung dauert ja wohl länger als ein C
> einzulöten

Die Entwicklung hat länger gedauert, war aber nur einmal nötig.
Danach ist der Aufwand aber deutlich geringer, als bei der C-Lösung.

Der große Vorteil der SW-Lösung ist, daß sie universell ist.
Einfach nur zum Projekt hinzufügen und die gewünschten Funktionen 
aufrufen.
Man muß nie wieder übers Entprellen nachdenken.


Peter

[Karl H. (kbuchegg)]

ich schrieb:
>>Wie lange dauert es wohl
>>#include "xyz.h"
>>zu schreiben?
>
> Und automatisch weis der Compiler wo der Taster angeschlossen wird...

OK.
Ein paar #define kommen noch davor.
Trotzdem ist das alles fertig programmiert, noch ehe dein Lötkolben heiß 
ist.

>
>>Mit Flexibilität ist zwar auch Anpassbarkeit gemeint.
>
> Was gibts da anzupassen?

Weil man eine Universalroutine hat, die man
* an die Tasten-Port-Belegung anpassen kann
* Autorepeat wahlweise auf Tasten drauflegen bzw. wegnehmen kann
* In den Entprell-zeiten anpassen kann

> Oder gibst du nach 5 Jahren ein Softwareupdate
> raus, weil du denkst dass die Taster mitlerweile stärker prellen?

Nein.
Aber Programme entwickeln sich weiter.
Ein Parameter der bisher von 1 bis 10 ging, geht demnächst zwecks 
feinerer Granulierung von 0 bis 1000. Dieselbe Verstellfunktionalität 
die bisher angemessen war (Einzeltastendrücke) geht plötzlich nicht mehr

bisher hattest du

  if( get_key_press( KEY_INCREMENT ) ) {
    if( value < 10 )
      value++;
  }
  else if( get_key_press( KEY_DECREMENT ) ) {
    if( value > 0 )
      value--;
  }

Durch die neu geforderte feinere Granularität änderst du das zu

  if( get_key_press( KEY_INCREMENT ) || get_key_rpt( KEY_INCREMENT )  ) {
    if( value < 1000 )
      value++;
  }
  else if( get_key_press( KEY_DECREMENT )|| get_key_rpt( KEY_INCREMENT ) ) {
    if( value > 0 )
      value--;
  }

trägst die beiden Tasten noch beim Repeat-Makro ein und bist fertig.
Der Benutzer kann weiterhin mit jedem Tastendruck den Wert um 1 
erhöhen/verringern. Drückt er aber die Taste und bleibt drauf, beginnt 
der Wert nach einer einstellbaren Zeit schnell (wie schnell ist 
wiederrum einstellbar) hoch/runter zu laufen.

Oder du machst

  if( get_key_press( KEY_INCREMENT ) ) {
    if( value < 1000 )
      value++;
  }
  else if( get_key_rpt( KEY_INCREMENT ) ) {
    if( value < 1000 )
      value += 10;
  }
  else if( get_key_press( KEY_DECREMENT ) ) {
    if( value > 0 )
      value--;
  }
  else if( get_key_press( KEY_DECREMENT ) ) {
    if( value > 0 )
      value -= 10;
  }

wieder: fertig
Belibt der Benutzer länger auf der Taste, so erhöht sich der Wert im 
schnellen Vorlauf um jeweils 10.

Das mein ich mit Flexibilität in der Benutzung.

> [x] du kennst sie nicht

Dann solltest du nicht über etwas lästern, was du nicht kennst.

>
> Dennoch sind 80% eurer Arggumente in meinen Auge Quatsch

Wir sehen das genau umgekehrt.
Mach niemals etwas in Hardware, was du genausogut und ohne Einbussen 
auch in Software machen kannst.

[Peter D. (peda)]

Marten Mcgonahy schrieb:
> Nur bei
> jedem Reset meines Controllers wird das Debounce einmal ausgeführt?!

Sie muß natürlich ständig in der Mainloop ausgeführt werden, wie soll 
sie denn sonst den Tastendruck zurückmelden!
Und Du mußt natürlich den Returnwert benutzen.


Und sie ist durchaus für kleinere Projekte sehr gut geeignet.

Was natürlich tödlich ist, sind riesen Monsterdelays (>100ms) in der 
Mainloop.
Dann wird sie nicht mehr oft genug aufgerufen und die 
Timerinterruptlösung ist angeraten.


Peter

[ich (Gast)]

>Man muß nie wieder übers Entprellen nachdenken.

Spätestens wenn man eine andere Taktfrequenz verwendet muss man 
vermutlich wieder darüber nachdenken (beim C nicht)

Aber bei Gelegenheit werd ich mir den Code mal ansehen, ich will ja 
nicht alles schlecht reden ohne es gesehen zu haben.

[Karl H. (kbuchegg)]

ich schrieb:
>>Man muß nie wieder übers Entprellen nachdenken.
>
> Spätestens wenn man eine andere Taktfrequenz verwendet muss man
> vermutlich wieder darüber nachdenken (beim C nicht)

Nö.
Wenn man programmieren kann, muss man nicht.

Compiler können einem so manche Anpassarbeit abnehmen. Man muss es nur 
richtig schreiben :-)

Du programmierst ja auch so, dass dir der Compiler die notwendigen 
Konstanten für die UART ausrechnet, wenn Baudrate und Taktfrequenz 
gegeben sind. Oder etwa nicht?

[Wagneth (Gast)]

Ich arbeite viel mit unsauberen/prellenden Signalen.
(zwar nur im Hobbybereich... aber denooch !)

Ich muss sagen ich habe das alles schon selbst ausprobiert.
C, Delay, und PeDas Minimum-ununterbrochen-an Prinzip.

Ich benutze zwar nicht seinen Code (faulheit das Ding richtig zu 
durchschauen -- benutze nur das was Du auch wirklich verstehst),
aber das Prinzip.

Ich habe mit PeDas Algorithmus noch nie Schmerzen gehabt !!!

Delay funktioniert auch nur Nach Zufall.
Es gibt statistisch genügend Möglichkeiten das einem was 
dazwischenfunkt.
Ausserdem blockiert das ganze.

Der kleine C...
Wie gross muss er denn sein ?
Was für ein Tau brauche ich ?
Was für ein Tau bildet er mit dem Eingangswiderstand des µC ?

Bei Peters braucht man nur die Max Prellzeit....

[Kluchscheißernder N. (kluchscheisser)]

Recht amüsant...

[X] du kennst die Dannegger-Entprellung und benutzt sie regelmäßig

MfG

[Marten M. (mcgonahy148)]

SO, nun zu meinem eigentlichen Problem :-)

Ich habs mir jetzt nicht alles durchgelesen, da wird heftig diskutiert 
ob hardware oder softwarelösung, nun gut. Ich möchte eine 
SOFTWARE-Lösung. Deher möchte ich gern die debounce-Lösung ausprobieren.

1.) Den im Link angegeben Code in eine header-datei ausgelagert
2.) Aufruf der Funktion "debounce()" in meiner main routine.

Beispiel...

int main (void)
{

  DDRA   = 0xFF;          //Port A auf Output
 
  DDRD &= ~(1 << DDB4)|~(1 << DDB3)|~(1 << DDB2);  
  DDRD |=(1<<DDD7); //Summer auf Output

  
  while(1)
  {
    
    //Taster 3 Blinkmuster
    //if(PIND & (1<<PIND4))
    if (debounce(PIND, PD4))
    {
      
      
      for(int a=0;a<=4;a++)
      {
        for (int i=0;i<=5;i++)
        {
        PORTA |= (1<<i);
        _delay_ms(blinktime);
        PORTA &= ~(1<<i);
        _delay_ms(blinktime);
        }
        
        for (int j=4;j>=1;j--)
        {
        PORTA |= (1<<j);
        _delay_ms(blinktime);
        PORTA &= ~(1<<j);
        _delay_ms(blinktime);
        }

So, nach reset oder neustart des Controllers fährt er mir jede 
if-Schleife meiner Main-Routine durch. WARUM?


Gruß,
Markus

[Karl H. (kbuchegg)]

Marten Mcgonahy schrieb:

>
>   DDRD &= ~(1 << DDB4)|~(1 << DDB3)|~(1 << DDB2);


Das ist Blödsinn

Schnapp dir Papier und Bleistift, rechne die Einzelterme aus und führe 
genau die Operationen durch, die auch dein Programm macht.

Dein Glück, dass im Endergebnis raus kommt: Alle Pins im Port D so 
lassen wie sie sind. Das heißt aber nicht dass die Einzeloperationen 
korrekt sind.


>   DDRD |=(1<<DDD7); //Summer auf Output


OK.


Kein Pullup Widerstand für die Taster?

> So, nach reset oder neustart des Controllers fährt er mir jede
> if-Schleife meiner Main-Routine durch. WARUM?

Nitpicking: if ist keine Schleife.
Zum Wesen einer Schleife gehört, dass etwas (zumindest potentiell) 
wiederholt wird. Bei einem if wird nichts wiederholt. Es wird eine 
Auswahl aus 2 Möglichkeiten getroffen.

[Stefan B. (stefan)]

Marten Mcgonahy schrieb:

> So, nach reset oder neustart des Controllers fährt er mir jede
> if-Schleife meiner Main-Routine durch. WARUM?

Das Makro aus der Artikelsammlung arbeitet mit active low geschalteten 
Tastern

Hängt der Taster im Ruhezustand (nicht gedrückt) nicht auf einem HIGH 
Pegel? D.h. ist der Pull-up Widerstand am Taster nicht eingeschaltet 
(der interne ist es laut Code nicht, d.h. es müsste ein externer da 
sein).

[U.R. Schmitt (Gast)]

ich schrieb:
> Was gibts da anzupassen? Oder gibst du nach 5 Jahren ein Softwareupdate
> raus, weil du denkst dass die Taster mitlerweile stärker prellen?
>
> [x] du kennst sie nicht
>
> Dennoch sind 80% eurer Arggumente in meinen Auge Quatsch

Genau das haben die Kutschenhersteller vor über 100 Jahren auch gesagt 
als die ersten Automobile über die Lande gefahren sind. :-)
Lässt Du dich immer noch in der Kutsche fahren?

Du urteilst über etwas das Du nicht kennst und dessen Konzept Du wohl 
nicht oder nur sehr unvollständig verstanden hast.
Schau Dir das erst mal in Ruhe an.
Und wenn schon Hardwareentprellung, dann machs mit Umschalter und 
Flipflops. Das ist wenigstens sauber!

[Marten M. (mcgonahy148)]

Karl heinz Buchegger schrieb:
>>
>>   DDRD &= ~(1 << DDB4)|~(1 << DDB3)|~(1 << DDB2);
>
>
> Das ist Blödsinn
>
> Schnapp dir Papier und Bleistift, rechne die Einzelterme aus und führe
> genau die Operationen durch, die auch dein Programm macht.
>
> Dein Glück, dass im Endergebnis raus kommt: Alle Pins im Port D so
> lassen wie sie sind. Das heißt aber nicht dass die Einzeloperationen
> korrekt sind.

Ok, ich sehs grad. Wenn ich statt den "oder" jeweils ein "und" einbaue, 
dann dürfte es stimmen.

Es gibt also verschiedene Varianten, wie schreibt man denn es nun im 
Normalfall, wenn ich also B4,B3,B2 als EINGANG nutzen möchte, weil 
Taster dranhängen?

Karl heinz Buchegger schrieb:
> Kein Pullup Widerstand für die Taster?

Die Eingänge sind mit einem Pulldownwiderstand abgeschlossen.

Karl heinz Buchegger schrieb:
> Nitpicking: if ist keine Schleife.
> Zum Wesen einer Schleife gehört, dass etwas (zumindest potentiell)
> wiederholt wird. Bei einem if wird nichts wiederholt. Es wird eine
> Auswahl aus 2 Möglichkeiten getroffen.

Sorry, du hast schon recht, aber du weisst was ich meine. Die 
if-ANWEISUNG wird mir immer ausgeführt.

[Karl H. (kbuchegg)]

Marten Mcgonahy schrieb:
> Karl heinz Buchegger schrieb:
>>>
>>>   DDRD &= ~(1 << DDB4)|~(1 << DDB3)|~(1 << DDB2);
>>
>>
>> Das ist Blödsinn
>>
>> Schnapp dir Papier und Bleistift, rechne die Einzelterme aus und führe
>> genau die Operationen durch, die auch dein Programm macht.
>>
>> Dein Glück, dass im Endergebnis raus kommt: Alle Pins im Port D so
>> lassen wie sie sind. Das heißt aber nicht dass die Einzeloperationen
>> korrekt sind.
>
> Ok, ich sehs grad. Wenn ich statt den "oder" jeweils ein "und" einbaue,
> dann dürfte es stimmen.

Nein.
Nimm dir Papier und Bleistift und spiels durch

[Karl H. (kbuchegg)]

Marten Mcgonahy schrieb:

>> Kein Pullup Widerstand für die Taster?
>
> Die Eingänge sind mit einem Pulldownwiderstand abgeschlossen.


Dann musst du die debounce Funktion umschreiben.
Die ist, wie die meisten Taster-Funktionen, darauf ausgelegt, dass der 
Grundzustand am Port eine 1 ist und beim Drücken der Eingangspin auf 0 
geht.

[Marten M. (mcgonahy148)]

Stefan B. schrieb:
> Das Makro aus der Artikelsammlung arbeitet mit active low geschalteten
> Tastern
>
> Hängt der Taster im Ruhezustand (nicht gedrückt) nicht auf einem HIGH
> Pegel? D.h. ist der Pull-up Widerstand am Taster nicht eingeschaltet
> (der interne ist es laut Code nicht, d.h. es müsste ein externer da
> sein).

Wie erkenne ich das im Sourcecode? Mein Taster (Schließer) verbindet 
beim schließen den Input vom Controller mit highpotential, wenn der 
Taster also offen ist, liegt lowpotential am Eingang an. Sprich der 
Taster is high active, nicht dass ich jetzt mit den Bezeichnungen 
durcheinander komme?! :-)

[Karl H. (kbuchegg)]

Marten Mcgonahy schrieb:
> Stefan B. schrieb:
>> Das Makro aus der Artikelsammlung arbeitet mit active low geschalteten
>> Tastern
>>
>> Hängt der Taster im Ruhezustand (nicht gedrückt) nicht auf einem HIGH
>> Pegel? D.h. ist der Pull-up Widerstand am Taster nicht eingeschaltet
>> (der interne ist es laut Code nicht, d.h. es müsste ein externer da
>> sein).
>
> Wie erkenne ich das im Sourcecode?

Indem du dir die Abfragen ansiehst und die Funktionsweise der debounce 
Funktion verstehen lernst.
Aus der Logik ergibt sich dann: solange der Grundzustand 1 vorliegt, 
macht debounce überhaupt nichts.
Bei dir ist aber der Grundzustand nicht 1, bei dir ist er 0

> Mein Taster (Schließer) verbindet
> beim schließen den Input vom Controller mit highpotential, wenn der
> Taster also offen ist, liegt lowpotential am Eingang an. Sprich der
> Taster is high active, nicht dass ich jetzt mit den Bezeichnungen
> durcheinander komme?! :-)

Diesmal stimmt deine Ausdrucksweise :-)

Im einfachsten Fall stopfst du einfach den invertierten Zustand des 
Ports in die debounce Funktion hinein. Dann dreht sich für debounce 
alles um (aus 1 wird 0, aus 0 wird 1) und es ist glücklich und arbeitet 
korrekt.

[Marten M. (mcgonahy148)]

Karl heinz Buchegger schrieb:
> Nein.
> Nimm dir Papier und Bleistift und spiels durch

Hab ich. Statt den Oder´s jeweils ein UND müsste ja gehen?!

Bit 6  5  4  3  2  1
--------------------
    1  0  1  1  1  1
    1  1  0  1  1  1 Oder
    1  1  1  0  1  1 Oder
--------------------
    1  1  1  1  1  1 Ergebnis

Wenn nun ein UND statt den beiden ODER verwendet wird, steht da

    1  0  0  0  1  1

Sprich, ein NULLER heisst ja dass der Port ein Eingang ist.

[Karl H. (kbuchegg)]

Marten Mcgonahy schrieb:
> Karl heinz Buchegger schrieb:
>> Nein.
>> Nimm dir Papier und Bleistift und spiels durch
>
> Hab ich. Statt den Oder´s jeweils ein UND müsste ja gehen?!

OK. Hast recht. Mein Fehler

die kanonische Schreibweise ist

  DDRD &= ~( (1 << DDB4) | (1 << DDB3) | (1 << DDB2) );

wenn man da jetzt De-Morgan anwendet kommt das von dir behauptete raus.
Mein Fehler. Sorry.

>     1  0  0  0  1  1
>
> Sprich, ein NULLER heisst ja dass der Port ein Eingang ist.

Noch nicht ganz.
Bis jetzt hast du nur die Maske, mit der das DDR selber wieder verundet 
wird. Jeder 0-er in der Maske sorgt dafür, dass im Ergebnis ebenfalls 
imt Sicherheit eine 0 auftaucht. Und damit sorgt diese Maske dafür, dass 
DB2, SB3 und DB4 in DDRD auf jeden Fall auf 0 gesetzt werden. Über die 
restlichen Bits in DDRD lässt sich keine Aussage machen. Die bleiben so 
wie sie vorher waren.

Aber: Es kommt das Richtige aus dem richtigen Grund raus.

[Marten M. (mcgonahy148)]

Karl heinz Buchegger schrieb:
> die kanonische Schreibweise ist
>
>   DDRD &= ~( (1 << DDB4) | (1 << DDB3) | (1 << DDB2) );
>
> wenn man da jetzt De-Morgan anwendet kommt das von dir behauptete raus.
> Mein Fehler. Sorry.

Aiaiai, den De-Morgen hab ich auch mal irgendwo gehört, lang ists her. 
Einfach UND und ODER tauschen, so irgendwie war das.

Karl heinz Buchegger schrieb:
> Noch nicht ganz.

Ja, ich vergaß es noch zu erwähnen, das macht ja das UND vor dem 
Gleichheitszeichen.

Nur ich versteh nicht warum in dem AVR oder GCC Tutorial sie so auf 
diese Schreibweise hinweisen?! Ich bin ein Fan von 0b0101010101, da 
sieht man es doch auch sofort und ist nicht so lange?! Hex schließ ich 
mal ganz aus, ausser es is halt 0hFF also alles 1.

Nun hab ich troztdem mit meinem debounce noch zu kämpfen, die 
Übergabeparameter invertieren funktioniert nicht, also im h-file 
invertieren mal versuchen.

Ein weiterer Nachteil der jetzt mit dem externen quarz aufkam, meine 
if-Anweisungen werden nicht mehr bedient, weil er in der delay-Schleife 
wohl festhängt und überhaupt nicht auf die Tasteneingaben reagiert. 
Klar, musste ja so kommen, bei den timern bin ich noch nicht so richtig. 
Und die PWM-Sache ist zwar thema Timer, aber ich hab den sourcecode ja 
nur kopiert und muss mir das ganze erst noch genauer ansehen.

Ich hatte mal nen c167 mit assembler programmiert. Da gabs dann ISR 
(Interrupt service routinen) und durch z.b. nen taster konnte man die ja 
auslösen, oder durch nen timer oder oder. Aber wie läuft das hier in C? 
Ich drücke eine Taste und dann springt er mir in eine Routine ausserhalb 
von main, oder wie?

[Karl H. (kbuchegg)]

Marten Mcgonahy schrieb:

> Nur ich versteh nicht warum in dem AVR oder GCC Tutorial sie so auf
> diese Schreibweise hinweisen?! Ich bin ein Fan von 0b0101010101, da
> sieht man es doch auch sofort und ist nicht so lange?!

Na dann schreib doch mal deine 0b... Schreibweise so um, dass du die 
Portnummern an einer einzigen Stelle beisammen hast und du dort einfach 
konfigurieren kannst, wo der Taster hängt.

> Nun hab ich troztdem mit meinem debounce noch zu kämpfen, die
> Übergabeparameter invertieren funktioniert nicht

Warum nicht?

[Karl H. (kbuchegg)]

Karl heinz Buchegger schrieb:

>> Nun hab ich troztdem mit meinem debounce noch zu kämpfen, die
>> Übergabeparameter invertieren funktioniert nicht
>
> Warum nicht?

Ah. Seh schon. Noch mal mein Fehler.
Dieser debounce Funktion übergibt man ja nicht einen Wert, sondern die 
Adresse des Ports.
Yep. Dann muss man die Funktion umdrehen.

[Stefan B. (stefan)]

http://www.mikrocontroller.net/articles/Entprellung#Debounce-Makro_von_Peter_Dannegger

"Peter Dannegger hat in "Entprellen für Anfänger" folgende vereinfachtes 
Entprellverfahren beschrieben. Das Makro arbeitet in der Originalversion 
mit active low geschalteten Tastern, kann aber einfach für *active 
high* geschaltete Taster angepasst werden (Tasty Reloaded)"

In den beiden Links im Artikel ist gezeigt, was man für active high 
ändern muss.

[Marten M. (mcgonahy148)]

Stefan B. schrieb:
> http://www.mikrocontroller.net/articles/Entprellun...
>
> "Peter Dannegger hat in "Entprellen für Anfänger" folgende vereinfachtes
> Entprellverfahren beschrieben. Das Makro arbeitet in der Originalversion
> mit active low geschalteten Tastern, kann aber einfach für *active
> high* geschaltete Taster angepasst werden (Tasty Reloaded)"
>
> In den beiden Links im Artikel ist gezeigt, was man für active high
> ändern muss.

Danke...