delay() vermeiden scheitert

[Demokrit]

Der Slider soll autark und netzunabhängig arbeiten. Ich nutze ein 20x4 LCD zusammen mit der LCDMenuLib2 und einem Drehgeber. Dieser Teil steht bereits weitgehend, ich habe ihn nur aus diesem Thread heraus gelassen, um die Sache nicht zu komplizieren. Am aktuellen Menüsystem stört mich noch etwas der fehlende "dynamische" Aufbau. Wünschenswert wäre, wenn nach Wahl eines Betriebsmodus nur Felder angezeigt würden, die für diesen relevant sind. Auch die Sprachauswahl wird derzeit erst nach einem Rücksprung in eine tiefer liegende Menüebene berücksichtigt. Das sind aber Luxusprobleme.

Im realen Code nutze ich plattformunabhängige Variablendefinitionen, um einen späteren MC Wechsel zu vereinfachen. Den derzeit genutzten Uno habe ich bewußt gewählt, um von Anfang an speicherbewusst zu entwickeln.

Wenn später der Mega nicht passt, dann nehme ich was größeres. Die Dinger sind ja alle erfreulich günstig.

[Demokrit]

Ich habe noch etwas wichtiges vergessen. Der Sketch von combie hat anfangs Fehler geworfen ('TASK' does not name a type). Nach Ersatz von TASK durch void (wie in den Beispielen) lief es durch - und tat, was es soll. Ob das jetzt so richtig ist, kann ich (derzeit noch) nicht beurteilen.

[combie]

Ja, bei der älteren Version ist das so!


Ein
> typedef  void Task; //  Task Type
 am Anfang der Lib schafft Abhilfe


Alles richtig gemacht!

Da habe ich nicht aufgepasst.
Danke, für den Hinweis!

[Demokrit]

Prima. Danke für die Rückmeldung. Ich habe die Lib aus dem verlinkten Thread genommen. Gibt es eine jüngere Version?

[combie]

Ja, es gibt eine jüngere.

Der Kern ist  identisch.
Und das Drumrum ist allerdings noch nicht fertig, verbuggt.
Ich habe dummer weise den Code mit der neuen getestet.

Nimm ruhig die ältere... das passt schon.
Die tut, wie in dem Thread beschrieben.
Ist schlank und stabil.

Wichtiger, ob alt oder neu, ist, dass du verstehst, was sie tut.
Sonst kann man sich damit super gut selber ein Beinchen stellen.

[Demokrit]

Ja, ich bemühe mich gerade um das Verständnis. Erste Umbauten haben schon mal auf Anhieb funktioniert (mehrere Auslösungen bevor der Fotoautomat wechselt, sowie Verschieben des 'carriageSettle' in den Motorteil, wo es eigentlich doch hingehört, denn auch nach dem letzten Schritt sollte noch ausgelöst werden.

Bislang bin ich ziemlich begeistert.

[Demokrit]

Hallo combie,

darf ich Dich noch mal was fragen? Ist folgendes Konstrukt zulässig:

Code: [Select]

Task goHomeT() {
 taskBegin();
 while (1)
 {
   taskWaitFor(goHome);

   lcd.setCursor (0, 2); lcd.print(F("    Going home      "));
   stepper.enableOutputs();
   if (homePos) {
     // Home on off-motor side
     stepper.setSpeed(-MAXSPEED);
     stepper.moveTo(limitBPos);
   } else {
     // Home on motor side
     stepper.setSpeed(-MAXSPEED);
     stepper.moveTo(0);
   }
   taskWaitFor(stepper.distanceToGo() == 0);
   Serial.println(F("At Home "));
   goHome = false;
   goneHome = true;
 }
 taskEnd();
}

Es geht speziell um die Frage, ob das zweite 'taskWaitFor(stepper.distanceToGo() == 0)' ok ist, oder ob ich mir damit doch wieder eine delay-ähnliche Blockade einbaue?

Der Hintergrund: Ich hatte bislang Homing, Limiting und goHome im Setup. Letzteres benötige ich aber mehrmals, und habe es deshalb in den Loop gezogen. Funktionieren tut es - aber ist es auch ohne unangenehme Nebenwirkungen?

[combie]

aber ist es auch ohne unangenehme Nebenwirkungen?

Welche Nebenwirkungen hättest du denn gerne?
        

Es geht speziell um die Frage, ob das zweite 'taskWaitFor(stepper.distanceToGo() == 0)' ok ist, oder ob ich mir damit doch wieder eine delay-ähnliche Blockade einbaue?

Ich wüsste jetzt nicht wie dir die Blockade gelingen sollte....
Dabei nehme ich mal an, dass stepper.distanceToGo() selber nicht wartet, sondern sofort wieder mit seinem Wert zurückkommt.

[Demokrit]

Ja, der Stepper antwortet direkt.

[combie]

Ja, der Stepper antwortet direkt.

Dann wird (bei dem Schritt)  der Vergleich "stepper.distanceToGo() == 0" ebenso oft ausgeführt, wie der Automat aufgerufen wird, bis der Vergleich wahr wird.

[michael_x]

Wichtiger [...] ist, dass du verstehst, was sie tut.
Sonst kann man sich damit super gut selber ein Beinchen stellen.

Man sollte generell nicht annehmen, das Verwenden einer Bibliothek würde einem helfen.  

[Demokrit]

Dann wird (bei dem Schritt)  der Vergleich "stepper.distanceToGo() == 0" ebenso oft ausgeführt, wie der Automat aufgerufen wird, bis der Vergleich wahr wird.

Das ist ok, zumal bei meiner Anwendung der Stepper eine Hauptrolle spielt. Ich wollte nur sicher gehen, weil in den bisherigen Beispielen 'taskWaitFor' das Kriterium für die Zuordnung der Zeitscheibe war - und ich eine zweite starte, während die erste läuft.
 
Danke für die Klarstellung.

[Demokrit]

Man sollte generell nicht annehmen, das Verwenden einer Bibliothek würde einem helfen. 

Definiere "helfen". Wenn Du damit meinst, dass man ohne Bibliotheken einen besseren Einstieg in C findet, als mit, so stellst Du die Existenzberechtigung aller Bibliotheken in Frage - und konterkarierst eine der (angeblichen) Hauptfeatures der Arduino Umgebung: "Dinge erreichen, OHNE sehr tief in C einsteigen zu müssen". Wenn die Lernkurve zu steil wird, und Erfolge ausbleiben, verliert man leicht die Lust. Ich spreche dabei nicht unbedingt von mir.

[combie]

weil in den bisherigen Beispielen 'taskWaitFor' das Kriterium für die Zuordnung der Zeitscheibe war -

Es gibt keine definierte "Zeitscheibe".


Das ist ein kooperatives Multitasking.
Das bedeutet, dass die Task Kontrollworte (taskSwitch(), taskPause(), taskWaitFor()) den Programmfluss freiwillig abgeben.


Ich bitte um Vorsicht, vor falschen Vorstellungen.
Es ist meist schwieriger, sie wieder los zu werden, als sie sich einzubilden.

[michael_x]

Definiere "helfen".

Nö.
Beachte den Kontext des Satzes, auch das smiley.