Go Down

Topic: delay() vermeiden scheitert (Read 2658 times) previous topic - next topic

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

#32
Dec 13, 2018, 10:35 am Last Edit: Dec 13, 2018, 10:36 am by 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!



Säge kein Sägemehl.

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.
Säge kein Sägemehl.

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

#37
Dec 15, 2018, 02:55 pm Last Edit: Dec 15, 2018, 02:58 pm by combie
Quote
aber ist es auch ohne unangenehme Nebenwirkungen?
Welche Nebenwirkungen hättest du denn gerne?
 :o  :o  :o  :o  :o


Quote
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.

Säge kein Sägemehl.

Demokrit

Ja, der Stepper antwortet direkt.

combie

#39
Dec 15, 2018, 03:05 pm Last Edit: Dec 15, 2018, 03:06 pm by 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.
Säge kein Sägemehl.

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

Quote
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.
Säge kein Sägemehl.

michael_x

Quote
Definiere "helfen".
Nö.
Beachte den Kontext des Satzes, auch das smiley. 


Go Up