Mehrere Taster/Schalter entprellen und verwalten

[MicroBahner]

Hallo,
es gibt ja eine ganze Reihe Libs, die sich mit dem Thema mechanische Schalter und dem Entprellen beschäftigen. Allerdings fokussieren die ( zumindest die ich kenne ) sich alle auf einen einzelnen Taster oder Schalter. Setzt man die dann mehrfach ein, verbrauchen sie ziemlich viel Ressourcen.
In dem Umfeld, in dem ich mich viel tummele ( der Modellbahnerei ) hat man es eher mit vielen Eingabeschaltern und Tastern zu tun. Da ist es dann häufig sinnvoll, Portexpander ( I2C ) oder/und eine Tastaturmatrix zu nutzen. Das wird von diesen Bibliotheken aber auch nicht unterstützt.
Aufgrund einer konkreten Anfrage habe ich mich deshalb mal daran gemacht, dafür eine möglichst allgemeingültige Lösung zu finden.
Ziele:

• beliebige Hw-Konfigurationen unterstützen ( direkter Anschluß, Portexpander, Matrix )
• Entprellen
• Flankenerkennung (Drücken/Loslassen)
• Langen / kurzen Tastendruck erkennen
  

Einen ersten Entwurf einer entsprechenden Lib ( MoToButtons ) habe ich auf GitHub gehostet. Um den ersten Punkt erfüllen zu können, wird die eigentliche Abfrage der HW über ein User Callback realisiert. Rückgabewert ist ein entsprechendes Bitmuster in einer 8,16 oder 32-Bit Variable ( je nach Einstellung in der Lib ). Damit können also in einer Instanz bis zu 32 Taster/Schalter verwaltet werden.

Die Doku ist noch etwas rudimentär ( Kommentare in der .h-Datei und ein Beispielsketch ), aber falls jemand Interesse hat, würde ich mich über Rückmeldungen freuen.

[RolandF]

(30.01.2020 17:08)MicroBahner schrieb:  Hallo,
es gibt ja eine ganze Reihe Libs, die sich mit dem Thema mechanische Schalter und dem Entprellen beschäftigen. Allerdings fokussieren die ( zumindest die ich kenne ) sich alle auf einen einzelnen Taster oder Schalter. Setzt man die dann mehrfach ein, verbrauchen sie ziemlich viel Ressourcen.
In dem Umfeld, in dem ich mich viel tummele ( der Modellbahnerei ) hat man es eher mit vielen Eingabeschaltern und Tastern zu tun. Da ist es dann häufig sinnvoll, Portexpander ( I2C ) oder/und eine Tastaturmatrix zu nutzen. Das wird von diesen Bibliotheken aber auch nicht unterstützt.
Aufgrund einer konkreten Anfrage habe ich mich deshalb mal daran gemacht, dafür eine möglichst allgemeingültige Lösung zu finden.
Ziele:

• beliebige Hw-Konfigurationen unterstützen ( direkter Anschluß, Portexpander, Matrix )
• Entprellen
• Flankenerkennung (Drücken/Loslassen)
• Langen / kurzen Tastendruck erkennen
  

Einen ersten Entwurf einer entsprechenden Lib ( MoToButtons ) habe ich auf GitHub gehostet. Um den ersten Punkt erfüllen zu können, wird die eigentliche Abfrage der HW über ein User Callback realisiert. Rückgabewert ist ein entsprechendes Bitmuster in einer 8,16 oder 32-Bit Variable ( je nach Einstellung in der Lib ). Damit können also in einer Instanz bis zu 32 Taster/Schalter verwaltet werden.

Die Doku ist noch etwas rudimentär ( Kommentare in der .h-Datei und ein Beispielsketch ), aber falls jemand Interesse hat, würde ich mich über Rückmeldungen freuen.

Hallo Franz-Peter,
ich hatte gerade letztens für einen Bekannten ein kleines Projekt mit 8 Tastern umgesetzt, das hatte ich noch mit OneButton realisiert.
Nach meinem Urlaub (Skifahren)werde ich das noch mal mit Deiner Lib umsetzen.
Von Deiner Mobatools-Lib war ich ja schon mal begeistert, also gehe ich davon aus, dass das mit dieser Lib auchwieder so wird. Diesen Erfolgsdruck hast Du Dir also selbst zuzuschreiben
Grüße
Roland

[Tommy56]

@MicroBahner: Wie ist das zu verstehen?

processButtons() soll oft aufgerufen werden, aber nicht kürzer, als die Entprellzeit, sonst wird die pressTime falsch. Da geht es doch nach meiner Meinung um Verfälschungen < Entprellzeit?
Die dürften in der Praxis doch kaum ins Gewicht fallen, wenn es handbetätigte Buttons sind

Die hardcodierte Größe (8/16/32 Bit) könnte man evtl. durch ein template verallgemeinern, so dass man die gleiche Lib ohne Codeänderungen z.B. in Sketchen mit 8 und welchen mit 16 Bit benutzen kann.

Ansonsten wieder eine schöne Arbeit. Besonders die Idee mit dem Callback finde ich gut, damit kann man beliebige HW für die Buttons rein hängen.

Gruß Tommy

[MicroBahner]

(30.01.2020 20:56)RolandF schrieb:  ich hatte gerade letztens für einen Bekannten ein kleines Projekt mit 8 Tastern umgesetzt, das hatte ich noch mit OneButton realisiert.
Nach meinem Urlaub (Skifahren)werde ich das noch mal mit Deiner Lib umsetzen.

Da bin ich auf deine Erfahrungen gespannt. Bei 8 Tastern braucht die OneButton doch schon ganz ordentlich RAM. Mein Ansatz ist aber deutlich anders - da wirst Du dein Programm schon umschreiben müssen.

(30.01.2020 21:30)Tommy56 schrieb:  @MicroBahner: Wie ist das zu verstehen?
processButtons() soll oft aufgerufen werden, aber nicht kürzer, als die Entprellzeit, sonst wird die pressTime falsch. Da geht es doch nach meiner Meinung um Verfälschungen < Entprellzeit?

Das habe ich wohl nicht richtig bzw. missverständlich beschrieben. Das Problem tritt auf, wenn processButtons zu selten aufgerufen wird, also in Intervallen die größer als die Entprellzeit sind. Beliebig kürzer als die Entprellzeit ist kein Problem, und sollte der Normalfall sein. Derzeit wird die 'pressTime' intern in 'entprellzeit' Einheiten gezählt. Da komme ich mit einem Byte aus, was RAM spart ( den Zähler braucht man ja für jeden Taster ). Das könnte man aber sicher noch optimieren. Ist ja erst ein erster Ansatz.

(30.01.2020 21:30)Tommy56 schrieb:  Die hardcodierte Größe (8/16/32 Bit) könnte man evtl. durch ein template verallgemeinern, so dass man die gleiche Lib ohne Codeänderungen z.B. in Sketchen mit 8 und welchen mit 16 Bit benutzen kann.

Da habe ich auch schon dran gedacht, und es gibt auf GitHub auch schon einen Branch (Templates) dazu. Allerdings hat das auch so seine Tücken, da das ja zur Compilezeit aufgelöst wird. In eine eigen cpp kann man das dann nicht auslagern, da dort zur Compilezeit nicht bekannt ist, was der Sketch haben will. Ausserdem ist die Instanziierung dann etwas komplexer und für die Einsteiger sicher recht ungewöhnlich. Bei Klassen muss man den gewünschten Typ mit übergeben. Funktionstemplates sind da einfacher handhabbar. Da weis ich noch nicht, was letztendlich die beste Lösung ist. Ich habe auch noch nicht sehr viel Erfahrung mit Templates.

[Tommy56]

Dann schau Dir bitte nochmal die Beschreibung bezüglich des Aufrufs in der Headerdatei an.

Zitat:if its called less then debTime, pressTime will be inaccurate

sagt nach meinem Verständnis dann das Falsche aus.

Zum Template: Der Anwender weiß (oder sollte es wissen) zur Compilezeit, wieviele Taster er hat. Deshalb sollte eine Anlage

Code:

MaToButton<uint16_t>

zur Compilezeit machbar sein. Der User muss seine Buttons ja auch nutzen und dazu muss er die Menge vorher kennen.
Es geht ja nicht um eine dynamische Anlage zur Laufzeit. Ja, Templates müssen in den Header.

Gruß Tommy

[MicroBahner]

(30.01.2020 22:46)Tommy56 schrieb:  Dann schau Dir bitte nochmal die Beschreibung bezüglich des Aufrufs in der Headerdatei an.

Zitat:if its called less then debTime, pressTime will be inaccurate

sagt nach meinem Verständnis dann das Falsche aus.

Ja, das ist zumindest missverständlich. Deutlicher ist:

Zitat:if its called less frequently than debTime, pressTime will be inaccurate

So habe ich das jetzt geändert.

(30.01.2020 22:46)Tommy56 schrieb:  Zum Template: Der Anwender weiß (oder sollte es wissen) zur Compilezeit, wieviele Taster er hat. Deshalb sollte eine Anlage
Code:
MaToButton<uint16_t>
zur Compilezeit machbar sein.

Ja, das funktioniert natürlich. Im Branch Templates ist das in dem Beispiel ja auch so gemacht und es läuft. Allerdings gehören templates sicher nicht zum Standardwissen des durchschnittlichen Arduino-Nutzers, und dementsprechend ist diese Syntax da erstmal neu und verwirrend.
Allerdings: Wenn eh der ganz Code ins .h-File muss, könnte man das auch mit einem optionalen #define vor dem #include lösen. Standardmässig wird z.B. 16Bit genutzt, und mit dem #define könnte man den Standard überschreiben. Das dürfte für die Meisten einfacher sein.

So wie jetzt, mit der Anpassung direkt im .h-File, ist jedenfalls nicht optimal .

[Tommy56]

(31.01.2020 09:10)MicroBahner schrieb:  Allerdings: Wenn eh der ganz Code ins .h-File muss, könnte man das auch mit einem optionalen #define vor dem #include lösen. Standardmässig wird z.B. 16Bit genutzt, und mit dem #define könnte man den Standard überschreiben. Das dürfte für die Meisten einfacher sein.

Das wäre auch eine sehr gute Lösung, die die allgemeine Verwendbarkeit erhält.

Gruß Tommy

[MicroBahner]

Ja, eigentlich gefällt mir das auch am Besten, weshalb ich den 'master' Branch auf GitHub jetzt mal darauf umgestellt habe.