Die ganze Diskussion ist doch für die Katz. Der Ansatz mit for Schleife und delay vom TE ist schlicht Mist, weil Sackgasse. Irgendwann wird er es hoffentlich verstehen, wenn er Nachtwächter, blinkwithoutdelay, etc. durch und vor allem verstanden hat.
combie:
2. Die for() Schleife mit einem Austiegs- und einem Wiedereintrittspunkt versehen. Das hat den Vorteil, dass sie als Schleife wiedererkennbar im Code bleibt, aber dann nicht mehr "so" funktioniert, wie man es gewohnt ist.
Da wäre eine Möglichkeit die oben von mir aufgeführte While-Schleife. Hier könnte man die parallel laufenden Aufgaben einfügen z.B. Abfrage einer Abbruchtaste. In bestimmten Fällen kann das sinnvoll sein.
Speedcore016:
Aber! Ich möchte einen Verlauf erzeugen, und hierbei hilft das delay ( Wurde von mir bereits getestet) kann ich hier mir einfach mit dieser millis() Funktion helfen, um das selbe Ergebnis zu erzeugen ?
Delay und millis() sind grundverschiedene Konzepte. Ich habe das mal mit dem Backen von Kuchen erklärt: 2 Lüfter unterschiedlich laufen lassen. - #12 by Theseus - Deutsch - Arduino Forum
Delay wartet stupide bis die Sekunde vorbei ist. Millis() ist eigentlich nur eine Uhr und keine Wartefunktion. Das wird sie erst, wenn du dir die Uhrzeit merkst. Dann vergleichst sie im weiteren Programmablauf immer wieder mit der aktuellen Uhrzeit bis eine Sekunde vorüber ist. In der Sekunde kannst du andere Aufgaben erledigen, du musst nur regelmäßig auf die Uhr schauen. Delay ist bequem, bei millis() musst du das Merken des Startzeitpunktes und den regelmäßigen Uhrzeitvergleich an sinnvollen Stellen programmieren.
delay ist böse.
delay darf man nicht verwenden.
delay hält den Prozessor davon ab, andere Dinge, die vielleicht grad wichtig sind, zu erledigen.
Man kann delay für testzwecke verwenden "funktioniert mein Transistorschalter?" oder "wird die Variable in der Funktion verändert?" Das fällt die Kategorie "loop verzögern"
Was der TO aber will ist ja: "jede Sekunde einen anderen Pin ansteuern"
das ist was anderes.
das musst du aber anders lösen:
Laß die loop in ungebremster Geschwindigkeit rennen.
Merk' dir die Schaltzeiten, und immer nach einer Sekunde schaltest du den nächsten Pin.
Hierzu gab es ja schon Beispiele.
Ich empfehle an dieser Stelle wieder mal BlinkwithoutDelay - Die Nachtwächtererklärung
Hilft immer wieder das mit den millis zu verstehen.
delay() ist notwendig, wenn Du mit einem ESP8266 eine WLAN Verbindung aufrecht erhalten willst...
hast Du kein delay(), dann gibt's einen watchdog - Event.
ein delay(1) in loop() reicht dafür aus.
... sagt meine Erfahrung.
hajos118:
delay() ist notwendig, wenn Du mit einem ESP8266 eine WLAN Verbindung aufrecht erhalten willst...hast Du kein delay(), dann gibt's einen watchdog - Event.
ein delay(1) in loop() reicht dafür aus.
... sagt meine Erfahrung.
Nein!
OK, nichts gegen deine Erfahrung, die mag richtig sein....
Aber das mit den Zusammenhängen....
Ein delay() ist nicht nötig.
Schon gar nicht in loop()
Warum?
Weil unbedingt yield() aufgerufen werden muss! (oder einer seiner Verwandten)
Weil es keinen Sinn macht die Anwendungstask länger zu blockieren, als die Hintergrundtask an Zeit braucht.
Natürlich kann man delay() aufrufen, auch wenn man eigentlich yield() aufrufen möchte, denn delay() ruft intern yield() auf.
Macht nur meist keinen Sinn, da es die Anwendung verzögert.
Möchte man die Anwendung verzögern? Dann ist nichts dagegen einzuwenden.
Aber oft möchte man/ich das nicht.
In loop() macht delay() keinen Sinn, aus den vorgenannten Gründen.
Zusätzlich:
Vor dem loop() Aufruf wird automatisch yield() aufgerufen.
Jedes mal!
Also:
delay() nur aufrufen wenn WIRKLICH die Anwendung verzögert werden soll.
Dafür wurde delay() erfunden.
Das kann es gut.
Hat man in seinem Code lang laufende Schleifen, oder ähnlich, welche den WDT auslösen würden, dann schreibt man da yield() rein, damit die Hintergrundtask auch mal die Chance bekommt, ihren Kram zu erledigen.
Die Zeit, welche sie braucht, bestimmt sie dann selber.
guntherb:
delay ist böse.delay darf man nicht verwenden.
delay hält den Prozessor davon ab, andere Dinge, die vielleicht grad wichtig sind, zu erledigen.
Gerade deshalb tüftle ich zur Zeit an "Karajan", ein Scheduler, der mehr kann, als nur "Blink ohne Delay".
U.a. auch über Serial in Scheibchen zu reporten, ohne Radio zu blockieren.
@combie:
Danke für die Anmerkung, werd' sie mal in den entsprechenden sketches ausprobieren!
combie:
Warum?
Weil unbedingt yield() aufgerufen werden muss! (oder einer seiner Verwandten)
Läuft yield() auf einen Arduino Uno, Mega, oder Nano?
Ja, nur braucht man es da nicht, weil im Hintergrund nichts bedient werden muss
ElEspanol:
Ja, nur braucht man es da nicht, weil im Hintergrund nichts bedient werden muss
Ich verstehe Dich nicht.
Läuft das Konstrukt auch auf diese Prozessoren oder nicht?
Es wird kompiliert und es läuft
Yield() ist als leere Funktion definiert, mit Attribut weak.
Man kann sie also mit einer selbstgeschriebenen 'Überlagern'
Wenn Du im Sketch eine eigene Funktion
void yield(void) {
// Code, der währende delay ausgeführt wird
}
definierst, wird sie während dem delay in einer Schleife immer wieder aufgerufen.
MicroBahner:
void yield(void) {
// Code, der währende delay ausgeführt wird
}
definierst, wird sie während dem delay in einer Schleife immer wieder aufgerufen.
Cool! also muss man aber darin nur kurze atomare codeschnipsel darin schreiben.
Wenn es zu lang wird ist dann delay gefälscht?
Ein Gedanke hatte ich noch:
Was passiert, wenn man auf digitalPin 3 ein PWM Signal schickt und zugleich Pin3 als Interrupt definiert?
Hat man dann ein Interrupt, das 490 mal pro Sekunde aufgerufen wird?
RIN67630:
Cool! also muss man aber darin nur kurze atomare codeschnipsel darin schreiben.
Wenn es zu lang wird ist dann delay gefälscht?
Jein, da delay intern mit micros() arbeitet und in einer while-Schleife im ms-Raster herunterzählt. Solange yield() deutlich weniger als 1ms benötigt, sollte es die delay-dauer nicht wesentlich beeinflussen. Wobei eher die kurzen delay-Zeiten kritisch sind.
RIN67630:
Ein Gedanke hatte ich noch:
Was passiert, wenn man auf digitalPin 3 ein PWM Signal schickt und zugleich Pin3 als Interrupt definiert?
Hat man dann ein Interrupt, das 490 mal pro Sekunde aufgerufen wird?
Ein interessanter Gedanke. Wenn ich mich recht erinnere, habe ich im Datenblatt gelesen, dass der Interrupt auch funktioniert, wenn der Pin auf Ausgang geschaltet ist, so dass die ISR per Software ausgelöst werden kann ( hab aber jetzt nicht nochmal nachgeschaut ). Ob die Arduino SW das aber entsprechend initiiert, ist eine andere Frage. Könnte ja auch sein, dass mit dem attach der PWM abgeschaltet wird. Müsste man mal testen.
Edit: hab's mal kurz getestet - funktioniert.
Was passiert, wenn man auf digitalPin 3 ein PWM Signal schickt und zugleich Pin3 als Interrupt definiert?
Hat man dann ein Interrupt, das 490 mal pro Sekunde aufgerufen wird?
MicroBahner:
hab's mal kurz getestet - funktioniert.
Danke. Supi!
Dann hat man doch in gewisse Weise ein Hauch von Preemptive Multitasking.
Dann hat man doch in gewisse Weise ein Hauch von Preemptive Multitasking
Der Timer kann auch Interrupts auslösen, ohne einen Pin zu belegen.
Der Umweg über den Pin hat nichts preemptives an sich.