schönes Multitasking mit Arduino

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.

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

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

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