Tasten Auswertung

roman65536 schrieb:
> Nein nein nein... keine neue Tasten Entprellung...

Hast recht, das Entprellen, also das Wichtigste, macht sie gerade nicht.
Warum?


> man hat ein Uc und ein paar tasten angeschlossen und nun moechte man
> heraus finden ist taste xy gedruckt oder nicht.  Oder wurde diese gerade
> erst gedruckt oder gerade erst losgelassen. Oder ... Man haelt diese
> schon seit laengerem gedruckt..

Jau, dat gibbed allet schon längst, schau Dir mal meine Entprellfunktion 
für 8 Tasten an.
Die hat sogar ne Repeatfunktion und merkt sich den Druck, auch wenn 
schon wieder losgelassen wurde.
Sie benötigt auch deutlich weniger Code, SRAM und CPU-Zeit.


> RELEASED wenn die Taste seit letzte abfrage Losgelassen wurde
...
> PRESSED wenn die Taste gedruckt wurde
> PRESS_LONG wenn die Taste seit laengerem (Definition von laenge siehe
> source code) gedruckt wurde

Deine Abfrage switches_status() liest doch nur den Status und setzt 
nichts zurück. Also wie sollen dann genau nur einmal die Flags gesetzt 
sein?

In meiner Routine erfolgt das Abtasten und das Auswerten dagegen völlig 
unabhängig. Das Main kann die Ereignisflags auswerten und rücksetzen, 
wann es Zeit hat und ist nicht an einen festen Zyklus gebunden.


Peter

roman65536 schrieb:
> Nur was soll man mit einer AVR Assembler routine auf einem Coldfire oder
> ARM ??

Hä?
Das ist doch C.

Beitrag "Universelle Tastenabfrage"

Und ein ARM ist bestimmt auch nicht unglücklich, wenn er weniger 
CPU-Zeit benötigt.
Je nach Portbreite ist dann die Routine natürlich für minimal 16 oder 32 
Inputs.
Das Vertical Counter Prinzip bearbeitet immer alle 8/16/32Bits parallel 
und nicht in einer Loop.


> "..merkt sich den Druck, auch wenn
> schon wieder losgelassen wurde." Weiss nicht was du meinst.

Der Timerinterrupt läuft immer, z.B. alle 10ms und tastet ab.
Die Mainloop ist z.B. für eine Sekunde mit was anderem beschäftigt. Dann 
ruft sie get_key_press() auf und bekommt das Ereignis. Die Taste kann 
derweil schon 0,5s losgelassen worden sein.
Der Trick ist, daß erst get_key_press() das Flag liest und löscht. Jeder 
Tastendruck bewirkt dadurch auch nur genau ein Ereignis. Egal, wann und 
wie oft get_key_press() aufgerufen wird.


Peter

Da muß ich Peter zustimmen: die Bulletproof-Geschichte läuft problemlos 
auch auf einem STM32 (Cortex-M3) und auf einem ARM9 (unter WinCE6) - 
reines C, ohne Spezialitäten, man muß nur die aktuelle Belegung der 
Tasteneingänge abfragen...

Ahoi, Martin

Martin Schneider schrieb:
> Da muß ich Peter zustimmen: die Bulletproof-Geschichte läuft problemlos
> auch auf einem STM32 (Cortex-M3) und auf einem ARM9 (unter WinCE6)

Ebenfalls auf einem TMS320F2812.

Wenn ich Deinen Code richtig verstehe, funktioniert er nur dann, wenn 
switches_update() und switches_status() immer genau im Wechsel 
aufgerufen werden. Erfolgt das zu langsam, können Ereignisse verloren 
gehen.

Deshalb war es mir wichtig, das Abtasten und das Auswerten voneinander 
zu entkoppeln.
Es nervt nämlich tierisch bei vielen kommerziellen Geräten, wenn 
Tastendrücke verloren gehen.


Peter

roman65536 schrieb:
> Peter,
>
>
> Ja das ist so..
> Bei meiner Applikation wollte ich eigentlich auf das PRESSED losgehen..
> dh. mich interessierte eigentlich nicht ob die Taste gedruckt ist (zu
> dem zeitpunkt). Es sollte ein Taste gedrueck werden (was ein Status
> PRESSED|PRESS zurueck gibt) um in ein Menue zu gelangen. Danach muss die
> Taste wieder losgelassen werden und wieder gedruckt werden um weiter im
> Menue etwas zu selektierien etc.

Genau für den Fall sind die PeDa Routinen besser geeignet.
Deine Funktionen könnte ich mir bei einem Joystick vorstellen, obwohl 
ich mir nicht sicher bin, ob da nicht direkte Pin Abfrage einfacher 
wäre.

> Bei mir laufft das ganze ohne Interrupts, den es je ein grosse loop. die
> delta Erkennung koennte ich verbessern resp. aus dem loop rausnehmen,
> jedoch die 5 verschiedene status muss ich per loop tun.

Man kann deine Funktionen auch aus einem Interrupt heraus aufrufen. So 
ist das ja auch wieder nicht. Genauso wie man die PeDa Routinen aus der 
ISR isolieren, in eine Funktion packen und aus der Hauptschleife heraus 
aufrufen könnte.

Aber die fehlende Entprellung wäre für die meisten hier ein 
KO-Kriterium.

Die PeDa Routinen haben den Charme, dass
* sie kurz sind
* so gut wie keine Rechenzeit verbrauchen
* irgendein regelmässiger Interrupt, den man mitbenutzen kann in
  praktisch jedem Programm rumlungert
* sobald die ISR aktiv ist, sich keine Gedanken mehr um verlorene
  Tastendrücke machen braucht. Selbst wenn das Programm kurzfristig
  etwas mehr zu tun hat, gehen selbst kurze Tastendrücke nicht verloren.
* sie auch mit den grindigsten Tasten, deren Kontakte ausgeleiert sind,
  klar kommen.
* sie schnell in ein Projekt übernommen, eingebaut und angepasst werden
  können.

Es ist schwer, diese Funktionalität zu toppen. Egal in welcher Richtung. 
In Punkte Codeverbrauch, Resourcenverbrauch, Komfort (sowohl für den 
Anwender als auch für den Programmierer) sind sie so ziemlich das 
Optimium dessen, was man kriegen kann.

Da hier schon einige den Code kennen und davon begeistert sind, mag der 
Eindruck entstehen, daß nun alle auf Dich eindreschen. Das ist aber 
bestimmt nicht so gemeint.

Letztendlich wichtig ist, daß eine Lösung zuverlässig arbeitet.
Und schön ist dann, wenn sie mit möglichst wenig Seiteneffekten und 
Ressourcen in andere Projekte einfügbar ist.

Meine Projekte sind wohl etwas kleiner als Deine, daher kein extra 
Tastenkontroller und das Entprellen muß mit drin sein.


Peter

roman65536 schrieb:

> Genau um das ging es auch bei mir ja .. eine Art Joystick,
> mit dem ich dann nur noch feststellen wollte ging es rauf/runter oder
> ins menue rein.

OK.
Das ist dann im Eröffnungsposting nicht so recht reübergekommen.

> Irgendwie, kommt es mir vor als nur "privilegierte" leute hier code rein
> stellen koennen... ich zwinge doch niemanden...

Sorry, wenn dieser Eindruck entsteht.
Das wir sicherlich nicht so gemeint.

Das Thema Tastenentprellunf und Auswertung (diesmal mit echten 
Digi-Tastern) ist eines, welches oft genug um restlichen Forum 
auftaucht. Und oft sehen wir dort völlig untaugliche Entprellfunktionen, 
die der Frager nur deswegen eingebaut hat, weil er sie 'irgendwo' 
gefunden hat.
Ich denke, es ist auch in der Codesammlung wichtig abzugrenzen, wo ein 
Code eingebaut werden kann und wo nicht. Wo er Sinn macht und wo nicht. 
Wo es bessere Lösungen gibt und wo nicht.

> BTW: Peter du hast mich auf eine idee gebracht wie ich den loop los
> werden kann. hmmm... cool...

Dann hat es sich schon ausgezahlt :-)