Hallo,
ich würde gerne diese zwei for-Schleifen gleichzeitig ausführen:
}
for(int b=27;b<55;b++){
pixels.setPixelColor(b, pixels.Color(0,0,50));
for(int a=27;a>-1;a--){
pixels.setPixelColor(a, pixels.Color(0,0,50));
delay(20);
pixels.show();
}
}
Vielen Dank schonmal!
Ja...und wie lautet deine Frage ?
Dann löse die Schleifen auf. Du hast in loop() schon eine Schleife. For-Schleifen kann man daher durch if-Abfrage in loop() ersetzen
for (int i = 0; < 28; i++)
{
pixels.setPixelColor(27 + i, pixels.Color(0, 0, 50)); // b 27..54
pixels.setPixelColor(27 - i, pixels.Color(0, 0, 50)); // a 27..0
delay(20);
pixels.show();
}
wobei halt der erste Durchlauf redundant ist, aber ist es bei dir oben auch...
For Schleifen kann man nicht gleichzeitig ausführen.
Man kann nur, wie gezeigt, beide aktionen in der gleichen for Schleife machen.
Wenn das nicht geht dann in der loop() Schleife mit Statusveriablen und if_'s arbeiten Bzw Millis() und Endlichen Automaten.
Grüße Uwe
For Schleifen kann man nicht gleichzeitig ausführen.
:o ich kann das :o
Oder ehrlicher:
Es gibt ein paar Arduino kompatible Boards, mit denen das möglich ist.
combie:
:o ich kann das :o
Ich auch, mit 2 Arduinos. 8) 8)
Grüße Uwe
combie:
:o ich kann das :o
Wirklich? Ich dachte, das kann nur Chuck Norris
Ja?
Hier schlage ich mich mit der Gleichzeitigkeit rum.
Denn sie nicht nur Vorteile hat.
Oder siehe auch hier, ähnliches Thema.
Chuck Norris?
Ganz so weit ist es noch nicht.
combie:
Chuck Norris?
Ganz so weit ist es noch nicht.
Aber mal ganz ehrlich combie, ganz soo weit davon entfernt bist Du ja nun wirklich nicht mehr. 8)
LG Stefan
Wenn man es richtig 
macht, ist definitionsgemäß alles was innerhalb eines loop() Durchlaufs passiert, "gleichzeitig". Falls sinnvoll, also auch zwei for-Schleifen.
Ist eher eine philosophische oder Definitions-Frage, was "gleichzeitig", insbesondere bei getakteten Prozessoren, bedeutet.
Irgendwo verhindern Leitungslängen, die endliche Lichtgeschwindigkeit und die Relativitätstheorie jede Gleichzeitigkeit.
Hallo,
am Ende macht unser Einkern µC sowieso alles der Reihe nach, also sequentiell.
Blockierfreie Programmierung ist das Zauberwort.
Blockierfreie Programmierung ist das Zauberwort.
Hmm...
"In Nebenläufigkeiten denken."
:o Also, die "Blockadefreiheit", ich glaube, davon bin ich mittlerweile geheilt. :o
Der Begriff ist eben so schwer zu greifen, wie "Gleichzeitig".
Hallo,
Wortspiele?
Der µC macht mit Deiner Lib am Ende auch nichts anderes als alles nacheinander abzuarbeiten. Nur das alles in der Lib versteckt ist. Wenn man Funktionen mittels millis schreibt und diese in der loop aufruft, kommt am Ende das Gleiche bei raus. Nämlich gefühlte Gleichzeitigkeit bzw. gefühlte Nebenläufigkeit. Aber es passiert alles nacheinander, nur eben sehr schnell.
Wortspiele?
Von mir aus!
Betrachte es als Wortspiel.
Wie auch Kinder mit Dingen spielen, ihnen so helfen die Welt zu begreifen.
Das kleine Drama dabei ist, dass sich manchmal Begrifflichkeit und Bedeutung von einander entfernen.
z.B. der Begriff "Blockadefrei Programmieren" impliziert den Verzicht auf langlaufende Schleifen(Endlosschleifen).
Oder Wartezeiten.
Betrachtet man die Nebenläufigkeiten. Das ist das schon mal eine Mehrzahl.
Und jede dieser nebenläufigen Dinge kann dann Schleifen und Wartezeiten beinhalten
Ja, ich weiß, ich war auch mal ein Priester des Schleifenausrollens.
Aber schöner und klarer, macht es die Programme nicht.
Der µC macht mit Deiner Lib am Ende auch nichts anderes als alles nacheinander abzuarbeiten. Nur das alles in der Lib versteckt ist. Wenn man Funktionen mittels millis schreibt und diese in der loop aufruft, kommt am Ende das Gleiche bei raus.
Faktisch ja.
Kann mich aber auch nicht daran erinnern, jemals was anderes behauptet zu haben.
(außer evtl in Sachen 2 Kern µC)
Hier habe ich letztens noch wieder so einen Brocken rausgehauen.
6 Tasks, welche ihr Ding abhandeln.
1 Merker für die Kommunikation zwischen den Tasks.
Jeder TaskBlock ist eine while(1) Endlosschleife.
Bei den TaskMakros war die Schleife noch öffentlich.
Dafür hats dann Kritik, oder Unverständnis gehagelt.
Jetzt ist die Schleife verborgen.
(so wie auch das Goto, auf dem die ganze Show basiert)
Es ist also nicht so sehr ein Wortspiel, sondern eine Betrachtungsweise.
An einer Stelle gibts da:
virtual void run() override
{
TaskBlock
{
taskWaitFor(flag & muster);
digitalWrite(pin,HIGH);
taskPause(interval);
digitalWrite(pin,LOW);
taskPause(interval);
}
}
Da könnte man genauso schreiben:
virtual void run() override
{
TaskBlock
{
while(1)
{
taskWaitFor(flag & muster);
digitalWrite(pin,HIGH);
taskPause(interval);
digitalWrite(pin,LOW);
taskPause(interval);
}
}
}
Macht keinen Unterschied.
Und wenn da nur 5 mal geblinkt werden soll, kommt da eben eine for Schleife in den TaskBlock, welche bis 5 zählt.
Es ist halt die Betrachtungsweise, welche einerseits Schleifen und Warten erlaubt, oder eben verbietet oder als falsch/böse definiert.
Auch wenn faktisch hinten das gleiche dabei raus kommt.
es riecht nur anders
Für mich können 2 for Schleifen nur nacheinander ablaufen (unter der Annahme sie sind nicht verschachtelt).
Also zuerst das was in der Schleife A gemacht wird und dann das was in der Schleife B gemacht wird.
Es kann nicht das was gemacht wird, gemischt werden. Also zB A,B,A,A,B usw
Unter "gleichzeitig" verstehe ich in diesem Fall nicht das etwas in der gleichen µS gemacht wird sondern, daß die Aktion der Schleife A und der Schleife B abgearbeitet wird. Also wie Multitasking oder eben wie die Schleifen bzw Aktionen auf 2 verschiedenen Arduinos ablaufen würden.
Also als Beispiel fällt mir ein:
Auf einem Display von 0 bis 10 Zählen (Variable in For Schleife) und Tastatur Scannen auch in einer For Schleife.
Blockadefrei verstehe ich daß ein Sketch nicht irgendwo auf bessere Zeiten wartet. Also mit delay() pulseIn() umfangreiche For Schleifen zB zum Dimmen von LED mittels while auf ein Ereignis warten usw.
Der loop() muß durchlaufen; er kann für Aktionen mehr oder weniger lang dauern aber selbsttätig sich wiederholen, also nicht auf irgendein Ereignis warten. Wenn er auf irgendwas wartet muß er es bei jedem Loop Durchlauf kontrollieren (polling).
Grüße Uwe
Hi
Trotzdem kannst Du nicht in Deiner While(1)-Schleife mit delay() um Dich werfen - da dann zwar töffte in den Makros hin und her gesprungen wird - aber erst NACH dem delay();.
yield() Mal außen vor gelassen.
Blockadefrei soll doch nur andeutet, daß man den Programmfluss nicht BLOCKIERT, weil Scheiße.
Wer Das dennoch will: meinen Segen hat Er, Jeder so, wie Er glücklich werden will.
Und nun ist aber langsam gut - wir reden wohl Alle vom Gleichen und der Eine oder Andere praktiziert Das sogar - mal mehr sichtbar, mal weniger.
MfG
Für mich können 2 for Schleifen nur nacheinander ablaufen (unter der Annahme sie sind nicht verschachtelt).
Also zuerst das was in der Schleife A gemacht wird und dann das was in der Schleife B gemacht wird.Es kann nicht das was gemacht wird, gemischt werden. Also zB A,B,A,A,B usw
Du meinst z.B. sowas:
#include <Streaming.h>
void funkA()
{
for(int i = 0; i<6; i++)
{
Serial << "A: "<< i << endl;
delay(10);
}
}
void funkB()
{
for(int i = 0; i<6; i++)
{
Serial << "B: "<< i << endl;
delay(10);
}
}
void setup()
{
Serial.begin(9600);
Serial << "Start: "<< __FILE__ << endl;
}
void loop()
{
funkA();
funkB();
}
Ausgabe: (nur ein Schnipsel)
A: 2
A: 3
A: 4
A: 5
B: 0
B: 1
B: 2
B: 3
B: 4
B: 5
A: 0
A: 1
A: 2
A: 3
Genau wie erwartet.
Jetzt könnte man den Wunsch haben, dieses beiden Forschleifen quasi parallel laufen zu lassen.
Damit eben sowas möglich ist:
Also zB A,B,A,A,B usw
Wenn man jetzt in "Blockadefrei" denkt, hat man keine andere Wahl, als die Schleifen auszurollen und mit einer ZustandsVariablen zu arbeiten.
Das zerreißt das Bild, versteckt die Schleife in irgendwelche komplizierten Konstruktionen, so dass man schon dabei schreiben muss, dass dieses eine Forschleife nachbildet.
So wird klar, dass dieses einerseits 2 nebenläufige Fäden sind, und auch, dass in einer Schleife gezählt wird.
#include <TaskMacro.h>
#include <Streaming.h>
Task funkA()
{
static int i = 0;
taskBegin();
while(1)
{
for(i=0; i<6; i++)
{
Serial << "A: "<< i << endl;
taskPause(10);
}
}
taskEnd();
}
Task funkB()
{
static int i = 0;
taskBegin();
while(1)
{
for(i = 0; i<6; i++)
{
Serial << "B: "<< i << endl;
taskPause(10);
}
}
taskEnd();
}
void setup()
{
Serial.begin(9600);
Serial << "Start: "<< __FILE__ << endl;
}
void loop()
{
funkA();
funkB();
}
Ausgabe: (nur ein Schnipsel)
A: 0
B: 0
A: 1
B: 1
A: 2
B: 2
A: 3
B: 3
A: 4
B: 4
A: 5
B: 5
A: 0
B: 0
A: 1
B: 1
A: 2
B: 2
A:3
Trotzdem kannst Du nicht in Deiner While(1)-Schleife mit delay() um Dich werfen -
Wenn man es anders nennt, z.B. taskPause() bleibt die Idee einer Pause erhalten, nur die Funktionalität ändert sich.
taskPause() ist ein "Drop In Ersatz" für delay() um Nebenläufigkeiten bequem zu ermöglichen.
Ohne die ursprüngliche Absicht (eine Wartezeit einbauen) zu sehr zu verwischen.
Natürlich würde man auch eine Kombination aus delay() und yield() so nutzen können. Wurde ja extra von den Arduino Entwicklern, für solche Zwecke, eingebaut.
Aber dabei ist mir schon so viel Abwehr entgegen gebracht worden, dass ich das eigentlich nie wieder erwähnen wollte.
Blockadefrei soll doch nur andeutet, daß man den Programmfluss nicht BLOCKIERT, weil Scheiße.
Blockadefreies programmieren ist quasi unmöglich. (ok, das ist provokant)
Das macht den Begriff ja dieses bisschen fehl platziert (aus meiner Sicht)
Und wenn man das dennoch versucht, wird das Programm bis fast zur Unkenntlichkeit zerrissen.
Hallo,
du reibst dich viel zu sehr an dem Begriff "Blockadefreies programmieren" auf. Wenn ein µC irgendwas tut, kann er zur gleichen Zeit nichts anderes tun. Ist ja nun logisch. Darüber muss man nicht diskutieren. Es dreht sich nur um die Frage wie man Blockadefrei programmiert.
Es dreht sich nur um die Frage wie man Blockadefrei programmiert.
Da du das wie so betonst....
Darf ich dich fragen, wie deine Lösung für dieses Problem aussehen würde?