Hallo,
bin neu hier und hab ein kleines Problem.
Ich möchte eine LED über Taster ein/ausschalten-das hab ich hinbekommen.
Bedingungen sollen sein:
-Wenn Taster dauerhaft ein soll LED maximal 3s leuchten.
-jetzt muss erneut Taster aus-eingeschaltet werden, damit die LED wieder leuchtet
-Wenn Taster aus soll LED sofort aus sein(auch vor den 3sec)
Danke für Eure Hilfe
Das hört sich doch recht machbar an.
Ich würde es so machen:
-Wenn Taster gedrückt (HIGH => LOW oder LOW => HIGH, je nach Anschluss deines Tasters), wird eine Startzeit mit millis() gesetzt.
-Solange Taster gedrückt ist, wird millis()-startzeit > 3000 verglichen…
-wenn die differenz erreicht ist => LED aus
-wenn vorher Taster geöffnet => LED aus
-solange Taster gedrückt, nichts machen (taster solange abfragen bis losgelassen)
-zurück zum Anfang
Wenn das klappt, kann man sich um die Feinheiten wie Taster entprellen oder Pause zwischen zwei Tastendrücken kümmern
(deleted)
(deleted)
Peter-CAD-HST:
Und dabei jede Menge Arduinolebenszeit in Delays versenken. oder ?
Boshafte Unterstellung! 
Aber hey, solange das Anforderungsprofil so simpel ist, warum nicht? Will ja nicht gleich mit zu komplexen Ausführungen abschrecken 
vielen Dank für Eure schnelle Hilfe
ich versuch mich mal heute abend mit millis(kenn ich noch nicht)
vielleicht kann mir jemand ein kleines Beispiel geben
dankeschön
(deleted)
(deleted)
Bedingungen sollen sein:
-Wenn Taster dauerhaft ein soll LED maximal 3s leuchten.
-jetzt muss erneut Taster aus-eingeschaltet werden, damit die LED wieder leuchtet
-Wenn Taster aus soll LED sofort aus sein(auch vor den 3sec
Ergibt sich die zweite Bedingung nicht von allein?
Ich sehe keine sinnvolle Möglichkeit, das mit delay() zu machen.
(per Interrupt oder yield() , wenn es um einen Wettbewerb der kompliziertesten Variante geht.)
Taster entprellen ist überflüssig. Während prellenden Ausschaltens nach langem Tastendruck blitzt die LED so kurz, dass man es nicht sieht, schätze ich mal. Käme auf einen Versuch an.
Dass bei Dauer EIN die LED alle 49,x Tage für 3 sec angeht, merkt keiner.
Peter-CAD-HST:
Ich hab ne DELAY-Allergie
Dann kannst du dein Antihistaminikum eingepackt lassen Wenn ich meinen genannten Programmablauf im Kopf durchgehe, komme ich wirklich ohne Delays aus.
Und wenn an LEDs an/aus und millis() denke, muss ich unwillkürlich an Blink without Delay - Nachtwächtererklärung denken. Guter Einstieg in die besprochene Thematik.
Und wenn an LEDs an/aus und millis() denke, muss ich unwillkürlich an Blink without Delay denken. Guter Einstieg in die besprochene Thematik.
Ja. Diese Aufgabenstellung ist übrigens sehr hübsch zum Zeigen, dass es beim BlinkWithoutDelay-Prinzip nicht um Blinken geht.
Peter-CAD-HST:
Das ist reiner Selbstschutz: Ich hab ne DELAY-Allergie
Ich nicht.
Stufen der Erkenntnis:
Vergleichbares gilt auch für Goto oder andere in Verruf geratene "Dinge"
(deleted)
Peter-CAD-HST:
GOTOs sind bei/in C nur "getarnt" worden
Wenn Du das so siehst, gilt das aber für alle höheren Programmiersprachen - auf Prozessorebene kommt keine ohne 'goto' aus.
(deleted)
vis01:
vielen Dank für Eure schnelle Hilfeich versuch mich mal heute abend mit millis(kenn ich noch nicht)
vielleicht kann mir jemand ein kleines Beispiel geben
dankeschön
Statt direkt millis() köntest Du auch den MoToTimer aus meinen MobaTools nehmen. Da ist auch ein Beispiel drin, dass deinem Wunsch schon recht nahe kommt. Du musst das jetzt nur noch so erweitern, dass die Led auch ausgeht, wenn man den Taster vorher loslässt.
vis01:
vielleicht kann mir jemand ein kleines Beispiel geben
dankeschön
Hallo,
es könnten dir bestimmt viele sofort eine eigene Lib an die Hand geben, mach ich in dem Fall mit millis nicht mehr. Warum? Weil das Verständnis mit dem Umgang dessen essenziell ist. Man muss und sollte es selbst verstanden haben, denn danach kann man damit alles machen was man möchte.
Tipp: Denke an deine Armbanduhr o.ä.. Dein eigener ewig laufender Zähler mit dem du unbewusst tagtäglich irgendwelche Differenzen bildest.
Erklärungen zum Umgang:
Doc_Arduino:
mach ich in dem Fall mit millis nicht mehr. Warum? Weil das Verständnis mit dem Umgang dessen essenziell ist.
Sorry, aber dem muss ich widersprechen. Das Verständnis des 'Nachtwächters' ist essentiell - der Umgang mit millis() nicht.
Beides wird hier gern in einen Topf geworfen (wahrscheinlich aufgrund des Beispiels 'BlinkWithoutDelay ' ), aber das sind 2 ganz unterschiedliche Dinge. Es geht beim 'Nachtwächter' nicht nur um Zeiten und delayfreies Programmieren. Es geht ganz allgemein darum, wie man auf dem Arduino mehrere quasi 'parallele' Abläufe realisieren kann. Dass so ein Ablauf zeitgesteuert ist, ist nur ein Aspekt - das können auch ganz andere Ereignisse sein, auf die reagiert werden soll.
Wobei der 'Nachtwächter' nur eine der Möglichkeiten ist, diese Art des Programmierens zu erklären.
Edit hier wird ja oft genug in einer while-Schleife auf einen Tastendruck oder den Empfang eines Zeichens gewartet. Hat alles nichts mit millis() oder Zeiten zu tun - aber sehr wohl mit der blockierungsfreien Programmierung - eben dem 'Nachtwächter'. Das Erlernen dieser Programmierart ist essentiell für den Einsteiger, wenn er komplexe Sketche schreiben will.
wird hier gern in einen Topf geworfen
Das sehe ich auch so!
Mehrere Aspekte da spielen:
Und ja, das sind grundverschiedene Dinge.
Auch wenn sie in der Regel im Rudel/Verbund auftreten.
Ansonsten kann ich ja mal mit schlechtem Beispiel vorangehen und ein Beispiel vorführen.
(die Libs gibts erst auf Wunsch, und der Gierige findet sie auch so)
/**
* Basisprogramm:
* Das Blink Beispiel aus der Arduino IDE
*
* Zusaetzliche nebenlaeufige Funktionalitaet:
* Eine Ablaufsteuerung
*
* Nach betaetigen des Schalters startet die Absaugung und danach
* die Maschine. Nach abschalten stoppt erst die Maschine und danach die
* Absaugung
*
*
* Ablaufdiagramm - Zeitdiagramm
*
* schalter _----------_____ Schalterstellung
* absaugung _-------------__ Verzoegertes abschalten
* maschine ____-------_____ Verzoegertes einschalten
*
* Der Schalter arbeitet invers und ist entprellt
* Alle Zeiten in ms
*
*/
#include <CombieTimer.h>
#include <CombiePin.h>
#include <CombieTypeMangling.h>
using namespace Combie::Pin;
using namespace Combie::Timer;
using namespace Combie::Millis;
TasterGND<2> schalter; // zwischen Pin und GND(invertierend)
OutputPin<3> absaugung;
OutputPin<4> maschine;
EntprellTimer entprell { 20_ms}; // Schalter entprellen
RisingEdgeTimer ton {500_ms}; // steigende Flanke wird verzoegert
FallingEdgeTimer toff {500_ms}; // abfallende Flanke wird verzoegert
void setup(void)
{
schalter.initPullup();
absaugung.init();
maschine.init();
pinMode(LED_BUILTIN, OUTPUT); // unveraendert aus Blink.ino
}
void yield(void)
{
bool schalterMerker = entprell = schalter;
absaugung = toff = schalterMerker;
maschine = ton = schalterMerker;
}
void loop(void) // unveraendert aus Blink.ino
{
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
Hallo,
häh? :o Hier widerspricht sich gar nichts. Erst mit dem richtigen Umgang mit millis kann man Eure angesprochenen Automaten und delay freies Programmieren überhaupt verstehen und realisieren. Die Basis dazu ist das Verstehen wie man millis korrekt anwendet. Dazu finde ich das Backbeispiel von Theseus sehr passend.