Hallo zusammen, ich schreibe gerade an der Doku für ein µC-Projekt. Dort gibt es verschiedene Zeitebenen. Die langsamste ist die main loop, die beiden schnelleren Ebenen sind als ISRs unter dem Namen "slow" und "fast" mit unterschiedlichen Prioritäten implementiert. Jetzt suche ich einen (englischen) Begriff, der auf alle drei Entitäten zutrifft. "task" scheint Systemen mit einem Scheduler vorbehalten zu sein. "function" trifft nicht auf die langsame Hauptschleife zu ,"loop" nicht auf die beiden Zeitebenen mit den höheren Wiederholraten.
Das sind alles einfach nur "Aufgaben". Task, Funktion, Methode, Sketch usw. sind nur verschiedene Namen dafür.
Walter T. schrieb: > "function" trifft nicht auf die langsame Hauptschleife zu Dann nenne es doch Hauptschleife. Und dann z.B. Unterprogramm, Funktion, Prozedur etc.
Funktionsblock?
Peter D. schrieb: > Das sind alles einfach nur "Aufgaben". "Aufgabe" heißt auf Englisch "Task". Mir wurde gesagt, dass bei Task die Softwerker das Vorhandensein eines Schedulers implizieren.
Tja, wenn du immer nur auf das hörst, was die gesagt wurde, dann kannst du das Problem nicht lösen. Du musst das System mit dem ISRs eh genau beschreiben, die sind dann halt dein Scheduler. Oliver
In vielen Fällen besteht der Unterschied zwischen einer guten und einer mittelguten Doku eben darin, für einen Sachverhalt den am besten passenden Begriff zu finden. Als fachfremder sucht man nach dem passenden Begriff leider etwas länger.
Ich hätte mich ja auch mit Task begnügt und allenfalls im Vorwort den Kontext dazu erklärt, so wie du es hier im Forum gemacht hast. Ansonsten: Procedure?
Walter T. schrieb: > für einen Sachverhalt den am besten > passenden Begriff zu finden. Nicht alles läßt sich mit einem Begriff erklären und nur die wenigsten Wörter sind eindeutig. Wenn Du zwischen Main und Interrupt Aufgaben unterscheiden willst, schreib eben Main-Task und Interrupt-Task. Eine Doku ist keine Programmiersprache und selbst in c haben z.B. "break" oder "static" mehrere Bedeutungen.
Danke für die Diskussion. Sie hilft dabei, sich nicht in eine Richtung festzufahren. Tatsächlich lässt sich das Ganze doch ganz übersichtlich darstellen, ohne einen Sammelbegriff für ISR und Hauptschleife zu haben. Und nimmt man noch Variablen dazu, eignet sich auch der komplett generische Begriff "Funktionselemente".
Angehängte Dateien:
-
Tasks_und_so.png
(32 KB)
Was soll denn ein DRO sein? Eine gute Doku verwendet Abkürzungen nur sparsam.
Hallo Peter, das weiß ich. Es sei denn, die Abkürzung ist so gängig wie der Gesamtbegriff oder dieser ist etwas sperrig, was in diesem Fall zutrifft. Deswegen lautet die Kapitelüberschrift: "Digital Read Outs (DROs)".
Walter T. schrieb: > eignet sich auch der komplett > generische Begriff "Funktionselemente". Ich hätte "Domäne" vorgeschlagen. Domäne geht immer. Auch im Englischen als "domain". Völlig generisch und kling schön wissenschaftlich überhöht. Sagt nichts anderes als dass es unterschiedliche Bereiche gibt die durch irgendwas abgegrenzt sind.
Gast
#6404811
Walter T. schrieb: > Jetzt suche ich einen (englischen) Begriff, der auf alle drei Entitäten > zutrifft Procedure würd ich hier vorschlagen einfach weil es im fertig assemblierten Kompilat aller wahrscheinlichkeit eh als prozedur hinterlegt wurde. sich wiederholende (/Gruppen von) Prozeduren werden nicht nur umgangssprachlich auch als Routinen bezeichnet ;) (so heist der "boot vorgang" am Rechner im englischen auch "boot routine" ;) ) 'sid
Tatsächlich würde ich beim Begriff "Tasks" nicht unmittelbar daran denken, dass es auch eine ISR sein könnte, aber der Begriff wäre dafür auch nicht völlig abwegig. "Routine" finde ich aber ganz gut. ISR steht ja letztendlich auch für "Interrupt Service Routine ". Peter D. schrieb: > Was soll denn ein DRO sein? > Eine gute Doku verwendet Abkürzungen nur sparsam. Würde ich nicht sagen. Eine gute Doku hat ein Abkürzungsverzeichnis und erkärt bei Einführung einer Abkürzung deren Bedeutung etwas genauer. Sie schreibt es dann nachher aber nicht bei jedem einzelnen Vorkommen nochmal komplett aus.
Gast
#6405135
Rolf M. schrieb: > Tatsächlich würde ich beim Begriff "Tasks" nicht unmittelbar daran > denken, dass es auch eine ISR sein könnte Warum denn nicht? Ich sehe da überhaupt kein Problem. Ein Task ist eine "Aufgabe", ein Stück Code, was einen bestimmten Zweck erfüllt und dazu nach irgendwelchen Regeln konkurrierend mit anderen Tasks zu Ausführung kommt. Das passt ganz genau auch auf ISRs. Der Scheduler ist hier übrigens schlicht die Hardware mit der gewählten Konfiguration. Beides zusammen bestimmt die Regeln, nach denen dieser Scheduler arbeitet. Nirgendwo steht geschrieben, dass ein Scheduler in Software realisiert sein muss.
c-hater schrieb: > Rolf M. schrieb: > >> Tatsächlich würde ich beim Begriff "Tasks" nicht unmittelbar daran >> denken, dass es auch eine ISR sein könnte > > Warum denn nicht? Weil ich bei dem Begriff zuerst eher an klassisches Multithreading denke. > Ich sehe da überhaupt kein Problem. Ein Task ist eine "Aufgabe", ein Stück > Code, was einen bestimmten Zweck erfüllt und dazu nach irgendwelchen Regeln > konkurrierend mit anderen Tasks zu Ausführung kommt. Du hast vergessen, den zweiten Teil des Satzes mit zu zitieren: Rolf M. schrieb: > aber der Begriff wäre dafür auch nicht völlig abwegig.
Gast
#6405161
Rolf M. schrieb: > Weil ich bei dem Begriff zuerst eher an klassisches Multithreading > denke. Definiere "klassisches Multithreading"...
Gast
#6405172
Walter T. schrieb: > ISRs unter dem Namen "slow" und "fast" mit > unterschiedlichen Prioritäten implementiert. Ich finde slow und fast nicht gut gewählt. Was genau möchtest du damit aussagen? Der µC wird ja vermutlich in beiden ISRs gleich schnell laufen (F_CPU konstant). Ich könnte mir eher vorstellen, dass du die Aufrufhäufigkeit der ISRs meinst (frequency, rate) oder die Dauer/den Zeitslot, der einer ISR zur Verfügung steht (long, short ISR), oder es geht dir um die erlaubte Latenz, bis die ISR aufgerufen wird (siehe Prioritäten). Slow/fast sind hier von der Bedeutung her ziemlich leer/vage, finde ich.
c-hater schrieb: > Rolf M. schrieb: > >> Weil ich bei dem Begriff zuerst eher an klassisches Multithreading >> denke. > > Definiere "klassisches Multithreading"... Ich habe eine Funktion, mit der ich Threads erstellen kann. Threads können prinzipiell unabhängig von einander laufen und haben jeweils ihren eigenen Stack. Ein Thread kann blockierend warten und damit den Prozessor für beliebige andere Threads freigeben. Ein Scheduler kümmert sich automatisch darum, dass von den gerade nicht als blockierend markierten Threads immer einer ausgewählt und ausgeführt wird. In der Regel gibt's noch einen Idle-Thread, der immer ausführbereit ist und entweder in einer Schleife Däumchen dreht oder den Prozessor schlafen legt, für den Fall, dass die anderen Threads allesamt gerade blockieren.