Forum: Mikrocontroller und Digitale Elektronik schönes Multitasking mit Arduino


von Markus (Gast)


Lesenswert?

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.

von Frickelfritze (Gast)


Lesenswert?

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?

von Markus (Gast)


Lesenswert?

>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.

von Carl D. (jcw2)


Lesenswert?

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
von Markus (Gast)


Lesenswert?

>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.

von Markus (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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

von chris_ (Gast)


Lesenswert?

>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.

von Falk B. (falk)


Lesenswert?

@  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.

von Markus (Gast)


Lesenswert?

>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.

von Dieter F. (Gast)


Lesenswert?

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?

von Falk B. (falk)


Lesenswert?

@ 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.

von Nop (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.