Du dachtest ich nutze die Funktion für alle Taster?
Du vielleicht nicht, aber ich oder andere, wenn ich die Funktion sehe und realisiere, dass ich die Pin-Nummer als Parameter mitgebe.
Das ist prinzipiell der Sinn einer Funktion, dass man sie auch mehrfach aufrufen kann.
Und wenn man dann noch parametrieren kann, für welchen Taster sie gerade da sein soll, lädt sie gerade dazu ein...
Damit bekommt jeder Taster seine eigene Instanz
Ja, das wäre eine Möglichkeit.
Oder eben zentral alle Taster-Pins im passenden Zyklus auf Zustandsvariable übertragen, wie es schon vorgeschlagen wurde.
Wie die Sache an welche Grenzen kommt, wenn man sie mit einer Zykluszeit von z.B. 500ms verwendet, kann man natürlich ausprobieren oder sich auch einfach so überlegen:
michael_x:
Die Zeiten für Prellen, Taster einlesen, und die vorgesehene Taster-Betätigungszeit sollten sich deutlich unterscheiden.
Das Stellwerk enthält 47 Einfache Taster und Schalter, 9 Drehschalter mit jeweils 7 Positionen und eine Tastatur mit 54 Tasten. Insgesamt also über 150 mechanische Eingabeelemente, die entprellt werden wollen.
Die Tastatur und die übrigen Taster und Schalter sind jeweils in einer Matrix verschaltet, die über I2C Portextender eingelesen werden. Am Controller sind dazu also nur 2 Pins notwendig.
Alle Elemente werden am Anfang der Verarbeitungsschleife mit einer Intervallzeit von ca. 50ms eingelesen und in Statusvariablen abgelegt. Das entprellt absolut zuverlässig und ist schnell genug, dass auch auf der Tastatur noch einigermaßen flott geschrieben werden kann.
Schon der gesunde Menschenverstand sagt, dass hier eine Intervallzeit von 500ms nicht funktionieren kann. Das hat nichts mit 'Extremtesten' zu tun, sondern ist einfach sinnfrei.
Ich denke dass deine 'Entprellklasse' hier schnell an ihre Grenzen käme, während die Intervallabfrage problemlos funktioniert.
auf das "testen" möchte ich nochmal hinweisen. Es ist absolut notwendig. An für unnötig gehaltene Tests oder anderen Fehleinschätzungen sind schon ganze Weltraummissionen gescheitert inkl. Todesfolge. Hier im Forum sind es meistens falsche Datentypen. Andere Parameter und die Funktion verhält sich plötzlich anders und ähnliches. Seinen Code zu testen gehört nun einmal dazu und beansprucht mehr Zeit wie die eigentliche Programmierung.
Ich wiederhole mich auch gern nochmal. Für "Taster als Taster" Abfragen ist es okay. Bei anderem Verwendungszweck hatte ich eben Probleme festgestellt. Nicht mehr und nicht weniger. Mehr wollte ich gar nicht mitteilen.
hier sind einfach verschiedene Herangehensweisen aus verschiedenen Blickwinkeln für verschiedene Zwecke aufeinander geprallt. So würde ich das formulieren wollen. Leider wurde auf mein gezeigtes Problem für den Zweck "Taster als Schalter" nicht eingegangen. Daraus entwickelte sich leider eine verzwickte Diskussion. Alles hat seine Berechtigung und alles hat seine Grenzen. Ich denke wir belassen es dabei.
Doc_Arduino:
hier sind einfach verschiedene Herangehensweisen aus verschiedenen Blickwinkeln für verschiedene Zwecke aufeinander geprallt. ... Leider wurde auf mein gezeigtes Problem für den Zweck "Taster als Schalter" nicht eingegangen.
Ja, da ist wohl was dran. Ich sehe das Entprellen und die Funktion des Tasters / Schalters als 2 getrennte Schritte. Erst entprellen um in der Statusvariable ein möglichst gutes Abbild des Tasterzustandes zu haben - nur eben ohne Prellen. Das geht nur mit kurzen Abtastzeiten. Die Funktion des Tasters wird dann ausschließlich mit der Zustandsvariablen gebildet. Z.B. haben die grünen Taster unter der linken Anzeige in meinen Stellpult ganz verschiedene Funktionen - je nachdem in welchem Menü man sich gerade befindet. Da wird dann durchaus auch was aus- oder eingeschaltet. Aber das sind alles Dinge, die nach dem Entprellen und rein anhand des programminternen Tasterstatus ausgewertet werden.
Du hast in deinen Beispielen Entprellen und Tasterfunktion vermischt. Das kann man in einfachen, statischen Anwendungen machen. Wenn man mehr Flexibilität braucht, geht das nicht.
Meine Vorgehensweise ist grundsätzlich: erst entprellen, dann die Funktion. Die Intervallmethode ist nur für das Entprellen geeignet - da dann aber auch für wirklich viele Eingangselemente.
Durch diese verschiedene Herangehensweise enstanden wohl die Differenzen.
Klar, es gibt immer Sonderfälle, die getrennt betrachtet werden müssen. Wenn ich mir aber so ansehe, was hier mit dem Arduino gemacht wird, sind das deutlich weniger als 20% . Auch wenn man erst entprellt kann man ja ohne weiteres Reaktionszeiten unter 40ms erreichen. Wenn's schneller sein muss -> Sonderbehandlung.
Wobei ich entsprechend dem Threadtitel hier eher von manuellen Eingaben ausgegangen bin, und da dürfte der wirklich zeitkritische Anteil noch kleiner sein.
Aber sei's drum - jeder wie er mag.
Gib 10 Programmierern eine Aufgabe und Du bekommst mindestens 11 Lösungen 8)
Endschalter am Maschinentisch, da muss sofort gebremst werden.
Reaktionstestspiel
Wecken aus dem SleepMode
Zu 1: Hat mit dem Thema nichts zu tun. Ein Endschalter muß bei der ersten Unterbrechung den Zustand des Prozesses auf Stopp bringen und dort halten, auch wenn er danach wieder einschaltet, also überfahren wird. Entprellen ist da nicht angebracht.
Zu 2: Sonderfall, der wohl ohne Entprellen durch "weiter zum nächsten Status" gelöst werden kann.
Ich habe das bei mehreren Tastern/Eingängen erweitert..
Eine Abtast Intervallzeit für alle Eingänge zusammen als eine Art Auflösung welche schon entprellend wirken kann, eine einstellbare entprellzeit und eine aus den beiden Fällen resultierende zulässige minimalzeit die mindestens erreicht werden muss damit der Eingang erkannt wird..
So kann man sich das für jeden Fall anpassen.
P.s: aus der Praxis kann ich sagen das es viele sicherheitsrelevante Endschalter, Lichtschranken oder Sensoren gibt die selbst eine Latenz von weit über 20ms haben.. Da wird ja auch viel berechnet mit Annäherungs und maschinengeschwindigkeit..u.s.w
. Auch wenn man erst entprellt kann man ja ohne weiteres Reaktionszeiten unter 40ms erreichen. Wenn's schneller sein muss -> Sonderbehandlung.