Hier habe ich ein kooperatives Multitaskingsystem mit extrem wenig Overhead gefunden: https://github.com/joe7575/Arduino-MOS Rein optisch macht es einen sehr eleganten Eindruck. Jetzt bleibt nur die Frage, was man interessantes damit machen könnte.
Markus schrieb: > Rein optisch macht es einen sehr eleganten Eindruck. Hätte nie gedacht dass bei einem Multitaskingsystem die Optik zählt. Wie misst man die Optik? Kannst du mir helfen wie ich in den Kernel von Windows hineinschauen kann um die Optik zu beurteilen?
>Hätte nie gedacht dass bei einem Multitaskingsystem die Optik zählt. Selbstverständlich zählt die Optik eines Codes ganz entscheidend. Es gibt schönen und schöneren Code. Es gibt natürlich auch weniger schönen Code. Der hier z.B. ist nicht hässlich, https://github.com/chrismoos/avr-os aber doch nicht so klein, übersichtlich und elegant in der Namensgebung wie der Obige. >Kannst du mir helfen wie ich in >den Kernel von Windows hineinschauen kann um die Optik >zu beurteilen? Das kann ich nicht und würde es niemals tun. Im Windows Code ist keine Schönheit zu erwarten.
Markus schrieb: > Hier habe ich ein kooperatives Multitaskingsystem mit extrem wenig > Overhead gefunden: > > https://github.com/joe7575/Arduino-MOS > > Rein optisch macht es einen sehr eleganten Eindruck. Jetzt bleibt nur > die Frage, was man interessantes damit machen könnte. Das Ding ist wohl von Adam Dunkel's Protothreads "inspiriert", auch wenn die Liste "inspired by" dies nicht erwähnt. Das zweite ist deshalb "unelegant", weil es ein preempzives Multitasking kann, also einem "OS" deutlich näher kommt. Es braucht aber pro Task 256byte für den Stack. Nix für Tiny24.
:
Bearbeitet durch User
>Das Ding ist wohl von Adam Dunkel's Protothreads "inspiriert", auch wenn >die Liste "inspired by" dies nicht erwähnt. Interessant, die kannte ich nicht: http://dunkels.com/adam/pt/index.html Sie sind in C und damit etwas einfacher als C++ zu verstehen.
Wobei ich aber fast finde, dass mit den Protothreads die Codeschönheit verloren gehen kann: https://github.com/georgeredinger/protothreads/blob/master/src/ir.ino
Sowas ähnliches gibt's in FreeRTOS schon ewig, heißen dort Co-Routinen. http://www.freertos.org/crcreate.html Hier findet man auch eine ganz interessante Erklärung, was man mit Co-Routinen noch so machen kann: http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
>http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
Ein ganz netter Artikel, wenn man auch so ein Konstrukt vermutlich sonst
nirgends finden wird ( case 1: in for Schleife ).
1 | int function(void) { |
2 | static int i, state = 0; |
3 | switch (state) { |
4 | case 0: /* start of function */ |
5 | for (i = 0; i < 10; i++) { |
6 | state = 1; /* so we will come back to "case 1" */ |
7 | return i; |
8 | case 1:; /* resume control straight after the return */ |
9 | }
|
10 | }
|
11 | }
|
Die wesentliche Zusammenfassung des Artikels ist quasi: Man hat ein Konstrukt, bei dem eine Funktion nicht am Anfang, sondern an der Stelle ihres letzten "Verlassens" aufgerufen wird.
@ chris_ (Gast) >Ein ganz netter Artikel, wenn man auch so ein Konstrukt vermutlich sonst >nirgends finden wird ( case 1: in for Schleife ). Das ist schon fast gemeingefährlich . . . >Die wesentliche Zusammenfassung des Artikels ist quasi: Man hat ein >Konstrukt, bei dem eine Funktion nicht am Anfang, sondern an der Stelle >ihres letzten "Verlassens" aufgerufen wird. Das macht JEDE 08/15 Statemachine so, dafür braucht man keine Stunts in C, das kann man PROBLEMLOS sauber hinschreiben.
>Das macht JEDE 08/15 Statemachine so, dafür braucht man keine Stunts >in C, das kann man PROBLEMLOS sauber hinschreiben. Da hast Du vermutlich weder den Artikel genau gelesen, noch den Eingangspost verstanden.
Markus schrieb: > Selbstverständlich zählt die Optik eines Codes ganz entscheidend. Es > gibt schönen und schöneren Code. Es gibt natürlich auch weniger schönen > Code. Genau, ich kann ziseliert "Scheiße" scheiben - wird die dadurch schöner?
@ Markus (Gast) >>Das macht JEDE 08/15 Statemachine so, dafür braucht man keine Stunts >>in C, das kann man PROBLEMLOS sauber hinschreiben. >Da hast Du vermutlich weder den Artikel genau gelesen, noch den >Eingangspost verstanden. Erwischt ;-) OK, jetzt hab ich den Artikel mal gelesen. Hmmm . . "This is very nice in theory, but in practice you can only do it in assembly language, because no commonly used high level language supports the coroutine call primitive. Languages like C depend utterly on their stack-based structure, so whenever control passes from any function to any other, one must be the caller and the other must be the callee. So if you want to write portable code, this technique is at least as impractical as the Unix pipe solution. " Naja. "It's still ugly, though. The worst part of it is that the set of labels must be maintained manually, and must be consistent between the function body and the initial switch statement. Every time we add a new return statement, we must invent a new label name and add it to the list in the switch; every time we remove a return statement, we must remove its corresponding label. We've just increased our maintenance workload by a factor of two. " "A reader can deduce the grammar recognised by the parser, or the compressed data format used by the decompressor, far more easily than by reading the obscure state-machine code." Wirklich? Ich seh das irgendwie nicht. Aber ich bin ja auch nur ein kleiner Hardwerker. "We have achieved what we set out to achieve: a portable ANSI C means of passing data between a producer and a consumer without the need to rewrite one as an explicit state machine." Ist das soo schlimm? Testbarkeit? Statemachines können vollautomatisch generiert und getestet werden. "Of course, this trick violates every coding standard in the book. Try doing this in your company's code and you will probably be subject to a stern telling off if not disciplinary action! You have embedded unmatched braces in macros, used case within sub-blocks, and as for the crReturn macro with its terrifyingly disruptive contents . . . It's a wonder you haven't been fired on the spot for such irresponsible coding practice. You should be ashamed of yourself. " ;-) "Any coding standard which insists on syntactic clarity at the expense of algorithmic clarity should be rewritten. If your employer fires you for using this trick, tell them that repeatedly as the security staff drag you out of the building. " ;-))) "In a serious application, this toy coroutine implementation is unlikely to be useful," Alles in allem. Eine nette, aber wenig praxisrelevante Spielerei.
Wieso nimmt man nicht einfach computed gotos? Reicht ja pro Taskfunktion ein static pointer, wo es nach Ablauf z.B. eines delays weitergehen soll.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.