Multithreading mit AVRco

[Frank]

So ist es! Echte Parallelverarbeitung gibt es doch ganz selten, in der Praxis arbeiten doch die meißten Controller und Microprozessoren immer Befehl für Befehl ab. Das Multitasking wird doch von der Software verwaltet (Zeitscheibenverfahren etc.)
Wenn du richtige Parallelverarbeitung haben möchtest, dann nimm einfach zwei Controller. Aber da wirst du sehen das dann auch andere Problemchen auftreten, nämlich der Datenaustausch und die Form der Zusammenarbeit.
Also meines wissens wird bei Atmel Multitasking nicht speziell duch irgendwelche Befehle oder Hardwarevorkehrungen unterstützt. Man muß es halt per Software regeln, wenn man es denn wirklich braucht. Ich nehme mal an das das bei der C-Control II auch per Software (Betriebsystem) gemanagt wird, bin mir aber nicht sicher.

Jup, bei der CC2 ist ein Betriebssystem drauf. Deshalb ist das Teil auch so langsam...

[Johannes]

Also, war von mir der Beitrag

[pbürgi]

Wird im PC das Multithreading nicht auch nur vom Betriebssystem bereitgestellt? Der Artikel in der CT beschreibt sozusagen, wie man sich sein einfaches Betriebssystem für nen Mikrocontroller programmiert. Das ist doch das selbe.

[Frank]

Ja so ist es. Wobei aber NT / Windows 2000 und vermutlich XP auch Boards mit mehreren Microprozessoren unterstützt.

[Kjion]

Der Artikel in der CT beschreibt sozusagen, wie man sich sein einfaches Betriebssystem für nen Mikrocontroller programmiert. Das ist doch das selbe.

Die Frage ist nur ob das auf 8-Bit Mikroprozessoren wirklich sinnvoll ist. Wenn die Hälfte des Speichers und der Rechenzeit benötig um eine Art Multithreading zu haben ist das eher fraglich. Meistens kann man viele Sachen quasi parallel durch Interrupts ablaufen lassen. Das ist meistens die bessere/schnellere Lösung.
Meine Meinung dazu...

MfG Kjion

[pbürgi]

Das ist doch genau das was in dem Artikel beschrieben ist, hab ich doch in diesem Thread oben geschrieben.

[hrrh]

... fuer weniger geuebte programmierer faellt die moeglichkeit ein betriebssystem fuer einenen microcontroller zu schreibern sowiso flach. ob ein betriebssystem sinnvoll ist, ist schon in anbetracht der (sicher vorhandenen) fehler fraglich sowas bringt nur eine fehlerquelle mehr (und diese fehlerquelle ist schwerer zu beheben) meiner meinung nach also nicht sehr sinnvoll.

[Johannes]

OK, aber Multithreading hat natürlich auch erhebliche Vorteile, z.B. die Sicherheit. Wenn irgendwo etwas nicht stimmt, läuft trotzdem die Sensorüberwachung weiter, etc.

Aber wenn der AVRco das so kann, dann reicht das für mich.

Womit programmiert ihr eigentlich eure AVRs?

Gruß
Johannes

[recycle]

fuer weniger geuebte programmierer faellt die moeglichkeit ein betriebssystem fuer einenen microcontroller zu schreibern sowiso flach. ob ein betriebssystem sinnvoll ist, ist schon in anbetracht der (sicher vorhandenen) fehler fraglich

Vielleicht sollte man bei "Betriebssystem" nicht unbedingt immer gleich an Monster wie Windows, Linux, Unix oder ähnliches denken.

Das was PBürgi da beschreibt ist doch eigentlich mehr ein Scheduler, der per Timer und Interrupt automatisch die verschiedenen Subroutinen aufruft die man sowieso braucht.
Allzuviel Programmcode steckt da vielleicht gar nicht hinter.
Wenn man den einmal richtig geschrieben hat, könnte ich mir schon vorstellen, dass das weniger fehleranfällig ist, als alles einfach in eine Schleife zu packen oder von jeder Routine die nächste manuell aufzurufen.

Der Vorteil von gut programmiertem Multitasking und Multithreading ist ja nicht nur, dass mehrere Programme oder Threeads scheinbar parallel ablaufen, sondern auch, dass sich nicht gleich alles aufhängt, wenn eine Routine hängt.

Wäre doch schön, wenn der Robby auch noch nach Hause kommt, obwohl irgendeine fehlerhafte Routine in einer Endloschleife hängt.

Wenn pbürgi seine CT irgendwann mal wiederfindet und ein paar Details mehr posten könnte, fände ich das schon ganz interessant.