Arduino - Tastendruck merken und später auswerten

macst du halt statt
einem delay(10000)
100 delay(100)
da hast du Tastenentprellung gleich mit dabei

3nibble schrieb:
> in einer Dauerschleife werte ich ein paar Sensoren aus und lasse die
> Ergebnisse im 10-Sekunden-Takt (delay(10000)) auf einem kleinen OLED
> anzeigen bzw. aktualisieren.

Dir ist schon klar, dass die Sensoren dann auch nur im 10s-Takt 
abgefragt werden?

Verwende entweder die Funktion millis() zur Abfrage des Arduino Timers 
oder wenigstens ein kürzeres delay() zusammen mit einem Zähler. Für eine 
Tastenabfrage alle 20ms könnte man die Abfrage/Ausgabe bei nur jedem 
500-sten Schleifendurchlauf aufrufen.

Es braucht weder Interrupt, noch muss man auf das delay() verzichten.
Die Taste kann man auch in yield() lesen und nach Abschluss des delay() 
das gemerkte dann auswerten.

du brauche 2 Variablen für das Problem.

alte_millis (bei mir genannt). LED_status

Do machst eine do while Schleife in der du die Millis abfragst 
permanent.

etwa so

alte_millis = 0
do
if millis >= alte_millis + Zeit_wert then
   alt_millis = millis
   frage_sensoren_ab
end if

if taster_gedruckt = true then
   if led_status = true then
      led_status = false
      mach_led_aus
   else
      led_status = true
      mach_led_an
   end if
end if

If Millis < alte_millis then alte_millis = 0 ' fängt den Millis überlauf 
an

loop


Das ist alles !!


Mache ich übrigens genau SO bei einer meiner Projekte um die 
Hintergrundbeleuchtung der 2004 abzuschalten.

Für die Freaks hier. Die Routine habe ich unter Arduino-C auch gemacht, 
das ist aber B4X-Code. Den der Arduino auch frisst mit den richtigen 
Compiler.

Lothar M. schrieb:
> Wenn ich in einem Programm ein delay() sehe, dann ist das ein
> Warnsignal. Wenn hinter dem delay() eine Zahl größer als 1 ms steht,
> dann ist es ein Fehler.
+1
Timer IRQ mit einer sinnvollen Zeiteinstellung IRQs erzeugen zu lassen.
Sinnvoll = kleinste benötigte Zeiteinheit, aber nicht kleiner.
Bei Tastendrücken reichen sicherlich auch längere Zeiträume, wenn man 
nicht gerade das Reaktionsvermögen einer Stubenfliege hat.

Stumpfes hochzählen der verschiedenen Zeitvariablen in der IRQ und ich 
weiß global ob meine Zeit X abgelaufen ist, arbeite dann ab und setze 
zurück.
So kann ich beliebig viele verschiedene Zeiten checken, brauche nicht 
ein delay() dazu und blockiere die MCU nie.

Wenn möglich lege ich die MCU am Ende der Main schlafen und lasse die 
durch den IRQ wecken.
Was soll die sich wild im Kreis drehen wenn die Aufgaben erledigt sind 
und alles weitere bis zum nächsten IRQ Zeit hat?

Ben K. schrieb:
> Delay, dass GOTO des Arduinos... 😝
Schlimmer.
Goto macht es nur unleserlich. Delay blockiert jede weitere Aktion mit 
Vollgas + Bremse.

Max M. schrieb:
> Delay blockiert jede weitere Aktion mit
> Vollgas + Bremse.

Herzerfrischend kenntnisfrei.

1

bool merker;

2

constexpr byte tasterPin {2};

3

4

void yield()

5

{

6

  if(not digitalRead(tasterPin)) merker = true;

7

}

8

9

void setup() 

10

{

11

  Serial.begin(9600);

12

  pinMode(tasterPin,INPUT_PULLUP);

13

}

14

15

void loop() 

16

{

17

  delay(10000);

18

  if(merker)

19

  {

20

    Serial.println("Aktion!");

21

    merker = false;

22

  }

23

}

Aabeku K. schrieb:
> sicherlich völlig in Ordnung.
Ganz offensichtlich ja nicht, wenn man während der 10sek gerne einen 
Tastendruck erkannt hätte statt sich nur hektisch im kreis zu drehen und 
rein garnichts mehr mitzubekommmen.

Auch die lausige Programmierung mit zusätzlicher Hardware erschlagen zu 
wollen ist leider völlig nutzlos, da die MCU auch dann erst nach 10sek 
mitbekommt das eine Taste gedrückt wurde.

Der TO muss das Wesen der Delay Routine verstehen, warum die Schrott ist 
und man das anders löst.

Schlaumaier schrieb:
> if millis >= alte_millis + Zeit_wert then

Böse Falle :-(

Was meinst du wohl, was passiert, wenn alte_millis + Zeit_wert einen 
Überlauf produziert.

... und ganz übel wird's, wenn millis() überläuft.

Delay ist nur wichtig wenn man auf Externe Hardware warten muss.

Einige Teile brauchen halt ihre Zeit bis sie Befehle abgearbeitet haben. 
Also wartet der MC halt, an genau DER Stelle.

Ansonsten benutze ich immer die oben genannte Schleife. Besonders wenn 
in der Zeit noch was anders passieren kann/soll.

Wolfgang schrieb:
> und ganz übel wird's

Das ist doch dem Schlaumaier ganz egal......

Wolfgang schrieb:
> ... und ganz übel wird's, wenn millis() überläuft.

Lesen und verstehen ist eine schwere Sache.

Schlaumaier schrieb:
> If Millis < alte_millis then alte_millis = 0 ' fängt den Millis überlauf
> an


Und schon ist das übel aus der Welt.

Millis fängt nach den Überlauf wieder bei 0 an.
Alte_millis sind aber bei X-Mio.
Ergo werden in der Zeile alte_millis auf 0 gesetzt.
Beim nächsten Lauf ist millis wieder größer alte_Millis und schon läuft 
es wieder rund.


Unter speziellen Anwendungen kann das vielleicht Problematisch werden. 
Aber nicht bei einer Sensorabfrage die dann vielleicht mal ein paar 
Takte später erfolgt.

Schlaumaier schrieb:
> Schlaumaier schrieb:
>> If Millis < alte_millis then alte_millis = 0 ' fängt den Millis überlauf
>> an
>
> Und schon ist das übel aus der Welt.

Warum sollte man sowas tun?
Denn das ist nicht exakt und damit fehlerhaft.
Zudem kann man das auch fehlerfrei, mit weniger Aufwand, hinbekommen.
Damit gib es keinen Grund die Krücke zu verwenden!

1

using Millis = decltype(millis());

2

3

Millis zeitMerker;

4

constexpr Millis interval {1000}; //ms

5

6

void setup() 

7

{

8

}

9

10

void loop() 

11

{

12

  if(millis()-zeitMerker>=interval)

13

  {

14

    zeitMerker += interval;

15

    // hier tuwas()

16

  }

17

}

EAF schrieb:
> Warum sollte man sowas tun?

Weil viele Wege nach Rom führen. Und ich nie behauptet habe das meine 
Routinen die besten sind.

Ich behaupte nur sie funktionieren. ;)

Zugegeben : Deine ist besser + kürzer.

Werde sie mir also merken für das nächste Projekt. ;)

DANKE

Obwohl deine auch ein Fehler hat.

Nach den Überlauf ist millis 0

Was dann übersetet bedeutet :

 if(millis()-zeitMerker>=interval)

if (0 - 1000) >= 1000  then

Also hast du auch min. 1 eher 2-3 Zeitsprung-Fehler beim Überlauf.

3nibble schrieb:
> Ich müsste also erreichen, dass der Tastendruck
> einen D-Pin dauerhaft setzt

Nein, der richtige Ansatz ist, dein Programm nicht anzuhalten. Schau dir 
die Erklärungen zum "Blink without delay" Beispiel an, da wird das 
thematisiert.

Schlaumaier schrieb:
> Also hast du auch min. 1 eher 2-3 Zeitsprung-Fehler beim Überlauf.

Nein!
Der Unterlauf bei der Subtraktion kompensiert den Überlauf.

Wolfgang schrieb:
> Schlaumaier schrieb:
>> if millis >= alte_millis + Zeit_wert then
> Böse Falle :-(
>
> Was meinst du wohl, was passiert, wenn alte_millis + Zeit_wert einen
> Überlauf produziert.

Kommt auf die Anwendung an, millis() ist ein vorzeichenloser 
32-bit-Wert, läuft knapp 50 Tage (49,71) - Windows_95 lässt grüßen.

Wenn die Anwendung dauerhaft laufen soll, muß man anders programmieren 
oder den Überlauf per Vergleich abfangen, kein Hexenwerk.

Die größere Falle ist, die Variable korrekt als 'unsigned long int' zu 
deklarieren, ein normales 'int' kracht schon nach 32 Sekunden über.

Das sind aber Nebenbaustellen, erstmal muß Arduino-Kind 3nibble (Gast) 
begreifen, ohne delay zu programmieren!

Schlaumaier schrieb:
> if (0 - 1000) >= 1000  then
> Also hast du auch min. 1 eher 2-3 Zeitsprung-Fehler beim Überlauf.

Nein, das trifft nicht zu. Bei einem Überlauf kommt trotzdem genau die 
gewünschte Zeitspanne heraus.

EAF schrieb:
> Zudem kann man das auch fehlerfrei, mit weniger Aufwand, hinbekommen.
> Damit gib es keinen Grund die Krücke zu verwenden!

1

  if(millis()-zeitMerker>=interval)

2

  {

3

    zeitMerker += interval;

4

    // hier tuwas()

5

  }

Jou, ich gucke gerade in mein letztes Project, genau so habe ich es da 
gemacht :-)

3nibble schrieb:
> Ergebnisse im 10-Sekunden-Takt (delay(10000)) auf einem kleinen OLED
> anzeigen bzw. aktualisieren.

Hier ein Taktgeber der dir nichts blockiert:

1

// Multivibrator Taktgeber

2

  mvist = millis();                                    // Multivibrator 

3

  if(mvist - mvstart >= mvinterval){

4

    mvstart = mvist;

5

    if(mv == LOW){

6

      mv = HIGH;

7

      }

8

    else {

9

      mv = LOW;

10

      }

11

     }                                                 // Multivibrator Ende 

12

  if(mv != mvvorher){                                  // Multivibratorflanken

13

    mvpuls = HIGH;

14

    }                                                  

15

  else{

16

    mvpuls = LOW;

17

    }

18

  mvvorher = mv;

19

20

    if(mvpuls == HIGH){

21

      strommessen();

22

      leistung();

23

      displaybeschreiben();

24

   }

Alles klar!
Keine Fragen!

1. Da wird keine Taste abgefragt. Das passiert ein paar Postings vorher.
2. Ja, das ist bei Kooperativen Multitasking so, egal wie kompliziert 
oder primitiv das konstruiert wurde. Das gerade laufende Codefragment 
muss aktiv Rechenzeit abgeben, damit andere Teile auch mal dran kommen.
3. Das muss dir ja gar nicht gefallen. Da gibt es keine Notwendigkeit.

EAF schrieb:
> Alles klar!
> Keine Fragen!

Das bezieht sich natürlich auf:

Joachim B. schrieb:
> Tastendruck

3nibble schrieb:
> Ich müsste
> also erreichen, dass der Tastendruck einen D-Pin dauerhaft setzt, sodass
> ich diesen dann im nächsten Durchgang der Schleife auswerten und wieder
> loslassen kann.

das kann ein if
wenn tasterpin  genau gleich high, dann bool taste gleich high.
Dann bleibt der high.

Joachim B. schrieb:
>> if(millis()-zeitMerker>=interval)
>>   {
>
> Nachteil, wenn irgendwo eine Sub oder Berechnung länger dauert bevor
> wieder millis() abgefragt wird ist der Tastendruck uralt.
> ausserdem wird nicht entprellt.

Du möchtest gerne ein Problem herbeireden, was in 99% aller Anwendungen 
nicht existiert.

Der einfache Mikroprofessor ist nun mal ein seriell arbeitendes Gebilde, 
wenn ein Job aktiv ist, müssen andere eben warten.

Das Beispiel von EAF ist erstmal ein nicht blockierender Timer, nicht 
mehr und nicht weniger. Der ruft eine Unteroutine "// hier tuwas()" auf, 
deren Funktion hier nicht definiert ist.

Dein Tastenproblem ist das denkbar unpassendste, kein Benutzer stört 
sich ernsthaft, wenn eine Taste mit ein paar Millisekunden Zeitverzug 
abgefragt wird. Ich werde einen Teufel tun, eine dusselige Taste in den 
Interrupt zu packen, der Professor hat wichtigere Dinge zu tun als den 
Knopf binnen Mikrosekunden zu bedienen.

Joachim B. schrieb:
> seit ich PeDas Routinen verwende

Was ist das?

Viel zu aufwändig. Monoflop programmieren, fertig.