Hallo Dieter

Natürlich habe ich mir das Tutorial von Achim S. angesehen, kann aber da auch nur eine sequentielle Arbeitung per Subroutinen erkennen.

Ich habe schon vor einiger Zeit mal ein Programm reingestellt (Nibo2_test_01.c), wo der NIBO2 während des Rückwärtsfahren blinkt und hupt - würde das aber nicht als Multitasking bezeichen.

nix für ungut

beste Grüße
Egon

Hallo
auch eine Graphikausgabe kann man beschleunigen / verlangsamen. Man kann z.B. im Prg festelegn, wie oft der Aufbau oder wechsel erfolgen soll und einen Zählöer entsprechend setzen. so das nur alle 50 oder 100 ms (Durchläufe) es erfolgt. Ich bau dir was zusammen.
achim

Hallo Egon,

wo fängt denn für Dich Multitasking an - bzw. wie definierst Du Multitasking?

Wikipedia z.B. meint:

Der Begriff Multitasking [ˌmʌltiˈtɑːskɪŋ] (engl.) bzw. Mehrprozessbetrieb bezeichnet die Fähigkeit eines Betriebssystems, mehrere Aufgaben (Tasks) nebenläufig auszuführen. Im Allgemeinen bietet der Prozessor hierzu auch unterstützende Strukturen. Die verschiedenen Prozesse werden in so kurzen Abständen immer abwechselnd aktiviert, dass der Eindruck der Gleichzeitigkeit entsteht. ...

Eine ähnliche Vorstellung habe auch ich davon. Vor sehr langer Zeit habe ich mal was über "Zeitscheibenverfahren" gelernt. Klar, dass zum "echten Multitasking" (je nachdem, wie man das definiert und welche Spielart man einsetzt) durchaus noch mehr gehört - aber das was Achim beschreibt ist für mich ein Ansatz dazu.

Er spart sich - in diesem einfachen Ansatz - die Bereitstellung einer "eigenen Umgebung" für jeden Prozess. Wobei streng genommen jede ISR sich ja eine eigene Umgebung "schafft" ... oder liege ich da komplett daneben?

Auch nix für ungut (schön, dass eine Diskussion in Gang kommt ) - und (hoffentlich - bei Sonnenschein) schönen Sonntag noch

Beste Grüße
Dieter

Hi Leute, was Achim erkannt und beschrieben hat ist vor allem "Verzichtet auf das delay(), in der Zeit des Wartens kann etwas anderes erledigt werden"..
Ich denke da immer an den Kaffeeautomat (der kann leider nicht gleichzeitig Espresso und Heisswasser):
Variante 1:
Gehe zum Schrank();
Nimm Tasse();
Stelle Tasse in Maschine();
Drücke KaffeeTaste();
Warte bis Kaffee gemahlen();
Warte bis Kaffee gebrüht();
Warte bis Kaffee in der Tasse();
Nimm Milch();
Gebe Milch in Tasse();
// dauert ca. 80Sekunden

Variante 2 (Multitasking?):
Drücke KaffeeTaste();
Gehe zum Schrank(); // Kaffee wird gemahlen
Nimm Tasse(); // Kaffee mahlt noch
Nimm Milch(); // Kaffee ist fertig gemahlen
Gebe Milch in die Tasse(); // Kaffee brüht derweil
Stelle Tasse in Maschine(); // Kaffee kommt
Warte bis Kaffee in der Tasse();
// dauert ca.50 Sekunden

Mein Fazit: Prozesse brauchen immer ihre Zeit, bei der Umordnung kann etwas Zeit für Leerlauf eingespart werden, aber keine 50%.

Für mich ist der nibo2 ein Automat (ich komme aus der Steuerungstechnik) und deshalb werde ich ihn wohl auch so programmieren wie einen Automaten, d.h. eine Zeitkonstante Zykluszeit (20ms wäre Spitze, realistisch sind wahrscheinlich 100ms), Prozessabbild Einlesen- Verarbeiten-Ausgeben, und alles was schneller als Zykluszeit sein muss, wird im Timer Interrupt abgefragt/erledigt.
Die Hauptschleife wird zwar in einem Bruchteil der Zykluszeit abgearbeitet, aber da sind ja auch die ewigen Unterbrechungen, die diese Zeit in der Hauptschleife verlängern, und während der Prozessor auf den nächsten Zyklusstart warten muss, Prozessabbild bearbeiten, Display- und Schnittstellen bedienen.

Nun Zeitfresser Display: Um das in den Griff zu bekommen, muss man erstmal verstehen, wie das Display funktioniert (Datenblatt KS0108) und dann mal den Sourcecode der Bibliothek nachvollziehen und experimentieren. Das Tolle und Problem an der GFX Bib ist, die Verknüpfung mit dem Hintergrund (Drawmode), hier muss vor dem Schreiben erstmal das Byte aus dem Display ausgelesen werden (ca. 6us), dann wird das neue Byte entsprechend dem Drawmode mit dem Displaybyte verknurpselt, dann muss die Adresse zum Schreiben wieder eingestellt werden (bei Lese- und Schreiboperation macht das Display ein Autoinkrement der Adresse), dann kann das neue Grafikbyte an das Display ausgegeben werden. Und das dauert..
Meine Alternative - einen Rambuffer, aber das kostet.. 1032 Byte Ram extra, und spart aber ca. 3/4 der Zeit.. weil ich nicht aus dem Display lesen, und die Adresse einstellen muss.
Leider habe ich den bisherigen Code nicht Stück für Stück gesichert, so dass die Entwicklung wie bei Achims Tutorials nachvollziehbar wäre. Aber da habe ich auch was von Achim gelernt..

@Dieter: Ich habe auch mit einem EA-Dog mit Touchpanel geliebäugelt; aber erstmal ist das Teil alleine schon fast so teuer wie der nibo2, und zum Zweiten ist mir nicht klar, ob ich auch ohne die teuere Entwicklungsumgebung das Ding vernünftig zum Laufen bringe.

Ein paar Anmerkungen: Das Display für die Biene hat einen eigenen AVR, der vom Haupt-AVR per I2C angesteuert wird. Kostet auch nur 10 Euro mehr

Ja, ISRs haben ihre eigene Umgebung, bzw. speichern die die Register, die sie brauchen, auf den Stack, und räumen Stack und Register beim Verlassen wieder auf.

Zum Multitasking: Ja, da gibts verdammt viele Möglichkeiten Mal die wichtigsten:

* man versucht alles in einer while() reinzustopfen - nunja, nicht die eleganteste Variante^^ Ob man das Multitasking nennen will ist eine andere Frage
* mehrere parallel laufende Zustandsautomaten: Die Funktionen (~einzelne Tasks) werden regelmäßig vom TimerISR aufgerufen, diese machen nur eine Kleinigkeit, speichern den Zustand und returnen sofort. Kooperatives Multitasking ist genau das.
* preemptives Multitasking: Den Tasks werden vom Scheduler die Kontrolle übergeben und auch wieder entzogen. Die Tasks "merken" davon nichts, dafür muss der Schduler den Status der einzelnen Tasks vewalten, man muss darauf achten, dass kritische Sequenzen nicht unterbrochen werden, Zugriff auf HW-Ressourcen und globaler Speicher muss synchronisiert werden etc. pp.

Für viele Sachen sollte die 2. Variante ausreichen Man kann auch die Kombination aus 1. und 2. Variante machen: ein Haupttask, dem über die vom TimerISR kontrollierten Zustandsautomaten zugearbeitet wird.

Man sollte auch Multitasking (im "normalen" Sinne bei "großen" Betriebssystemen und wie es die Wikipedia hat) und Multithreading außeinander halten. Beim Multitasking sind die Prozesse strikter voneinander getrennt, z.B. haben die einen eigenen Adressraum. Beim Multithreading sind die einzelnen Threads im selben Adressraum, können sich also z.B. auch direkt gegenseitig beeinflussen. Auf den Mikrocontroller macht man fast immer Multithreading, schon alleine weil die Mikrocontroller keine MMU (Speicherverwaltungseinheit, die für die verschiedenen logischen Adressbereichen sorgen kann) haben.

Hi Michael



Super erklärt - vielen Dank!

Beste Grüße

Egon