Hallo

Generell ist die Idee mit dem Multitasking sehr gut - dies wurde auch schon in anderen Foren angesprochen. Es ist auch klar, dass nicht jeder User auf Anhieb damit zurecht kommt, speziell wenn das Wissen um Multitasking erst "erarbeitet" werden muss.
Wenn ein User damit nichts zu tun haben will - ok, muss jeder für sich selbst entscheiden.
Dennoch sollte man dies nicht als quasi "unnütz" abtun, "weil es wichtigeres gibt".
Wie dem auch sei - workwind

@jim_quakenbush -also ich finde, dass dem nicht so ist. Schade, wenn Du diesen Eindruck hast. Und ich bin schon der Meinung, dass man hier Fragen diskutieren oder Probleme gemeinsam aufbereiten kann...

mfg

Egon

Hallo zusammen,

O.K. - ich habe mit harten Worten provoziert - aber nur wenige "hinterm Ofen vorgelockt" ...


Neuer Ansatz ...

Ich frage mich, wozu ich mich mit preemptivem Multitasking auf dem Nibo2 beschäftigen soll?

1. Einfach so - "der Weg ist das Ziel"

2. Wegen der Supi-Dupi Vorteile, die preemptives Multitasking bringt

(Schreibt man es nun "präemptiv", "preemptiv" oder gar "preemtiv" ?)


zu 1. O.K., abgehakt. Mache ich auch so, wenn ich etwas verstehen will. Schaun mer mal ...

zu 2. Ja, welche Vorteile haben wir denn? Da fehlt mir, ehrlich gesagt, noch das Verständnis.


Wir bewegen uns auf dem Nibo2. Wenn ich mich umschaue finde ich den ATMEGA128 mit einigen LED's und wenigen Sensoren, nicht zu vergessen das LCD-Display, die direkt angeschlossen sind. Ferner ist ist da ein Co-Prozessor, der auch Sensoren "abfragt" und die Motore steuert. Worüber der Sound ausgegeben wird weiß ich aktuell gar nicht so recht ... ist aber auch egal.

Motore - ja, wir haben hier einen selbstfahrenden Roboter. Das sehe ich eigentlich als ureigenen Zweck, nämlich dass der Roboter sich "orientiert" und definierte "Fahr-Aufgaben" ausführt.

Das Blinken von LED's, die Textausgabe auf dem LCD-Display, die Sound-Ausgabe sind - aus meiner Sicht - nur Beigaben, die man nutzen kann oder auch nicht. Oh, Textausgabe - da habe ich schon einige Erfahrungen gemacht mit "zickigen" LCD-Displays, die partout auf einem sehr eng definierten Timing bestanden, wenn sie denn etwas ausgeben sollten. Wie soll/wird das denn funktionieren im Multitasking? Wie werden IRQ's abgearbeitet? Wie wird die wichtige (nicht unterbrechbare?) SPI-Verbindung zum Co-Prozessor ablaufen?

Ich kann mir viele Problemstellungen vorstellen, in denen ein Multitasking (im engeren Sinn) überaus sinnvoll ist - z.B. bei Rechen-intensiven Programmen, wo andere Programme auch mal "ran wollen" - aber auf dem Nibo2? Hier sind Sensoren und Aktoren das Maß der Dinge - oder liege ich da so falsch? Das ist alles sehr Hardware-nah und hier arbeite ich mit IRQ's, PWM, Timern, SPI und TWI etc. - wie kriege ich das alles mit Multitasking zusammen?

Ich bin gespannt auf die Antworten ...

Dieter - alias, für einige, "jim_quakenbush"

Hallo Dieter,

1.) ist natürlich ein starkes Argument! Der Nibo ist unter anderem eine Plattform zum Erlernen des Umgangs mit Mikrocontrollern. Man soll sich auf verschiedenen Ebenen mit den Problematiken des Embedded Programmierens vertraut machen. Zunächst kann man die fertigen Beispiele und die Bibliothek verwenden und dann nach und nach dazu übergehen, die Hardwarekomponenten direkt anzusprechen. Auch die Problematiken des Multitaskings (Contextswitch/IPC) sind da sehr interessant...

2.) Der Vorteil ist einfach zu Beschreiben: Das Multitasking hört sich teuer an, ist jedoch relativ preiswert! Anstatt sich eine Lösung zu basteln um mehrere Dinge zu tun kann man einfach zwei, drei Threads verwenden. Die "selbstgebastelten Thread Lösungen" sind meistens kompliziert und fehleranfällig - ob sie wirklich resourcenschonender sind sei dahingestellt.
Ach ja noch ein Vorteil: Strom sparen - Der Controller nutzt die SLEEP Instruktion wenn nichts zu tun ist

Ein Befehl wie "fahre 2 Sekunden geradeaus" im Bewegungsthread funktioniert mit Multitasking prima, da ein zweiter Kollisionsvermeidungsthread das Warten durch ein Signal unterbrechen kann wenn ein Hindernis gefährlich wird. Bei meinem Parcours Programm hätte ich PMT gut gebrauchen können...
Falls man Daten mit XBee oder Bluetooth versenden oder empfangen möchte geht das übrigens auch sehr gut aus einem Thread heraus...

DE: Präemptives Multitasking
EN: Preemptive multitasking
Ich spendier noch ein P für die Themenüberschrift!!

Gruß,
workwind

Hallo
als Verursacher der ganzen Sache, muss ich wohl auch was dazu sagen.
Workwind hat mit seiner Sichtweise vollkommen recht. Es ist eine Lehrplattform für Roboter und Programmierung. Dazu zählt das Programm und die Hardware. Jeder kann das machen, was er kann. Vom Einsatz der Bibliotheken bis zu eigenen Programmen oder ganz anderen Sachen. Jeder nach seinen Möglichkeiten. Dabei sind kaum Grenzen gesetzt. Wenn die Hardware nicht reicht, kann man auch was dazu bauen. Auch darin besteht ein Teil des Sinns der ganzen Sache. Wenn ich was dazu baue, muss ich es auch programmieren bzw anwenden.
Auch das Multitasking hat seinen Sin und Berechtigung. Es gibt bestimmte Abläufe und/oder Funktionen die anders kaum, sehr schwer oder garnicht machbar sind. Als Beispiel: das Menue mit Einknopfbedienung. Das geht los bei der Entprellung und weiter der Auswertung von verschieden langen Druck und anderen Sachen.
Was ich nicht verstehe ist einfach zu sagen. Muss der Aufwand so gross sein? Es sind so ca. 10 Unterprg dabei. Wo kommt den meine eigenes Prg hin und wie wird es eingebunden? Wie erfogt der Aufruf der ganzen Prg? Für mich ist einfach zu schwer es zu verstehen oder anzuwenden. Gibt es nicht einfaches?

achim

Hi,

"eigentlich" (hi) ist das Konzept recht einfach

Schau dir mal die main.c an, und da die main-Funktion.
Am Anfang wird der Timer initialisiert, der für die regelmäßige Unterbrechung führt. Das kannst du einfach so übernehmen.
Danach gibts 3 task_init(), die als Übergabe den Speicherbereich für die Verwaltungsstruktur des Tasks, den Pointer auf den Stack des Tasks und dessen Größe bekommt.
Den Stack braucht der Task für lokale Variablen, Funktionsaufrufe und sowas.
Ein Task ist eine ganz normale Funktion, in dem Beispiel sind es die threadMainA bis threadMainC .

Mit thread_startScheduler(0); wird der Scheduler als solches gestartet, mit thread_start(&threadA, &threadMainA, 0); dann die einzelnen Tasks. Diese Funktion bekommt neben der Verwaltungsstruktur den Funktionspointer auf den Start des Tasks. Wie du siehst kann jede Funktion als Task gestartet werden, es ist nur zweckmäßig, dass die Tasks eine Endlosschleife haben, weil wenn der Task das Ende der Funktion erreicht ist das Programm beendet (@workwind: Wird das vom Scheduler abgefangen oder passiert dann "sonstwas"? Hab mir den Code noch nicht tief genug angeschaut)

Danach brauchts halt noch ein
while (true) {
thread_wait();
}
, weil die main() in dieser Implementierung als Task im Hintergrund weiterläuft.

das task_signal signalisiert dem Scheduler, dass die Tasks, die auf das Signal warten, weiterlaufen können - ist z.B. zur Kommunikation interessant, wenn der Task A neue Daten für Task B hat (z.B. neue Fahrbefehle von der UART reingekommen oder so)

Kurz: Wenn du einen neuen Task bauen möchtest baue die Logik in eine normale Funktion ein, erstelle Speicherbereiche für Stack & Verwaltungsbereich, und nehme die task_init/task_start Funktionen Eventuell brauchst du auch das task_signal, damit die Tasks loslaufen - musst du ausprobieren, da müsste ich den Code genauer lesen, um da eine sichere Aussage machen zu können

Hallo workwind,

prima - ich nehme das p gerne an und kaufe noch ein ä dazu . Habe jetzt ein e günstig abzugeben - wer mag, kann sich gerne melden ...

Jaaa - teuer und preiswert - das ist relativ. Und die Vorteile der Threads überzeugen mich ehrlich gesagt noch nicht so recht. 2 Sekunden geradeaus fahren kann ich auch, wenn ich die Fahrt durch einen Timer-Interrupt nach 2 Sekunden beenden lasse (macht der Thread doch im Grunde genommen genau so - oder?). Und wenn ich dann noch einen anderen Interrupt mit der Hindernis-Erkennung "beauftrage" kann ich auch in diesem Fall entsprechende Maßnahmen ergreifen.

AVR-Programme laufen - vereinfacht - doch generell so ähnlich ab:

ISR ...

ISR ...

...
main()
...

while()
{
Funktion/Prozess 1
Funktion/Prozess 2
Funktion/Prozess 3
...
}

sub1()...

sub2()...

Irgendwo gar nicht so unähnlich den Threads - nur dass ich mich selbst um alles kümmere. Dafür habe ich aber auch nicht den ganzen Verwaltungs-Overhead ...
Außerdem frage ich mich, ob Multitasking der richtige Einstieg "...zum Erlernen des Umgangs mit Mikrocontrollern ..." ist. Ich denke, bevor man sich nicht mit allen Aspekten des Microcontrollers (Speicherverwaltung, Register, Interrupts, PWM, SPI, TWI etc.) beschäftigt hat wird man sich nicht unbedingt erfolgreich mit den hohen Weihen des Multitaskings beschäftigen können. Mag sein, dass ich da komplett falsch liege, aber so sehe ich das aktuell.

Mir fehlt auch noch eine Antwort auf die Behandlung zeitkritischer Prozesse durch das Multitasking. Vom Programm-lesen werde ich da nicht schlauer.

Beste Grüße
Dieter