Taskmanager im uC-Bereich

Wenn Taskmanager für µC erwähnt werden darf eine Erwähnung von 
Protothreads auf jeden Fall nicht unterbleiben: Das beantwortet zwar 
nicht konkret alle obigen Fragen und wirft stattdessen neue auf, aber 
dennoch ;-)

Alexander M. schrieb:
> sodass vielleicht Task1 nur dann starten darf, wenn Task2 schon gestartet ist.

Wie wäre es, wenn Task2 einfach Task1 startet?

meinst du sowas?
Beitrag "Wartezeiten effektiv (Scheduler)"

Bernd K. schrieb:
> Wenn Taskmanager für µC erwähnt werden darf eine Erwähnung von
> Protothreads auf jeden Fall nicht unterbleiben: Das beantwortet zwar
> nicht konkret alle obigen Fragen und wirft stattdessen neue auf, aber
> dennoch ;-)

Sehr interessant, bisher nie was davon gehört.. :D

Joe F. schrieb:
> Alexander M. schrieb:
>> sodass vielleicht Task1 nur dann starten darf, wenn Task2 schon gestartet ist.
>
> Wie wäre es, wenn Task2 einfach Task1 startet?

In "größeren" Projekten könnte das meiner Meinung nach sehr schnell sehr 
undurchsichtig werden ;)

Joachim B. schrieb:
> meinst du sowas?
> Beitrag "Wartezeiten effektiv (Scheduler)"

Nein ich meinte schon einen richtigen "Taskmanager", vergleichbar 
vielleicht mit folgendem Beispiel:
Windows wird mit Sicherheit verschiedene States / Tasks haben, gesteuert 
von einem "Haupttask", der untergeordnete Tasks wiederum ansteuert.
Konkreter:
State 1: Anmeldung --> laufende Tasks: Tastatureingabe, 
Bildschirmausgabe
State 2: Startbildschirm --> laufende Tasks: Tastatureingabe, 
Bildschirmausgabe, Initialisierung (benötigt Task: "hole Daten", 
Download externe Files (benötigt wiederum Task WLAN)
State 3: Bildschirm nach Startbildschirm: WLAN, Tastatureingabe, 
Bildschirmausgabe, Audio, AUS: Download externe Files ...

Sieht stark nach einer State Machine aus. Gibts für sowas vielleicht 
schon fertige Implementierungen, sodass solche "State Machines" schnell 
entwickelt werden können und ich mir nicht mehr um das richtige Starten 
und Schließen der Tasks Gedanken machen muss, sondern nur noch sagen 
kann: Starte WLAN --> und im Hintergrund dann alle anderen benötigten 
Tasks gestartet werden.

In die Richtung zielt die Frage ab.

Bernd K. schrieb:
> Protothreads auf jeden Fall nicht unterbleiben

http://www.cocoos.net/

... läuft bei mir in einigen pic18/24 and avr projekten.


mt

Arduino Fanboy D. schrieb:
> Bevor ich die Richtung verstehe, möchte ich darauf aufmerksam machen,
> dass du "Taskmanager" sagst, aber offensichtlich "Scheduler" meinst.
> Stimmt das?

so sah ich das
Beitrag "Re: Taskmanager im uC-Bereich"
was sah ich falsch?

Alexander M. schrieb:
> Ich frage mich, ob hier jemand gute Open-Source Projekte bezüglich einem
> "Taskmanager" im uC-Bereich kennt / verwendet.

Falls es für AVR sein soll: Hast Du schon im AVR-Softwarepool geschaut?
https://www.mikrocontroller.net/articles/AVR_Softwarepool#Betriebssysteme_und_Scheduler

Arduino Fanboy D. schrieb:
> Alexander M. schrieb:
>> In die Richtung zielt die Frage ab.
>
> Bevor ich die Richtung verstehe, möchte ich darauf aufmerksam machen,
> dass du "Taskmanager" sagst, aber offensichtlich "Scheduler" meinst.
> Stimmt das?

Jein, im Endeffekt gehts mir um den "übergeordneten Scheduler", der 
bestimmt, welche Tasks ein / ausgeschalten werden. Der Scheduler an sich 
macht ja beispielsweise nur die Taskwechsel (natürlich viel mehr), aber 
ohne weitere "Logik". Wie vorhin beschrieben, mir gehts da um Task 
beenden starten mit "Abhängigkeiten". Klar kann das alles in den Tasks 
ausgeführt werden, nur wird das halt bei angenommen 10 Tasks schon sehr 
schnell sehr unübersichtlich.

> Alexander M. schrieb:
>> Sieht stark nach einer State Machine aus.
> Ja.
> Dann verwende eine.

Jap.

> Alexander M. schrieb:
>> Gibts für sowas vielleicht
>> schon fertige Implementierungen,
> Aber sicher.
> Leider hast du vergessen, Sprache und µC, zu benennen.
> Oder habe ich das übersehen?

C, uC erstmal egal (sollte eigentlich aber auch erstmal irrelevant sein, 
weil der "Manager" ja erstmal nicht auf Peripherie zugreift, sondern 
"lediglich" im Programmcode unterwegs ist), eventuell aufgebaut mit 
FreeRTOS.

> Alexander M. schrieb:
>> State 1: Anmeldung --> laufende Tasks: Tastatureingabe,
>> Bildschirmausgabe
>> State 2: Startbildschirm --> laufende Tasks: Tastatureingabe,
> Um den Zugriff auf Ressourcen zu "regeln" verwendet man üblicher Weise
> Semaphoren oder einen Mutex, aber das müsstest du schon gefunden haben,
> wenn du dir dem Adam Dunkel seine Protothreads angesehen hast.

Das mit den Protothreads gehe ich morgen an, Danke für den Hinweis ;)

Je länger ich aber überlege, umso eher glaube ich tatsächlich, dass ich 
meinen "Task-Manager" eigentlich besser "State-Machine" taufen sollte... 
Da werde ich mit Sicherheit eher fündig ;)

Joachim B. schrieb:
> Arduino Fanboy D. schrieb:
>> Bevor ich die Richtung verstehe, möchte ich darauf aufmerksam machen,
>> dass du "Taskmanager" sagst, aber offensichtlich "Scheduler" meinst.
>> Stimmt das?
>
> so sah ich das
> Beitrag "Re: Taskmanager im uC-Bereich"
> was sah ich falsch?

Hier gehts ja um Wartezeiten verbessern im Scheduler, mir gehts aber 
eher umd einer Art Erweiterung von beispielsweise FreeRTOS.
Also nochmal in einem anderen Beispiel:
Der Scheduler ist ja dazu da, um bestimmte Tasks ein / auszuschalten, 
wenn (OHNE Task-Manager) Task A sagt: schalte Task B aus --> dann wird 
Task B ausgeschalten, ohne wenn und aber...
Da würde jetzt  (eventuell je nach Einstellung) "mein Task-Manager" 
dazwischenfunken und dem Task A sagen: Sorry, keine Berechtigung im 
aktuellen State, du kannst nur Task C auschalten, nicht B.

Ich verstehe die Frage nicht.

Bei einem Betriebssystem, das beliebige Software, die nachgeladen wird 
ausführen soll macht sowas Sinn (Bsp.: Windows, Linux etc.)
Da weis aber auch der Entwickler des OS nicht, "was" am Ende darauf 
läuft.

Bei einer µC-Firmware (und da wird FreeRTOS genutzt) weis der Entwickler 
genau, welche Tasks überhaupt existieren "können", und da braucht man 
keinen  Task-Manager, sondern einen soliden Plan, wie diese Tasks 
sinnvoll ineinander greifen.

A. S. schrieb:
> Alexander M. schrieb:
>> Da würde jetzt  (eventuell je nach Einstellung) "mein Task-Manager"
>> dazwischenfunken und dem Task A sagen: Sorry, keine Berechtigung im
>> aktuellen State, du kannst nur Task C auschalten, nicht B.
>
> Zum Schutz von Speicher (MMU, MPU) vielleicht. aber was Du hier
> beschreibst, sind Überwachungen in den Tiefen deines Systems, die sich
> kaum generalisierten lassen. Das ist so, als wenn Du ein Fenstersystem
> nutzt und fragst, ob es auch was für die Inhalte gibt.

Mir gings tatsächlich um solche "Überwachungen", aber dann muss ich mir 
wohl selbst was zusammenbasteln.

Danke für Eure Hilfe.

Grüße ;)

Wenn 10 Tasks unuebersichtlich werden, solltest du's sein lassen. Da 
hilft dann leider gar nichts mehr.