Beispiel "Entprellun" Verständnissfrage

[Carsten (Gast)]

Hallo,

um die Eingaben zu entprellen, habe ich mir das Beispiel "Komfortroutine 
(C für AVR) " im Tutorial angeschaut

http://www.mikrocontroller.net/articles/Entprellung

Das prinzip habe ich verstanden, jedoch nicht den Quellcode im ganzen.
Ich möchte den Code dazu bringen, mit "Low-Active" Tastern 
zusammenzuarbeiten

Dazu habe ich die "definde Key" auf "0" anstelle "1" gesetzt und die 
if-Abfragen in der Main ebenfalls mit "0" aufgerufen. Leider ohne 
erfolg.

Kann mir jemand auf die Sprünge helfen, was ich dafür anstellen muss?

Gruß
Carsten

[g457 (Gast)]

> #define ALL_KEYS        (0<<KEY0 | 0<<KEY1 | 0<<KEY2)
> #define REPEAT_MASK     (0<<KEY1 | 0<<KEY2)
[und mehr davon im Rest]

..das klapprt so nicht so richtig, mach da mal brav wieder Einsen rein 
∗hüstel∗

Was Du machen musst ist die Logik umdrehen, nicht die einzelnen Bits.

[Helfer (Gast)]

> Ich möchte den Code dazu bringen, mit "Low-Active" Tastern
> zusammenzuarbeiten

Genau das ist die von Peter bevorzugte Schaltungsweise von Tastern, weil 
man damit u.a. die internen Pull-Ups eines AVR verwenden kann.

Du musst den Code im Artikel Entprellung für active-low Taster 
überhaupt nicht ändern.

Oder verwechselst du vielleicht etwas mit dem Begriff. Zeige doch mal 
deinen Schaltplan...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 0<<KEY0
Du solltest dich mal schlau machen, was bei dieser Aktion herauskommt...

Das selbe wie hier:
(0<<KEY0 | 0<<KEY1 | 0<<KEY2)
und hier
0<<KEY1 | 0<<KEY2
nämlich einfach 0 (Null).

Den shift-Operator verstehen und auf Bitebene zu denken ist eine der 
ersten und offenbar auch schwersten Aufgaben im Leben eines 
uC-Programmierers... :-/

[Carsten (Gast)]

Hallo,

danke für eure Antworten. Ich habe hier das Modul von Display3000 
liegen.
Es ist mit einem AtMega 2561 bestückt, der mit 16Mhz rennt.
Die Pins habe frage ich wie folgt ab:

  if (!( PIND & (1<<PIND4)))
  {
       /Aktion
  }
Daher meine Vermutung, das es sich um "Low Active" handelt. Ich hoffe 
das reicht an stelle des Shcaltplans.

Ich habe wieder den Code in den Ursprung versetzt, nur die I/O Ports und 
den Timer habe ich angepast, leider ohne erfolg. Sofort nach dem Start, 
wird PB7 auf hight gesetzt und die LED leuchtet.

Hat jemand noch einen Tipp oder Idee?

Gruß
Carsten

[g457 (Gast)]

> Sofort nach dem Start, wird PB7 auf hight gesetzt und die LED leuchtet.

..häng an LED0 mal ein Ossi dran, die dürfte blinken:

> #define LED_DDR         DDRB
> #define LED_PORT        PORTB
> #define LED0            7
[..]
> if(!( get_key_long( 1<<KEY1 )))
>       LED_PORT ^= 1<<LED0;

HTH

[Peter D. (peda)]

g457 schrieb:
> ..häng an LED0 mal ein Ossi dran, die dürfte blinken:

Schätzungsweise mit >100kHz.


Carsten schrieb:

> if(!( get_key_long( 1<<KEY1 )))
>       LED_PORT ^= 1<<LED0;

Kommentier mal, was Du Dir dabei gedacht hast.


Peter

[Helfer (Gast)]

Dieser Code ohne Entprellung

  if (!( PIND & (1<<PIND4)))
  {
       //Aktion
  }

wird mit Hilfe der Routinen aus dem Artikel Entprellung so ersetzt

// Anpassungen der Defines an die tatsächliche Hardware 
#define KEY_DDR         DDRD
#define KEY_PORT        PORTD
#define KEY_PIN         PIND
#define KEY0            4
#define ALL_KEYS        (1<<KEY0)

#define REPEAT_MASK     (0)       // repeat: key1, key2
#define REPEAT_START    50        // after 500ms
#define REPEAT_NEXT     20        // every 200ms

// Unveränderter Restcode aus dem Artikel
...

// Anpassung der Tasterabfrage
  if ( get_key_press( 1<<KEY0 ) )
  {
       //Aktion
  }

[Helfer (Gast)]

> // Unveränderter Restcode aus dem Artikel
> ...
>
> // Anpassung der Tasterabfrage

Kleine Korrektur:

"Unveränderter Restcode" ist ungenau geschrieben.

Der Inhalt des while(1)-Anweisungsblocks ist im Artikel nur ein Beispiel 
für die vielfältigen Einsatzmöglichkeiten.

Dieser Teil muss durch eigenen Code mit der "Anpassung der 
Tasterabfrage" ersetzt werden.

[Carsten (Gast)]

Hallo,

danke für die Hinweise. Ein Ozi besitze ich leider nicht, daher kann ich 
nicht sagen ob der Ausgang so schnell blinkt. Ich glaube dir aber, das 
es so ist, Peter.

Was ich mir mit if(!(Abfrage)) gedachte kann ich im inzwischen auch 
nicht mehr so ganz nachvollziehen.

Mir scheint das zurzeit das größe Problem darin besteht, das ich mit 
16Mhz arbeite und das Beispiel auf 1Mhz basiert. Hier könnte vielleicht 
REPEAT_START und REPEAT_NEXT mit größernen Werten helfen???

Bevor ich aber weiter Glaskugelraten mache, muss ich mir wohl das 
Tutorial mit den Bitoperationen mal sehr genau durchlesen und endlich 
genau nachzuvollziehen, was Peter mit seinem Code bewirkt.

Ich zwar habe versucht im AVR Studio den Simulator zu nutzen, hier gab 
es aber Limitierungen mit dem Interrupt (?) wenn ich mich richtig 
entsinne.

Gruß
Carsten

[Hannes L. (hannes)]

Carsten schrieb:
> Mir scheint das zurzeit das größe Problem darin besteht, das ich mit
> 16Mhz arbeite und das Beispiel auf 1Mhz basiert.

Warum arbeitest Du mit 16 MHz?

...

[Carsten (Gast)]

Mir kam erst später der Gedanke, das ich die Fuse bits anders setzen 
kann. Ich war der Meinung, das in dem Moment, wenn ein externe4s Quarz 
angeschlossen wird, diese auch genutzt werden muss.

Ein Irrglaube wie mir das Datenblatt verriet. Leider haben mich meine 
versuche mit 1Mhz Takt noch nicht zum Ziel gebracht.

gruß
Carsten

[Carsten (Gast)]

So Problem gelöst und es sahs mal wider vor dem Monitor.

Beim Umstellen des Timer habe ich anstelle:

>  TCCR0B = (1<<CS02)|(1<<CS00);      // divide by 1024
>  TIMSK0 |= 1<<TOIE0;        // enable timer interrupt

folgendes geschrieben:

>  TCCR0A = (1<<CS02)|(1<<CS00);      // divide by 1024
>  TIMSK0 |= 1<<TOIE0;        // enable timer interrupt

Nur dummerweise besitzt TCCR0A kein CSxx, es wundert mich nur das der 
Compiler es zugelasssen hat.

Danke mal ein mal für eure Unterstützung.

Gruß
Carsten

[Helfer (Gast)]

> Nur dummerweise besitzt TCCR0A kein CSxx, es wundert mich nur das der
> Compiler es zugelasssen hat.

An der Stelle ist das nur Textersetzung und Vorberechnung (<<). CS02 an 
sich ist definiert. Die Bits in den Registern werden aber nicht 
kontrolliert.

Beim Simulieren könnte es aufallen, wenn man sich die Spezialregister in 
der I/O View anschaut und dort Bitweise aufdröselt.