@andre

"Wie muss ich vorgehen, wenn ich mit einem Taster bei kurzem und
langem (ca. 1 sek) zwei verschiedene Aktionen durchführen möchte?"

short = kurz
long = lang

//
      // release after short press: task 1
      // long press: task 2

    if( get_key_short( 1<<KEY1 ))
      LED_PORT ^= 1<<LED1;

    if( get_key_long( 1<<KEY1 ))
      LED_PORT ^= 1<<LED2;

Peter

atomic meint, nicht durch Interrupts unterbrechbar und das bewirkt man
mit der Klammerung durch cli() + sei().

Nur C-Instruktionen, die in eine einzige Assemblerinstruktion übersetzt
werden, sind von Haus aus atomic (nicht teilbar).


Peter

@duundich

Meinst Du ne Shift-Taste ?

if( get_key_press( 1<<KEY1 ){
  if( key_state & (1<<SHIFT_KEY) ){
// do action Shift + KEY1
  }else{
// do action KEY1
  }
}

Peter

@noXe

"Ne Idee was ich falsch gemacht haben könnte?"


Tja, was soll man dazu sagen ?

Wenn wenigstens die komplette Source als Anhang dabei wäre, dann könnte
man schonmal Softwarefehler suchen. Aber hellsehen kann ich leider
nicht.

Und so ins Blaue: "Versuch es mal mit 1 Mhz." bringt meistens
nichts.


Peter

Hallo zusammen,

ich hab nochmal eine Frage zum deaktivieren der Interrups.

Folgendes:
Ich hab den Code "missbraucht" um eine Tastenabfrage über RS232 zu
realisieren. Das sieht im Prinzip so aus:
Jedesmal wenn eine Taste gedrückt wird (oder losgelassen) wird der
keystate in einem byte gesendet.
Jedes Bit steht dabei für eine Taste.
Dieses Byte wird dann einfach für den "ursprünglichen" Tastenport
verwendet!

Ich weiss, dass das garantiert auch eleganter gelöst werden kann aber
mir gefällt es da ich dann auch ohne weiteres die zusätzlichen
Tastenfunktionen nutzen kann (außerdem bin ich ein absoluter
Programier-Anfänger so dass ich froh bin wenn es für etwas schon eine
fertige Lösung gibt ;-)) - und es funktioniert soweit!

Das Problem das ich jetzt seh ist, wenn die Interrups deaktiviert sind
kann ja auch kein neuer keystate empfangen werden - wie wahrscheinlich
das ganze ist sein mal dahingestellt (der keystate wird zuerst bei einem
receive-interrupt in einen Buffer geschrieben...) aber es ist nunmal
Möglich!

Deshalb nochmal die Frage (ich habs oben nicht ganz verstanden):
Warum verlier ich den Tastendruck (nehmen wir mal an, dass die Tasten an
einem Port sind)?
Und kann ich z.B. einfach alle Interrups außer dem
UART-Receive-Interrupt deaktivieren? Ich mein das sind doch ganz andere
Zeitdimensionen (empfangen -> in Buffer schreiben -> Buffer
auswerten)...

Ich hoffe ihr könnt mir weiterhelfen

Gruß
Jörg

Markus wrote:

> Dazu sind doch die Funktionen short und long oder?

Genau.
Siehe Beispiel.
Nicht vergessen, die Taste in REPEAT_MASK einzutragen.


Peter

Hallo Peter,
ich habe mich gerade mit deinem Code beschäftigt.
Ich glaube ich habe dabei nen Fehler gefunden:
und zwar einen allgemeinen Fehler bei der Behandlung von lange
gedrückten Tasten. Wenn ich deine Routine in der ISR richtig verstehe,
dann setzt du die rpt Zählvariable immer wieder auf den Ausgangswert
solange keine Taste gedrückt wird. Sobald eine Taste gedrückt ist,
geschieht dies nicht mehr und die rpt wird heruntergezählt. Jedoch
unterscheidet deine Routine dann nicht welche Taste gedrückt ist und wie
lange bereits. Kann nicht im Moment der Fall eintretten, dass (Annahme
REPEAT_START = 50) Taste 1 die ersten 40 Interrupts gedrückt ist und
nach Interrupt 30 auch noch Taste 2 hinzukommt. Nun wird im Code nach 50
Interrupts bei Taste 2 ein langes drücken festgestellt, obwohl sie nur
20 Interrupts gedrückt war. Ich hoffe das ist so weit verständlich.
Und sollte auch nur als Anregung dienen.

Gruß Thomas

@Thomas,

das ist absichtlich so.

In der Praxis ist es so, daß man nur eine Taste lange drückt, z.B. count
up und losläßt, wenn der gewünschte Wert erreicht ist.
Würde man gleichzeitig count down drücken, würde der Wert immer +1,-1
machen, was ja ziemlich sinnlos ist.


Damit man eine Shift-Taste definieren kann (z.B. count +1, oder +10),
gibt es die Maske mit der nur die Repeat-Tasten definiert werden.

Zu entprellende Eingänge ohne Repeat können also gleichzeitig aktiv sein
(z.B. Endlagenschalter).


Peter

Hi Leutz,

ich versuche grad die Routine auf einem Mega32 mit 16MHz Takt zu
benutzen. Ich hab das Original C-Beispiel aus der Artikelsammlung
benutzt (http://www.mikrocontroller.net/articles/Entprellung). Zur
Auswertung geb ich einen Text auf ein LCD aus:

    if( get_key_press( 1<<KEY0 )) {
      lcd_gotoxy(0,1);
      lcd_puts("T0");            
                    }
    if( get_key_press( 1<<KEY1 )) {
      lcd_gotoxy(0,1);
      lcd_puts("T1");            
                    }

    if( get_key_press( 1<<KEY2 )) {
      lcd_gotoxy(0,1);
      lcd_puts("T2");            
                    }

Soweit funktioniert das auch, nur zeigt bei mit der erste Taster T0 oft
fälschlicherweise T1 an. Und zwar immer wenn vorher eine andere Taste
gedrückt war. Ich hab schon die verschiedensten Sachen probiert, weiss
mir aber mittlerweile nicht mehr weiter. Any hints?

Markus

Markus _neu wrote:

> Soweit funktioniert das auch, nur zeigt bei mit der erste Taster T0 oft
> fälschlicherweise T1 an. Und zwar immer wenn vorher eine andere Taste
> gedrückt war. Ich hab schon die verschiedensten Sachen probiert, weiss
> mir aber mittlerweile nicht mehr weiter. Any hints?

Wackler, Kurzschluß, unterbrochene Pullups, ...


Schreib mal die LCD-Texte hintereinander, dann sieht mans besser.

So weißt Du ja nicht, ob ein Text von einem anderen überschrieben wurde
und wie oft er geschrieben wird.


Peter

Peter Dannegger wrote:
>
>
> Schreib mal die LCD-Texte hintereinander, dann sieht mans besser.
>
> So weißt Du ja nicht, ob ein Text von einem anderen überschrieben wurde
> und wie oft er geschrieben wird.
>
>
> Peter

Ja, gute Idee. Werd ich heute abend gleich mal probieren.

Markus

Hi,

danke für deine Tipps Peter. Das Problem waren nicht aktivierte interne
Pullups !?!

Hab ich völlig übersehen. Durch das hinternander schreiben der Ausgabe
konnte ich sehen dass da tatsächlich teilweise mehrere Tasterdrücke auf
einmal registriert wurden.

Gruß - Markus

@ mgiaco (Gast)

>Was machen wenn man 10 Tasten braucht?

Da wird man wohl oder übel den Code anpassen müssen und auf zwei Ports
zugreifen müssen. Oder gleich ne Matrix aufbauen, ist auch in der
Codesamlung verfügbar.

MFG
Falk

Falk Brunner wrote:
> @ mgiaco (Gast)
>
>>Was machen wenn man 10 Tasten braucht?
>
> Da wird man wohl oder übel den Code anpassen müssen und auf zwei Ports
> zugreifen müssen. Oder gleich ne Matrix aufbauen, ist auch in der
> Codesamlung verfügbar.
>
> MFG
> Falk

Hallo,

drei!!! Ports (einer für Matrix, zwei für je 8 Tasten) würde mich auch
(in gleichzeitiger Interrupt Abfrage!!!) interessieren. Habe leider
nichts hierzu gefunden - liegt das an mir - gibt es so etwas schon ?

Habe versucht Peter's Beispiel dahingehend zu erweitern ... aber
anscheinend funzt meine Erweiterung manchmal nicht, an anderen Tagen
problemlos ....!

Würde mich daher lieber auf professionellen Code verlassen!

Peter, hast Du vielleicht einen Hinweis, wie man so etwas professionell
implementiert ? Wie würdest Du Deine Routine erweitern ? Matrix an sich
ist kein Problem. Problem ist der Portwechsel ... Tasten verschiedener
Ports im Wechsel ....!!!!

Vielen Dank im voraus,

Grüsse

Hallo,

auch ich hab Peters Code "Debouncing" eingesetzt und meiner Anwendung
Pollin Atmel Evaluation-Board V2) angepasst. Dies Funktioniert soweit
ganz gut mit einer Ausnahme von KEY2.
Vielleicht liegt es daran, weil ich mit einem Pull-Down Widerstand
arbeite und der Taster gegen VCC schaltet!

Nun will ich diesen Code besser verstehen. Wer kann mir die Funktion
erläutern?

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
      uint8_t i = LED_PORT;
 
      i = (i & 0x07) | ((i << 1) & 0xF0);
      if( i < 0xF0 )
        i |= 0x08;
      LED_PORT = i; 

Vorab vielen Dank; Gruß Werner

Werner Dornstädter wrote:

> Nun will ich diesen Code besser verstehen. Wer kann mir die Funktion
> erläutern?
>
>

if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
>       uint8_t i = LED_PORT;
> 
>       i = (i & 0x07) | ((i << 1) & 0xF0);
>       if( i < 0xF0 )
>         i |= 0x08;
>       LED_PORT = i; 

>


Lauflicht über die obersten 5 LEDs.

Daran sieht man schön die Wiederholfunktion.


Peter

Bastler wrote:
> Das Problem ist nämlich, dass der controller durch einen Tastendruck in
> den power-down mode versetzt werden soll, und mit einem Flankeninterrupt
> wieder aufwacht.
> D.h. bei einem langen Tastendruck wacht er durch die Flanke beim
> Loslassen sofort wieder auf.

Na dann wartste eben bis zum Loslassen:

if( get_key_long( 1<<KEY0 )){
  while( keystate & 1<<KEY0 );
  sleep();
}

Peter

Geniales Programm ,aber kann mir nochmal wer die Bedeutung der Zeile

TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5);

erklären. Falls ich eine Taktfrequenz von 1Mhz habe dann lautet das
Ganze ja wie folgt:

1000000/1024 * 10e-3 + 0.5 = 1.47

ich verstehe den Zusammenhang zwischen 1.47 und 10ms nicht?!

Hannes S. wrote:
> Geniales Programm ,aber kann mir nochmal wer die Bedeutung der Zeile
>
> TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5);
>
> erklären. Falls ich eine Taktfrequenz von 1Mhz habe dann lautet das
> Ganze ja wie folgt:
>
> 1000000/1024 * 10e-3 + 0.5 = 1.47

Nö, da kommt 10,26 raus, also Teilerwert 10.

1MHz / 1024 / 10 = 97,6Hz = 10,2ms

Peter

Danke Micha - hab den ganzen Thead schon gelesen - war mir aber immer
noch nicht klar - soll vorkommen!

@Peter

Ja es is aber auch ein Unterschied ob ich:
"1MHz/1024 * 10e-3 + 0.5" oder
"1MHz  1024  10"

rechne. Bei der Zweiten Rechnung kommt schon 97,6Hz raus. Aber eben bei
der oberen nicht. Dennoch funktionierts richtig. Irgendwie muss ich
gerade voll am Schlauch stehen....

Mhmhhm, gott. Der Fehler lag mal wieder im Detail. Hab wohl die
Scientific Notation schon zu lange nichtmehr benutzt..
10e-3 ist ja 10*10^-3 und nicht 10^-3
Danke für die Erklärungen ;-)

noXe wrote:
> Kann einer bitte den Quellcode überfliegen

sieht o.k. aus.

Gib doch einfach mal den Input-Port direkt aus, ob das geht.


Peter

dom wrote:
> reicht es aus anstatt sei() und cli() bloß den Timer-Interrupt zu
> sperren?

Was soll denn das bringen, außer mehr Code?


Peter

dom wrote:
> Ich möchte nicht, dass ein bestimmter Interrupt dadurch gesperrt wird.

Das läßt sich aber nicht verhindern.

Immer wenn ein Interrupthandler ausgeführt wird, sind alle Interrupts
gesperrt. Dagegen sind die 4 Zyklen für den atomaren Zugriff nur
Pillepalle.

Jedes Programm enthält unweigerlich kurze Sperren und bisher hat das
auch noch keinen Programmierer gestört.


Peter

@Philipp

Versuchs mal hiermit:

u8 get_key_long2( u8 key_mask )
{
  return get_key_press( get_key_rpt( key_press^key_mask ));
}


u8 get_key_long_rpt( u8 key_mask )
{
  return get_key_rpt( ~key_press^key_mask );
}

get_key_short: ein/aus
get_key_long2: Dimmrichtung wechseln
get_key_long_rpt: dimmem.


Peter

Hallo,

ich hab das Entprellen von 8 Tasten mal als Fingerübung (nach 20 Jahren
Einchip und C-Pause) auf eine Matrix mit Multiplexansteuerung der LED's
erweitert (Ziel: XPressNet Schaltpult für die Modellbahn).

So können mit 2 Port's 64 Schalter und 64 LED's mit wenig Aufwand
angesteuert werden. Die LED's können parallel zum Taster liegen, jeweils
an Zeilen und Spalten sollte ein Vorwiderstand zur Einhaltung der max.
Ströme am AVR vorgeschaltet sein. Ich hab je 470 Ohm genommen, da sind
bei 8 Zeilen die LED's hell genug.

Die Tasten landen nun in dieser Version in einem Array, die LED's werden
ebenfalls in ein Array eingetragen und dann per Interrupt ausgegeben. Um
Flackern zu vermeiden wurde der Timer-Int auf 2,5ms verkürzt.

Eine Erweiterung auf mehr Spalten ist ohne Probleme, evtl. kann man da
Schieberegister verwenden. bei den Zeilen würde ich bei max. 8 bleiben,
da sonst die Helligkeit der LED's wohl zu gering wird, auch wird das
Einlesen und Handhaben der Tasten mit mehr 8bit schwieriger.

vg jens

man kann den anhang im Bearbeiten wohl nicht anhängen, hiermit also noch
mal anbei.

#include <stdint.h>
#include <avr/io.h>
#include <avr/interrupt.h>

#ifndef F_CPU
#define F_CPU           16000000                   // processor clock frequency geändert
#warning kein F_CPU definiert
#endif


#define KEY_DDR         DDRB
#define KEY_PORT        PORTB
#define KEY_PIN         PINB
#define KEY0            0
#define KEY1            1
#define KEY2            2
#define ALL_KEYS        (1<<KEY0 | 1<<KEY1 | 1<<KEY2)

#define REPEAT_MASK     (1<<KEY1 | 1<<KEY2)       // repeat: key1, key2
#define REPEAT_START    1000                        //Zeit geändert
#define REPEAT_NEXT     500                        // Zeit geändert

#define LED_DDR         DDRA
#define LED_PORT        PORTA
#define LED0            0
#define LED1            1
#define LED2            2

volatile uint8_t key_state;                                // debounced and inverted key state:
                                                  // bit = 1: key pressed
volatile uint8_t key_press;                                // key press detect

volatile uint8_t key_rpt;                                  // key long press and repeat


ISR( TIMER0_OVF_vect )                            // every 10ms
{
  static uint8_t ct0, ct1, rpt;
  uint8_t i;

  TCNT0 = (uint8_t)(int16_t)-(F_CPU / 1024 * 10e-3 + 0.5);  // preload for 10ms

  i = key_state ^ ~KEY_PIN;                       // key changed ?
  ct0 = ~( ct0 & i );                             // reset or count ct0
  ct1 = ct0 ^ (ct1 & i);                          // reset or count ct1
  i &= ct0 & ct1;                                 // count until roll over ?
  key_state ^= i;                                 // then toggle debounced state
  key_press |= key_state & i;                     // 0->1: key press detect

  if( (key_state & REPEAT_MASK) == 0 )            // check repeat function
     rpt = REPEAT_START;                          // start delay
  if( --rpt == 0 ){
    rpt = REPEAT_NEXT;                            // repeat delay
    key_rpt |= key_state & REPEAT_MASK;
  }
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
  cli();                                          // read and clear atomic !
  key_mask &= key_press;                          // read key(s)
  key_press ^= key_mask;                          // clear key(s)
  sei();
  return key_mask;
}

///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed long enough such that the
// key repeat functionality kicks in. After a small setup delay
// the key is reported beeing pressed in subsequent calls
// to this function. This simulates the user repeatedly
// pressing and releasing the key.
//
uint8_t get_key_rpt( uint8_t key_mask )
{
  cli();                                          // read and clear atomic !
  key_mask &= key_rpt;                            // read key(s)
  key_rpt ^= key_mask;                            // clear key(s)
  sei();
  return key_mask;
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_short( uint8_t key_mask )
{
  cli();                                          // read key state and key press atomic !
  return get_key_press( ~key_state & key_mask );
}

///////////////////////////////////////////////////////////////////
//
uint8_t get_key_long( uint8_t key_mask )
{
  return get_key_press( get_key_rpt( key_mask ));
}

int main( void )
{
  KEY_DDR &= ~ALL_KEYS;                // konfigure key port for input
  KEY_PORT |= ALL_KEYS;                // and turn on pull up resistors

  TCCR0 = (1<<CS02)|(1<<CS00);      // divide by 1024
  TIMSK = 1<<TOIE0;        // enable timer interrupt

  LED_PORT = 0xFF;
  LED_DDR = 0xFF;

  while(1){
    if( get_key_short( 1<<KEY1 ))
      LED_PORT ^= 1<<LED1;

    if( get_key_long( 1<<KEY1 ))
      LED_PORT ^= 1<<LED2;

                                                  // single press and repeat

    if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 )){
      uint8_t i = LED_PORT;

      i = (i & 0x07) | ((i << 1) & 0xF0);
      if( i < 0xF0 )
        i |= 0x08;
      LED_PORT = i;
    }
  }
}

Hallo
Atmega128 16Mhz (code-blocks-ubuntu.9.04-libc1.6.2.)
bei mir funktioniert nur  Eingang PINB2 (0und 1nicht)
bei gedrücktem Taster läuft die schleife durch!! wie ein lauflicht mit
500ms
andere Anwendungen (blinken Standard funktionieren auf den ports

> //Hallo
> // Atmega128 16Mhz (code-blocks-ubuntu.9.04-libc1.6.2.)
> //bei mir funktioniert nur  Eingang PINB2 (0und 1nicht)
> //bei gedrücktem Taster läuft die schleife durch!! wie ein lauflicht mit
> //500ms
> //andere Anwendungen (blinken Standard funktionieren auf den ports

Kann den Beitrag nicht mehr ändern als Quellcode
mache es jetzt (habs zuspät gelesen)

Stefan Strauß schrieb:
> #define REPEAT_START    1000                        //Zeit geändert
> #define REPEAT_NEXT     500                        // Zeit geändert

Eine Repeatfunktion mit 10s / 5s Wartezeit ist ziemlich witzlos.
In ein uint8_t passen außerdem nur max 255.
Max 2,55s bei 10ms Interrupt sollte wohl reichen.


Peter

Hallo Peter
der 128er läuft mit 16Mhz
wenn ich hier nichts ändere kann ich nicht kontrolliert die LED`s weiter
tasten ( rennt einfach durch) jetzt hat er eine Schaltzeit von ca 250ms
bei dem wert wo 1000 steht.
muß ich die Zeiten wo anders ändern?
gruß Stefan

Stefan Strauß schrieb:
 der 128er läuft mit 16Mhz

Lies Dir den Thread in Ruhe durch, wo die Quarzfrequenz festgelegt wird.


> bei dem wert wo 1000 steht.

Ich hab Dir doch schon gesagt, daß das Mumpitz ist.
Nimm auch mal die Compilerwarnungen ernst:

C_TAST.C:58: warning: large integer implicitly truncated to unsigned type

> muß ich die Zeiten wo anders ändern?

Warum willst Du 10s?


Sind Deine Tasten gegen GND?
Daß KEY0 nicht geht, liegt einfach daran, daß Du in garnicht verwendest.
Ich hab den Eindruck, Du verstehst überhaupt nicht, was Du da schreibst.
Hast Du vorher schonmal in C programmiert?


Peter

Hallo (vor allem Jens),
der Thread ist genau, was ich suchte. Vor allem das Feature mit
"Lange-Druecken-Erkennung" finde ich cool. Ich will auch eine kleine
Tastaturmatrix ansteuern, deshalb habe ich mir die Codeanpassung von
Jens Kuehn (vom Februar) hergenommen. Bei mir funktioniert's aber (nach
Murphy) natuerlich noch nicht so ganz.

Zum Verstaendnis habe ich an Jens folgende Fragen:
1) KEY0...2 und ZEILE0...2 sind doch m.E. synonym; hast Du die wegen des
Bezugs zu Peters Originalcode dringelassen?
2) Meine Zeilenleitungen sind PD2...PD7, also muss ich doch auch bei
KEY0...5 und bei ZEILE0...5 die 2...7 eintragen, oder?

Hintergrund: Ich will ueber Kippschalterchen, die eine Ruhestellung
haben und nach oben und unten getastet werden und einen ATMega(8) und
Servos die Weichen meiner Modellbahn schalten. (Die Schalter-Bedienung
finde ich ziemlich intuitiv und Vollautomatisierung will ich (noch)
nicht.) Dafuer wollte ich "oben" und "unten", also PB0 und PB1, als
Spalten an die Schalterchen anlegen und die jeweiligen mittleren
Schalterkontakte als Zeileneingaenge, also PD2...PD7, abfragen.

Der Effekt ist jetzt ganz komisch: zum Testen habe ich einen solchen
Schalter angeschlossen, der eine Lumi nach oben an- und nach unten
ausschalten soll. An geht bei jedem dritten mal, manchmal auch bei jedem
vierten, manchmal geht's aber da auch aus, wo's eigentlich nur angehen
soll ...

Muss wohl noch etwas 'rumdebuggen. Dankeschoen auf alle Faelle schonmal
an Peter und Jens fuer den coolen Code.
Viele Gruesse!

Hallo Arwed,

die lange Tastenerkennung hab ich nicht mehr drin, ansonsten habe ich
aber an dem Code noch viel geändert, so wie er oben steht kann er nicht
so richtig gehen. Ich muss es aber noch mal aufbereiten (bisher gab es
nicht so viel Interesse) und stelle es dann hier noch mal ein. ich
hoffe, ich schaff es am Wochenende.

Ich setze es übrigens auch für die Moba ein, hab es allerdings als
Schaltpult an einer Zentrale (opendcc.de) hängen und kann dann auch ohne
PC weiter meine Signale und Weichen schalten.

viele Grüße

jens

hab es gleich noch gemacht ...

in der zip ist das AVR-projekt und eine PDF als Schaltplan. Sorry, der
Code ist etwas unordentlich. Es gibt nun noch ein Array welches einen
Blinkmodus für die LED's einbaut.

Bei einem muss ich Dich aber enttäuschen: Kippschalter gehen nicht, weil
Du damit eine Spalte/Zeile 'tot legst' das geht bei einer Matrix halt
nicht.

vg jens

Danke Jens,
das werde ich probieren. Dass die Erkennung des lange Drueckens nicht
mehr drin ist, ist natuerlich schade. Ich werde mich mal dran versuchen.
Muesste beim Vergleich mit Peters Originalcode ja 'rauszufinden sein.

Aber dass Dein (alter) Code nicht geht, kann ich nicht bestaetigen.
Mittlerweile habe ich den Fehler gefunden: Ich hatte ein Quarz-Gehaeuse
so dicht an den Pins des ATMega, dass der "so'n bissel" Kurzschluss
gemacht hat ... Sonst tut's aber nun!

Die Kippschalter sind eigentlich Kipptaster, also mit Nullstellung und
je einer Taststellung oben und unten. Das passt schon. Die Mitte eines
solchen Tasters kommt an je eine Zeile und "oben" und "unten" gemeinsam
an die beiden Spalten.

Danke auch fuer den Schaltplan; mit den LED's war mir das noch nicht
ganz klar.

Viele Gruesse von Arwed

p.s.: Aber kann man nicht doch die KEY-Definitionen weglassen und
stattdessen ueberall die ZEILE-Definitionen? Also codetechnisch ja
sowieso, aber ich meine auch inhaltlich? Was bei Peter die KEYs waren,
sind doch nun die ZEILEn, dachte ich ...

[quote]Aber dass Dein (alter) Code nicht geht, kann ich nicht
bestaetigen.
[/quote]
ja, prinzipiell ging er schon. Geändert hab ich glaub ich noch etwas
weil sonst der Interrupt meine Datentransferroutinen blockierte und in
dem alten code flackern die LED's glaub ich noch.

[quote]Die Kippschalter sind eigentlich Kipptaster, also mit
Nullstellung und
je einer Taststellung oben und unten. Das passt schon. Die Mitte eines
solchen Tasters kommt an je eine Zeile und "oben" und "unten" gemeinsam
an die beiden Spalten.[/quote]
das passt gut, der Verdrahtungsaufwand wird dadurch ja noch geringer

[quote]Aber kann man nicht doch die KEY-Definitionen weglassen und
stattdessen ueberall die ZEILE-Definitionen? Also codetechnisch ja
sowieso, aber ich meine auch inhaltlich? Was bei Peter die KEYs waren,
sind doch nun die ZEILEn, dachte ich ...[/quote]

das ist doch nur eine Frage was für Dich besser verständlich ist. Ich
hatte es dann doch auf den KEY0 ... gelassen (so nach dem Motto: Taste 0
in der Spalte X). Du kannst einfach alle KEY0 durch ZEILE0 ersetzen, das
wird auch gehen. Und die Definition selbst isst ja kein Brot ... da kann
man auch beide Varianten definieren und im Code dann je nach besserer
Verständlichkeit verwenden.

Zum Schaltplan evtl. noch ein Hinweis: die Vorwiderstände kannst Du
evtl. noch größer machen, wenn Deine LED's hell genug sind. Ich hab
Taster mit eingebauter LED, die funzeln recht trübe. Gegenüber einer
normalen Ansteuerung brauchst Du aber immer etwas mehr Strom, da die ja
nur 1/8 der Zeit Strom bekommen.

viel Spaß

jens

Hallo,
ich habe mir nochmal Jens' Code hergenommen und mit Peters verglichen,
weil ich (noch) keine Lumis ueber den Tasten brauche, aber die
Long-Funktion haben wollte. Dabei habe ich festgestellt, dass Jens die
ct0 und ct1 bei jdem ISR-Durchlauf auf 0 gesetzt hat; geht denn das in
Ordnung? Eigentlich hatte ich es so verstanden, dass die ueber die ISR
hinaus ihre Werte behalten sollen, oder? Und die muessen daher doch auch
einmal je Spalte dasein?!
Ich habe mich nun nochmal dran versucht und in Zeitlupe debuggt und habe
nun folgende ISR:

ISR( TIMER0_OVF_vect ){
  static uint8_t ct0[SPALTENANZAHL], ct1[SPALTENANZAHL], rpt;
  uint8_t i;
  uint8_t key_mpex;    //die aktive Tasten-Spalte

  TCNT0 = TIMER0_STARTVALUE;
  //jetzt alle Spalten durcharbeiten
  for( key_mpex=0; key_mpex < SPALTENANZAHL; ++key_mpex ){
    i = 0;
    SPALTE_PORT &= ~(1<<(spalten_pin[key_mpex])); //aktive Spalte auf 0 
    i = key_state[key_mpex] ^ ~ZEILE_PIN;         // key changed ?
    ct0[key_mpex] = ~( ct0[key_mpex] & i );       // reset or count ct0
    ct1[key_mpex] = ct0[key_mpex] ^ (ct1[key_mpex] & i); // dito ct1
    i &= ct0[key_mpex] & ct1[key_mpex];    // count until roll over ?
    key_state[key_mpex] ^= i;             // then toggle debounced state
    key_press[key_mpex] |= key_state[key_mpex] & i; // 0->1: key pressed
    if( (key_state[key_mpex] & REPEAT_MASK) == 0 )  // check repeat fct.
      rpt = REPEAT_START;                           // start delay
    if( --rpt == 0 ){
      rpt = REPEAT_NEXT;                            // repeat delay
      key_rpt[key_mpex] |= key_state[key_mpex] & REPEAT_MASK;
    }   
    SPALTE_PORT |= (1<<(spalten_pin[key_mpex])); //Spalte deaktivieren
  }
}

Das tut soweit wunderbar -- solange ich nur mit get_key_press() abfrage;
aber get_key_rpt liefert nix und get_key_long verhaelt sich entweder wie
get_key_press oder gar nicht.
Ich habe den Repeat-Trick noch nicht ganz verstanden; muss da nicht auch
noch eine Repeat-Variable je Spalte rein, also so aehnlich wie
key_state?
Viele Gruesse ...

MarkusK schrieb:
> F_CPU steht auch auf 14745600UL.

Versuchs mal mit XTAL.


Peter

Versuchs mal mit XTAL ... statt F_CPU.

Du darfst Dir das Programm ruhig durchlesen. Dann wirst Du merken, daß
ich XTAL verwende, aber nirgends F_CPU.


Peter

hallo,

hab heute mein avr starterboard von pollin bekommen und damit etwas
rumgespielt (verwende einen atmega32). wenn ich nun eine taste extrem
schnell nacheinander drücke (man muss sich schon etwas anstrengen um das
hinzubekommen) macht mein atmega einen reset!?


gruß,
marco

Das liegt an der "Buggy" Beschaltung der Tasten auf dem Pollin Board.
Siehe Beitrag "Pollin AVR Board Fehler beim drücken der Taster / Qualität der Bauteile"

Hans-Peter schrieb:
> Hallo,
>
> ich bins nochmal, hat denn keiner eine Idee wieso nach dem Erkennen des
> wiederholten langen Drucks auch ein kurzer Tastendruck erkannt wird?
>
> Grüße
> Hans-Peter

Du mußt dann alle 3 Funktionen aufrufen:

if( get_key_short( xxx )){
...
}
if( get_key_long2( xxx ) || get_key_long_rpt( xxx )){
...
}

Versuch mal zu beschreiben, warum.


Peter

eku schrieb:
> Ich entprelle 4 tasten mit Peters Routine. Allerdings schaffe ich es
> nicht, mehr als eine Taste gleichzeitig erkannt zu bekommen obwohl ich
> zwei nebeneinander liegende Tasten praktisch mit einem Finger betätige.

Du müßtest beide innerhalb des gleichen 10ms-Fensters drücken, das ist
recht sportlich.
Für den MC drückst Du sie also nacheinander.

> Wie muß man den Source verändern, das mehrere Tasten erkannt werden?

Du könntest eine als Shifttaste definieren, d.h. kurz vorher gedrückt
halten:

  if( get_key_press( 1<<USER_KEY0 )){
    if( key_state & 1<<SHIFT_KEY ){
      // shift + userkey0
    }else{
      // only userkey0 
    }
  }

Peter

Das Problem ist, die CPU kann nicht Deine Gedanken lesen.

Woher soll sie den wissen, daß Du etwa 300ms später eine 2.Taste drücken
wirst und das dann als 2-Tastendruck erkannt werden soll und der 300ms
vorher erkannte 1-Tastendruck ungültig gewesen war?

Du mußt einen eindeutige Regel definieren, wie die CPU etwas
unterscheiden soll.
Mach Dir mal nen Programmablaufplan und dann erst kann man den
implementieren.

Bedenke auch, daß ältere Menschen deutlich länger benötigen werden, 2
Tasten gleichzeitig (innerhalb eines Zeitintervalls) zu drücken. Bzw. ob
das überhaupt benutzerfeundlich (ergonomisch) ist.

Du wirst deshalb in kommerziellen Geräten keine solche Bedienung finden.
Da haben sich für Mehrfachbelegung die Sondertasten bewährt, deren
Funktion nur durch die Reihenfolge eindeutig bestimmt ist und damit die
unterschiedlichen motorischen Fähigkeiten verschiedener Menschen die
Bedienung nicht behindern/verhindern.


Peter

thomas schrieb:
> Sie funktioniert ja auch soweit, nur wenn ich die Taste nach langem
> Drücken loslasse, wird offensichtlich nochmal ein kurzer Tastendruck
> augelöst.

Ja, da hat sich ein Schreibfehler eingeschlichen. Das EXOR ist Unsinn,
muß ein AND sein.
Hier mal ein funktionierender Code:

/************************************************************************/
/*                                                                      */
/*                      Debouncing 8 Keys                               */
/*                      Sampling 4 Times                                */
/*                      With Repeat Function                            */
/*                                                                      */
/*              Author: Peter Dannegger                                 */
/*                                                                      */
/************************************************************************/

//                              Target: ATtiny13

#include <avr/interrupt.h>
#include <util/atomic.h>


#define F_CPU           1.2e6           // 1.2MHz

#define KEY_PIN         PINB
#define KEY_PORT        PORTB
#define KEY0            4

#define LED_DDR         DDRB
#define LED_PORT        PORTB
#define LED0            0
#define LED1            1
#define LED2            2
#define LED3            3


#define REPEAT_MASK     (1<<KEY0)       // repeat: key0
#define REPEAT_START    50              // after 500ms
#define REPEAT_NEXT     20              // every 200ms


uint8_t key_state;                      // debounced and inverted key state:
                                                // bit = 1: key pressed
uint8_t key_press;                      // key press detect
uint8_t key_rpt;                        // key long press and repeat


ISR( TIM0_COMPA_vect )                          // every 10ms
{
  static uint8_t ct0 = 0xFF, ct1 = 0xFF, rpt;
  uint8_t i;

  i = key_state ^ ~KEY_PIN;                     // key changed ?
  ct0 = ~( ct0 & i );                           // reset or count ct0
  ct1 = ct0 ^ (ct1 & i);                        // reset or count ct1
  i &= ct0 & ct1;                               // count until roll over ?
  key_state ^= i;                               // then toggle debounced state
  key_press |= key_state & i;                   // 0->1: key press detect

  if( (key_state & REPEAT_MASK) == 0 )          // check repeat function
     rpt = REPEAT_START;                        // start delay
  if( --rpt == 0 ){
    rpt = REPEAT_NEXT;                          // repeat delay
    key_rpt |= key_state & REPEAT_MASK;
  }
}


uint8_t get_key_press( uint8_t key_mask )
{
  ATOMIC_BLOCK(ATOMIC_FORCEON){
    key_mask &= key_press;                      // read key(s)
    key_press ^= key_mask;                      // clear key(s)
  }
  return key_mask;
}


uint8_t get_key_rpt( uint8_t key_mask )
{
  ATOMIC_BLOCK(ATOMIC_FORCEON){
    key_mask &= key_rpt;                        // read key(s)
    key_rpt ^= key_mask;                        // clear key(s)
  }
  return key_mask;
}


uint8_t get_key_short( uint8_t key_mask )
{
  uint8_t i;

  ATOMIC_BLOCK(ATOMIC_FORCEON)
    i = get_key_press( ~key_state & key_mask );
  return i;
}


uint8_t get_key_long( uint8_t key_mask )
{
  return get_key_press( get_key_rpt( key_mask ));
}


uint8_t get_key_long_r( uint8_t key_mask )      // if repeat function needed
{
  return get_key_press( get_key_rpt( key_press & key_mask ));
}


uint8_t get_key_rpt_l( uint8_t key_mask )       // if long function needed
{
  return get_key_rpt( ~key_press & key_mask );
}


int main( void )
{
  TCCR0A = 1<<WGM01;                                    // Mode 2. CTC
  TCCR0B = 1<<CS02 | 1<<CS00;                           // F_CPU / 1024
  OCR0A = F_CPU / 1024.0 * 10e-3 - 0.5;                 // 10ms interrupt
  TIMSK0 = 1<<OCIE0A;

  LED_PORT = 1<<LED0 | 1<<LED1 | 1<<LED2 | 1<<LED3;     // LEDs off
  LED_DDR = 1<<LED0 | 1<<LED1 | 1<<LED2 | 1<<LED3;
  KEY_PORT |= 1<<KEY0;                                  // Pullup on
  sei();

  for(;;){                                              // main loop

    if( get_key_short( 1<<KEY0 ))
      LED_PORT ^= 1<<LED0;

    if( get_key_long_r( 1<<KEY0 ))
      LED_PORT ^= 1<<LED1;

    if( get_key_rpt_l( 1<<KEY0 ))
      LED_PORT ^= 1<<LED2;
  }
}

Peter

Anmerkung:

Erlaubte Funktionen einer Taste:

- get_key_press()

- get_key_rpt()

- get_key_press() mit get_key_rpt()

- get_key_short() mit get_key_long()

- get_key_short() mit get_key_long_r() und get_key_rpt_l()


Peter

Ich weiß nicht, warum alle so scharf auf 2-Tastenbedienung sind.
Man muß einfach nur logisch denken, wie ein MC das erkennen soll, ohne
Hellseherei.

Man kann es mit meinen Funktionen erreichen. Gleichzeitig bedeutet dann,
innerhalb der Zeit zur Langdruckerkennung. Man kann also einen
Einzeldruck nicht mehr sofort erkennen.

  for(;;){                                              // main loop
    switch( get_key_long(  1<<KEY0 | 1<<KEY1 ) |
            get_key_short( 1<<KEY0 | 1<<KEY1 )){

      case 1<<KEY0:             LED_PORT ^= 1<<LED0; break;

      case 1<<KEY1:             LED_PORT ^= 1<<LED1; break;

      case 1<<KEY0 | 1<<KEY1:   LED_PORT ^= 1<<LED2; break;
    }
  }

Für 2-Tastendruck muß also immer lange gedrückt werden.
Kurze Drücke werden als einzeln gewertet. Will man das nicht, muß man
get_key_short aus dem Switch herausnehmen, aber man muß es trotzdem
aufrufen. Es wird nur nicht ausgewertet.


Aber wie schon gesagt, es ist weder sinnvoll, noch bedienerfreundlich.

Ich kann mir eigentlich nur eine einzige Anwendung denken:
Man hat eine gefährliche Maschine und will verhindern, daß der Bediener
hineingreift und zu Schaden kommt. Deshalb muß er mit je einer Hand eine
Taste drücken.
Damit der Bediener nun aber nicht eine Taste aus Bequemlichkeit
blockiert, muß er sie innerhalb einer bestimmten Zeit gleichzeitig
drücken.


Peter

Verbesserte Version:

  for(;;){                                              // main loop
    switch( get_key_long(  1<<KEY0 | 1<<KEY1 ) |
            get_key_short( 1<<KEY0 | 1<<KEY1 )){

      case 1<<KEY0:             LED_PORT ^= 1<<LED0; break;

      case 1<<KEY1:             LED_PORT ^= 1<<LED1; break;

      default:
                if((key_press & (1<<KEY0 | 1<<KEY1)) != (1<<KEY0 | 1<<KEY1))
                  break;
                get_key_press( 1<<KEY0 | 1<<KEY1 );

      case 1<<KEY0 | 1<<KEY1:   LED_PORT ^= 1<<LED2; break;
    }
  }

Peter

So, jetzt noch einfacher, mit ner extra Funktion für die 2 Tasten
Erkennung.
Man kann auch auswählen, ob der Druck beider Tasten innerhalb einer
bestimmte Zeit erfolgen soll (#define TIMEOUT)

uint8_t get_key_common( uint8_t key_mask )
{
  return get_key_press((key_press & key_mask) == key_mask ? key_mask : 0);
}

// ...

//#define TIMEOUT

  for(;;){                                              // main loop
#ifdef TIMEOUT
    if( get_key_short( 1<<KEY0 ) || get_key_long( 1<<KEY0 ))
      LED_PORT ^= 1<<LED0;

    if( get_key_short( 1<<KEY1 ) || get_key_long( 1<<KEY1 ))
      LED_PORT ^= 1<<LED1;
#else
    if( get_key_short( 1<<KEY0 ))
      LED_PORT ^= 1<<LED0;

    if( get_key_short( 1<<KEY1 ))
      LED_PORT ^= 1<<LED1;
#endif
    if( get_key_common( 1<<KEY0 | 1<<KEY1 ))
      LED_PORT ^= 1<<LED2;
  }

Peter

Hallo,

@peda: Du hattest ja beschrieben welche Funktionen zusammen zulässig
sind:

Peter Dannegger schrieb:
> Erlaubte Funktionen einer Taste:
>
> - get_key_press()
>
> - get_key_rpt()
>
> - get_key_press() mit get_key_rpt()
>
> - get_key_short() mit get_key_long()
>
> - get_key_short() mit get_key_long_r() und get_key_rpt_l()

Sehe ich das richtig, dass *get_key_long_r()* nur die long-Funktion ist
wenn man auch noch *get_key_rpt_l()* (Repeat während lang gedrückt)
nutzen möchte?

Ich suche nach einer Möglichkeit das Loslassen einer Taste, die zuvor
lang gedrückt war zu detektieren. Ein Repeat beim lang gedrückt halten
müsste ich hier nicht mehr detektieren können.

Das müsste doch möglich sein, oder?
Vielleicht hat jemand das ja schonmal in eine Funktion gegossen oder
kann mir sagen wie ich dazu die Aufrufe kombinieren muss?

Vielen Dank schonmal!

Gruß
Fabian

Gibts dazu keine Lösung? Ich hab nun mittlerweile alles hier im Thread
an Funktionskombinationen gefundene ausprobiert, aber ohne Erfolg.
Nicht mal die "fehlerhafte" Variante von "Thomas" (
Beitrag "Re: Universelle Tastenabfrage" ), die ja eigentlich
das richtige tun sollte, geht nicht -> sie funktioniert bei mir gar
nicht.

Nochmal zusammengefasst muss ich auf einer Taste folgendes detektieren.
1) Taste kurz gedrückt -> ok
2) Taste lang gedrückt -> ok
3) Taste losgelassen nach lang gedrückt -> geht nicht

Alternative wäre noch einfach das loslassen (egal ob nach kurz oder
lang) der Taste detektieren zu können, dann könnte ich immernoch anhand
interner Variablen die Aktion korrekt auswählen.

Ich wäre dankbar, wenn's doch noch eine Möglichkeit gibt, das mit Pedas
Standardfunktionen umzusetzen.

Gruß
Fabian

Nein eigentlich gibts nur zwei Funktionen für den Nutzer pro Taste: kurz
gedrückt und lang gedrückt.
Es wird ein externes Gerät angesteuert (CD-Player). Auf einer Taste soll
nun bei kurzem Druck Skip und bei langem Druck Spulen liegen. Soweit so
einfach.
Es ist aber so, dass ich beim Spulen nicht immer wieder "spulen" schicke
sondern nur einmal "fang an zu spulen" sobald ein langer Druck erkannt
wurde und ein "spiel wieder normal" wenn dann wieder losgelassen wird.
Hoffe das ist verständlich.

Ich habe es jetzt aber über eine "illegale Funktionskombination" gelöst:
get_key_short und get_key_rpt.

Hier muss ich mir nur über eine interne Variable merken ob ich spule
(damit beim repeat nicht immer wieder das Kommando gesendet wird. Da
get_key_rpt den Key nicht zurücksetzt wird beim loslassen direkt nochmal
get_key_short ausgelöst. Hier kann ich nun ebenfalls über die interne
Variable erkennen ob ich skippen soll oder das Spulen beende.

Schöner wäre natürlich eine eigene Funktion
"get_key_release_after_long_press" und dann die Nutzung von
get_key_short und get_key_long. Aber ich habe dafür keine Möglichkeit
sehen können.

Gruß
Fabian

Hallo Leute,

erstmal vielen Dank an Peter für den erstklassigen Code!

Um mir und hoffentlich noch anderen die Entscheidung zu erleichtern
welche Kombination von Abfragen die geeignete ist, habe ich
mal ein paar Grafiken gemacht, welche die verschiedenen Funktionsweisen
veranschaulichen. Im Grunde sind es 3 Modi, die man verwenden kann. Die
Grafiken stellen den Ablauf einer Folge von 3 Tastendrücken dar. Ein
kurzer, ein langer und wieder ein Kurzer. In der ersten Grafik sind auch
die Zeitintervalle REPEAT_START und REPEAT_NEXT gekennzeichnet.

Anmerkungen:
- keystate ist bei gedrückter Taste oben, ansonsten unten.
- "X" bedeutet ein Tastenereignis wurde erkannt (die entsprechende
Funktion liefert != 0).
- Der aufmerksame Beobachter wird feststellen, dass eine Funktion
gelistet ist, die nicht existiert. Nämlich 'key_release'.
Die lässt sich mit ein paar Handgriffen in den Code von Peter einbauen.
Wie das geht zeige ich in seperatem Post.


Modus 1 ('get_key_press' mit 'get_key_rpt')
===========================================

           Zeitachse ---->
                 __      _________________      __
keystate    ____/  \____/                 \____/  \____
key_press   ----X-------X----------------------X-------
key_rpt     --------------------X--X--X--X-------------
key_release -------X----------------------X-------X----
                        |       |  |  |
                        |       |__|__|
                        |       | \ /
                        |_______|  REPEAT_NEXT
                              \
                               REPEAT_START

Modus 2 ('get_key_short' mit 'get_key_long')
============================================

                 __      _________________      __
keystate    ____/  \____/                 \____/  \____
key_short   -------X------------------------------X----
key_long    --------------------X----------------------
key_release -------X----------------------X-------X----

Modus 3 ('get_key_short' mit 'get_key_long_r' und 'get_key_rpt_l')
==================================================================

                 __      _________________      __
keystate    ____/  \____/                 \____/  \____
key_short   -------X------------------------------X----
key_long_r  --------------------X----------------------
key_rpt_l   -----------------------X--X--X-------------
key_release -------X----------------------X-------X----

Wichtig zu wissen ist vielleicht noch, dass 'get_key_long_r' und
'get_key_rpt_l' immer zusammen abgefragt werden müssen,
auch wenn für ein Fall keine Verwendung ist. Für sich alleine liefern
die Funktionen keine brauchbaren Ergebnisse (auch nicht zusammen mit
'get_key_short').

'get_key_release' kann man in allen Modi verwenden.

Grüße
Jonas

Wie angekündigt hier die 'get_key_release' Funktion. Drei Schritte sind
nötig.


1. Zu den globalen Variablen den release buffer hinzufügen:


Nach der Zeile

volatile uint8_t key_press;   // key press detect

folgendes einfügen:

volatile uint8_t key_release; // key release detect

2. In der ISR den buffer aktualisieren:


Nach der Zeile

key_press |= key_state & i;    // 0->1: key press detect

diese Zeile einfügen:

key_release |= ~key_state & i; // 1->0: key release detect

3. Und zu guter Letzt die Funktion um den release abzufragen:


Bei den anderen Funktionen einfügen:

uint8_t get_key_release( uint8_t key_mask )
{
  cli();                     // read and clear atomic !
  key_mask &= key_release;   // read key(s)
  key_release ^= key_mask;   // clear key(s)
  sei();
  return key_mask;
}

Gruß
Jonas

Christian schrieb:
> Wenn der Timer0 schon durch PWM belegt ist, kann man dann einfach einen
> der beiden anderen nehmen oder gibt es einen besonderen Grund für die
> Verwendung des "Nullers"?

Wie kommst Du denn darauf, daß es nicht ginge?

Du brauchst ein Zeitintervall von etwa 5..50ms.


Peter

Moin Moin!
Ich möchte die get_key_common() Funktion nutzen um durch langes drücken
zweier Tasten in den "Programmier-mode" zu gelangen.
Die Funktion reagiert aber auch schon auf kurzen Tastendruck. Wie kann
ich die Funktion erweitern/verändern, sodaß nur auf langes drücken
zweier Tasten reagiert wird?

10000000 * 10^12 Dank für eure Hilfe

Karsten

Hallo an alle,

Ich habe den Code (Orginal Peter) an einen ATmega 8515 angepasst die
KEY's liegen auf dem DDRC, die LED's auf dem DDRA
Die Funktion ist bei diesem µC auch gegeben.
KEY0 keine Funktion; KEY1 kurz/lang die Aktivierung von LED0/1;
KEY2 bei Betätigung laufen die LED's 2....7 je nach Takt und prescaler.

Nun hab ich den 8515 gegen einen ATmega 16 getauscht, weil ich einen
weiteren TIMER benötige, die alle nötigen Bekanntmachungen in AVRStudio
auf "ATmega16" geändert.
Die KEY's 0 und 1 sind in ihrer FUnktion erhalten geblieben
nur die LED2 leuchtet nun sofort und das Lauflicht beginnt, nach einer
noch nicht quantifizierten Zeit, von selbst. Das Betätien der KEY2 Taste
hat keinen Einfluss auf die Funktion der LED's.

Laut Datenblatt unterscheiden sich die relevanten Register(TIMER0) des
ATmega16 bzw. 8515 "überhaupt" nicht. Ausnahme die Adresse des OCR0
dieses sollte meine ich in der <avr/io.h> definiert sein.

Hää? ich bin für jeden Tipp dankbar.(Schlauch)

Martin Sv schrieb:
> Nun hab ich den 8515 gegen einen ATmega 16 getauscht

Nur wer eine Frage formulieren kann, kann sie sich ach selbst
beantworten

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

Einige Prozessoren haben eine Werkseinstellung, die zu Problemen führen
kann. Wenn der Prozessor JTAG unterstützt (ab Mega16 aufwärts), so ist
ab Werk die JTAG Schnittstelle eingeschaltet, was dazu führt, daß einige
Portpins nicht wie gewohnt funktionieren (nämlich die an denen das JTAG
Interface herausgeführt wird). In so einem Fall ist es das Beste, die
entsprechende Fuse JTAGEN umzusetzen, um so das JTAG Interface
abzuschalten, wenn es nicht gebraucht wird.

das war's, einen großen Dank dem Autor des o.g.Artikel

Hallo Peter,

auch von mir ein Dankeschön für das Veröffentlichen dieses hilfreichen
Codes.
Nach über 20 Jahren Pause hat mich wieder das "Mikrocomputer-Fieber"
erfasst, damals hatte ich, allerdings nur oberflächlich, den Z80 auf
HEX-Ebene gelangweilt, hat aber Spaß gemacht. Viele Funktionalitäten, so
auch die Entprellung, erfolgten in HW (RS-FF).
Nun versuche ich, dem Controller (Mega8) mit C "Beine zu machen".
C ist für mich völliges Neuland, insofern sind funktionierende Module,
wie auch diese Entprellroutine, wichtig für die ersten kleinen
Erfolgserlebnisse.

Viele Grüße
Thomas

Hans Peter L. schrieb:
> i = key_state ^ KEY_PIN;      // key changed ?
>   //aktvie high, desswegen Änderung ~KEY_PIN!

Und wie groß ist der Pulldown?


Peter

Hans Peter L. schrieb:
> Das wird über/* Push-pull with weak pull-up, Strom auf 2mA eingestellt.*/
> GPIOPadConfigSet(GPIO_PORTE_BASE, GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2,
GPIO_STRENGTH_2MA,GPIO_PIN_TYPE_STD_WPU);
> festgelegt.

Aha, "weak pull-up" bedeutet also Pull-down?


Peter

Hallo Steffi,

hier hatte ich mal eine Beispielprogramm geschrieben:

Beitrag "Re: 3fach Timer (einschaltverzögerung)"

Wenn Du dir bitte mal die Module in den Verzeichnissen timer und tools
ansiehst, wird es bestimmt klarer..

Hallo,

was ist das Problem ?

Ich denke bevor man nicht den gesamten CODE versteht, sollte man
versuchen Stück für Stück dem Verständnis näher zu kommen und immer nur
kleine Änderungen an Programmen machen.
Nur so lerne ich etwas..

Also nun ran an den Speck.

uint8_t get_key_release( uint8_t key_mask );

wurde irgendwann mal im Thread diskutiert und veröffentlicht.

Beitrag "Re: Universelle Tastenabfrage"

Als Ergänzung noch dieser Link:
Beitrag "Re: Universelle Tastenabfrage"


Noch eine Tipp zum Programm:

Beitrag "Re: Universelle Tastenabfrage"

#define ALL_KEYS        (1<<KEY0)

Es wird auch nur ein Bit als Eingang definiert !

Peter und andere lesen auch hier mit, also hänge doch deine komplettes
Programm bitte hier an !

Dann sehen wir alle schneller wo es hängt.

Hallo Steffi,

schon mal das Programm übersetzt und wenn ja, was sind die
Fehlermeldungen ?

Wie Arbeitest Du mit dem avr-gcc - ich meine mit welcher Umgebung ?

Ich verwende klassisch nur ein Makefile, make in einer bash-shell.

Steffi schrieb:

> Konntest du irgendwelche Ungereimtheiten im C-Code finden?

Dein C-Code sieht recht ordentlich aus.
Natürlich ist er umfangreicher, als nötig, aber sicher ist sicher :)

Für deine Taster benutzt du PINC1 und PINC2, aber nur der PINC1
"funktioniert".

Versuch doch einfach mal einen anderen PIN zu nehmen anstatt PINC2.
Vielleicht hilft es ja...

Gruß Helmut

Hallo,

schau dir bitte die angepassten Routinen von PeDa in diesem Beitrag an:

Beitrag "Re: 3fach Timer (einschaltverzögerung)"

http://www.mikrocontroller.net/attachment/107805/c...


Was dir sofort auffallen sollte beiden Dateien unter tools:

volatile uint8_t key_state;

Es wurden also noch einige wichtige Änderungen hier im Thread gemacht,
die dann eingeflossen sind.

Also lese bitte alles von Oben nach.

Moin alle zusammen! Erstmal frohe Weihnachten :)

Ich versuche gerade zu verstehen, wie die Methode get_key_long()
funktoniert.
Ich bin mir nicht sicher, ob dies hier schon einmal erklärt worden ist.
Ich habe mich bemüht den ganzen Thread durchzugucken, habe aber nichts
gefunden.

So, nun zur eigentlichen Frage. Zuerst wird ja get_key_rpt() aufgerufen
und das wird nur eins, wenn die Taste min. 500ms gedrückt wurde. Dann
kommt die Methode get_key_press() ins Spiel. Wenn die Taste noch nicht
500ms gedrückt wurde, wird ihr ja die ganze Zeit als Parameter 0x00
übergeben und es kommt immer 0x00 zurück. Nach 500ms wird ihr dann eben
die 1 an der jeweiligen Position übergeben. Aber nach 500ms wurde das
Bit in key_press doch schon längst gelöscht, weil das ja sofort beim
Timeroverflow nach dem setzen wieder gelöscht wird. Also müsste
get_key_press() dann doch immer eine 0 liefern?
Aber sie gibt ja eine 1 zurück, warum funktiniert das?

Danke schon mal und noch ein fröhliches Weihnachtsfest.

Gruß
Pascal

Tilman schrieb:
> Heyho,
>
> für active high muss noch eine zweite Zeile geändert werden, sonst
> liefert get_key_rpt und damit auch get_key_long für jede nicht gedrückte
> Taste das Signal, dass sie gedrückt sei.
>
> Änderekey_rpt |= key_state & REPEAT_MASK;
> inkey_rpt = ~key_rpt & ~(key_state & REPEAT_MASK);
> oder (vielleicht einfacher zu erkennen, was gemacht wurde)key_rpt = ~(key_rpt |
(key_state & REPEAT_MASK));
>
> Diese Zeilen invertieren einfach key_rpt.
>
> Tschau,
> Procyon


Servus

Verwende Hr Danneggers Code nun schon eine Weile und bin äußerst
zufrieden damit. Hab ihn nun auch das erste mal mit active high Tastern
in Verbindung und mir hierzu die Foreneinträge angesehen.

Meiner Meinung nach muss für active high Schalter lediglich das KEY_PIN
Makro invertiert werden (siehe
Beitrag "Re: Universelle Tastenabfrage"), der Rest bleibt
exakt gleich! Schließlich wird ja der Port auch nur an dieser Stelle
"eingelesen". Die restliche Logik ändert sich ja nicht.

Da ich eine faule Natur bin und die Logik nur kurz überflogen hab, hab
ich das ganze einem Praxistest unterzogen und tatsächlich, key_rpt
funktioniert in der Standardversion einwandfrei.

Kein Grund also, key_rpt in der ISR umzuschreiben? (geschweige denn die
long_... Funktion.


lg
Vincent


ps: Ich ändere den Artikel erst, sofern dies jemand bestätigt hat, da
ich Teile des Codes stark modifiziert hab. (mehrere Ports, Pins
verschiedener Ports, usw.) Ev. lieg ich ja doch falsch.