Luna hat nun in der Version 2013.r6.1 einen TaskKernel, mit echtem preemptiven Task-Scheduler (ähnlich RTOS-Kernel). http://avr.myluna.de/doku.php?id=de:lib-taskkernel
ja, aber ich kann mir hier keine Anwendung vorstellen, sind das nicht meistens Statusmaschinen die man auf dem Controller laufen hat? Was wäre denn eine sinnvolle Anwendung?
Hallo, Multitasking, das bedeutet für mich Strukturierung mit jeweils einem Prozess pro Problem, welcher dann übersichtlich ggf. auch mit Endlosschleifen programmiert ist. Also Tasteneingabe:
1 | do while (1) |
2 | {
|
3 | key=WaitKey(); |
4 | MachWasDamit(key); |
5 | }
|
Ausgabe, z.B. LED 4-stellig im Multiplex:
1 | do while (1) |
2 | {
|
3 | for(i=0;i<4;i++) |
4 | {
|
5 | MultiplexOff(); |
6 | Ausgabe(digit[i]); |
7 | MultiplexOn(i); |
8 | WaitNotBusy(3); // 3ms warten |
9 | }
|
10 | }
|
Genauso parallel Sensor per i2c auslesen, Ergebnisse an PC übertragen... Also ich finde das halt einfach schöner als das Fummeln mit verschachtelten Programmstrukturen und besonders reizvoll auf einem AVR. Und solange das RAM dafür reicht kann es nicht verschwendet werden. Gruß, Michael
Michael Appelt schrieb: > Multitasking, das bedeutet für mich Strukturierung mit jeweils einem > Prozess pro Problem, welcher dann übersichtlich ggf. auch mit > Endlosschleifen programmiert ist. Dann hast du MT nicht wirklich begriffen. Deine Bedeutung hat MT nämlich nur dann, wenn es einen Haufen voneinander unabhängiger Probleme zu lösen gilt. Das ist aber eher selten der Fall. Viel häufiger ist der Fall, daß die Tasks in irgendeiner Form zusammenwirken müssen. Und dann beginnt sofort der Hassel mit der Synchronisation beim Zugriff auf gemeinsam genutzte Resourcen. Und sobald es mehr als eine solche Resource gibt, droht auch noch der allseits beliebte Deadlock. Klar, man kann natürlich lernen, "parallel" zu denken und auch ein MT-System in den Griff bekommen, aber vielen Menschen fällt das enorm schwer. Und selbst erfahrene MT-Programmierer bauen immer mal wieder einen Deadlock oder eine nicht behandelte Race-Condition in ihre Programme ein... Dazu kommt noch, daß bei kleinen µC (die gewöhnlich nur über einen Rechenkern verfügen) MT nicht mal irgendeinen echten Vorteil bringt, ganz im Gegenteil, schon das reine Scheduling erzeugt eine gehörige Grundlast und belegt obendrein einen wertvollen Timerkanal. Dazu kommt dann noch der Rechenzeitaufwand für die Synchronisation, wenn mehrere Tasks zusammenarbeiten müssen. Das braucht man nicht und das will man nicht. Wenn man grundsätzlich "parallel" denken kann, hat man auch kein Problem damit, das "natürliche MT" sinnvoll zu nutzen, nämlich die Interrupts, die der µC zur Verfügung stellt. Konkurrierende Interrupts in den Griff zu bekommen ist sogar grundsätzlich etwas leichter, als MT zu beherrschen, denn eine Deadlock-Situation ist bei korrekter Programmierung völlig unmöglich, weil es naturgemäß kein "Warten" auf gleichberechtigte Tasks in ISRs geben kann. Race-Conditions gibt es allerdings natürlich auch bei schnöder Interruptprogrammierung. Insofern besteht doch eine starke Ähnlichkeit mit der MT-Programmierung. Zusammenfassung: Entweder man kann "parallel" denken, dann kann man sowohl MT als auch Interrupts. Aus Performance-Abwägungen gewinnt dann auf single-core-Maschinen grundsätzlich der interuptbasierte Ansatz. Oder man kann das halt nicht, dann wird man beides vergeigen und letztlich doch die bekannte Busy-Loop verwenden, angereichert vielleicht mit einigen primitiven ISRs. Das Verrückte ist: zumindest für manche Probleme ist das sogar objektiv die technisch beste Lösung...
ja, das würde mir jetzt auch in den Sinn kommen. Vor allem wenn ich jetzt an das Beispiel mit I2C denke stellt sich mir die Frage, ob es da dann überhaupt funktionieren kann wenn durch die Prozessumschaltung das ganze mitten in irgendeiner Signaländerung auf dem Bus stattfindet, d.h. wie klein müsste man da dann die Zeitscheiben machen usw. Naja, ich werde damit mal weiter experimentieren.
Dirk schrieb: > mitten in irgendeiner Signaländerung auf dem Bus stattfindet Wenn Du den Hardware-TWI nutzt ist das wurscht. Deswegen gibt es doch die Pufferregister.
Michael Appelt schrieb: > Also Tasteneingabe:do while (1) > { > key=WaitKey(); > MachWasDamit(key); > } Ah ja. Multitasking ist also was für Leute, die ihre Programme nach PAP schneidern und partout NICHT nachdenken wollen. Bedenke mal ne andere und weitaus bessere Variante: { immerzu: if (KeyAvailable()) MachWasDamit(GetTheKey()); MachWasAnderes(); MachNochWasAnderes(); ... goto immerzu; } W.S.
So, ich habe mal mit dem Beispiel ein wenig herumgespielt. das sind die beiden tasks die ich in das beispiel eingebaut habe:
1 | procedure task0() |
2 | dim zaehler as word |
3 | dim s1,s2 as string |
4 | 'this is like a single main program |
5 | 'here you can initialize something once |
6 | #define LED1 as PortD.5 |
7 | LED1.mode = output,low |
8 | 'the main loop of this task (never exited) |
9 | do |
10 | zaehler++ |
11 | 'absichtlich aufteilen und Stringverarbeitung provozieren |
12 | s1 = "Task 0 " |
13 | s2 = s1 + "Zähler: "+str(zaehler) |
14 | print s2 |
15 | LED1.toggle |
16 | waitms 100 |
17 | loop |
18 | endproc |
19 | procedure task1() |
20 | dim zaehler as word |
21 | dim s1,s2 as string |
22 | 'this is like a single main program |
23 | 'here you can initialize something once |
24 | #define LED2 as PortD.6 |
25 | LED2.mode = output,low |
26 | 'the main loop of this task (never exited) |
27 | do |
28 | zaehler++ |
29 | 'absichtlich aufteilen und Stringverarbeitung provozieren |
30 | s1 = "Task 1 " |
31 | s2 = s1 + "Zähler: "+str(zaehler) |
32 | print s2 |
33 | LED2.toggle |
34 | waitms 300 |
35 | loop |
36 | endproc |
Was dabei positiv auffällt ist, dass auch bei Stringverarbeitung keine Speicherfehler auftreten. Ich hätte jetzt gedacht, dass man hier auch aufpassen muss weil der Speicher ja nunmal nur einmal vorhanden ist. Die ieingebaute Speicherverwaltung scheint da also intelligent genug zu sein, das hilft schonmal. Trotzdem fällt mir partout kein richtige Anwendung ein, wo man das preemptive Zeugs sinnvoll einsetzen könnte. Zur Zeit nutze ich "normal" eine Hauptschleife, die Interrupts und den KeyMgr (Tastenentprellung von PeDa).
Bei Robotern ist Multitasking sehr nützlich. Ein zweirädriger Roboter benötigt eine Bahnregelung. Die kann man in einem Task laufen lassen. Außerdem gibt es meistens Sensorwerte, die gefiltert und ausgewertet werden müssen, das kann man auch in einen Task verpacken.
Hallo, ist ja klar, daß hier Gegenstimmen mit Zeitscheiben kommen. Wenn man das System Preemptive und kooperativ auslegt, und das geht hier immer, weil ich ja alle Prozesse selbst schreibe und mit mir kooperiere, dann läuft das auch. Zugegeben, I2S ist sicher ein Thema, wo ich selst auch nicht sicher bin, wie man das hinkriegen kann. Wesentlich ist, daß man Tasks direkt umschalten kann, vor allem auch aus Interrupts heraus. D.h Task wartet auf Message, Interrupt sagt, Message ist da und startet die Task direkt, falls sie hoch genug priorisiert ist. Weiterhin ist wichtig, daß man bei mehreren Umschaltanforderungen (typ. Semaphoren-Signal) erst nach Abarbeitung aller Interrupts 1-malig umschaltet. Wichtig ist, daß das Reschedule per Interrupt angeworfen werden kann, in meinem Fall am liebsten per Hardware-Interrupt auf niedrigster Priorität. Ach ja, Zeitscheiben habe ich dabei nie implementiert, die braucht ein Multi-User-System, ein Mikrokontroller dagegen nicht. Ok, ein gewisser Overhead für den Kernel bleibt immer, dem aber der Overhead für das Polling in der Main-Loop entgegensteht. Gruß, Michael
> Ah ja. Multitasking ist also was für Leute, die ihre Programme nach PAP > schneidern und partout NICHT nachdenken wollen. > > Bedenke mal ne andere und weitaus bessere Variante: > { > immerzu: > if (KeyAvailable()) MachWasDamit(GetTheKey()); > MachWasAnderes(); > MachNochWasAnderes(); > ... > goto immerzu; Hallo, was ist PAP ? Was soll das KeyAvailable() ? So programmiert man das im Multitasking nicht !!! Der keyboard-Interrupt stellt fest, daß ein key da ist und setzt ein Signal per Kernelfunktion SetSignal(KEYAVAILABLE). Die Funktion GetKey() macht ein WaitSignal(KEYAVAILABLE) und niemand muss hier sinnlose Zeit mit leeren Abfragen vergeuden. Nochmal meinen Punkt dazu: wenn es zeitkritisch wird kann meine Methode die falsche sein. Aber meine finde ich schöner und auch schneller, wenn man sich ersteinmal einen Grundstock von hilfreichen Routinen aufgebaut hat. Gruß, Michael
Guten Morgen, merkt ihr eigentlich was da gerade abläuft ? Albert hat nur einen Bericht über eine neue Funktionalität abgeliefert, es geht nicht um die Fragen was sonst noch sinnvoll ist, oder wie man Probleme i.A. lösen kann. Allg. Beispiele für den LunaAVR TaskKernel (ähnlich RTOS) wären dennoch angebracht. Alles andere bitte ich in einen weiteren Thread zu verfrachten.
Hallo, ...und ich fand Alberts Lösung richtig gut, schön, dass er sicht die Mühe gemacht hat. Ich bin nur noch nicht dazu gekommen, mir sein System im Detail anzuschauen. Aber ich tue mich manchmal schwer, sowas auszudrücken. Ich wundere mich allerdings, wieso noch keine gemeckert hat, dass er in Basic programmiert. Aber: ich programmiere beruflich auch mit Basic (und Java, C, C++, PHP...), allerdings bis vor einem halben Jahr noch ohne Multitasking, jetzt nutze ich auch Threads. Gruß, Michael
Sorry Michael, LunaAVR ist kein Basic - schon eher eine Hochsprache und in der Version 2013 R6 mit den externen Libraries sehr gut um eine eigene Sprache in der Sprache zu erweitern. http://avr.myluna.de/doku.php
Michael Appelt schrieb: > ...und ich fand Alberts Lösung richtig gut Ich bin nicht der Entwickler von Luna, ich benutze es nur öfter. > Ich wundere mich allerdings, wieso noch keine gemeckert hat, dass er in > Basic programmiert. Es ist hier im Forum immer das selbe Elend. Man stürtzt sich auf ein Stichwort im Start-Posting ohne den Text mit Verstand gelesen zu haben, die zugehörigen erklärenden Links angeschaut zu haben oder sonstwie informiert zu sein.
Der Punkt war: - man braucht meistens kein Multitasking auf einem uC - Ausnahme: Interrupts, aber das kann die Hardware alleine - Multitasking erzeugt fühlbare Grundlast - ein Scheduler allein ist sinnfrei, weil man selten unabhängige Tasks hat Daraus folgt für mich: - Wer ein RTOS will, soll ein vollständiges RTOS nehmen. - Wenn LunaAVR ein eingebautes, zuschaltbares RTOS hat, finde ich das gut. - Ich nutze es nicht. :-) Michael Appelt schrieb: > Wenn man das System Preemptive und kooperativ auslegt, und das geht hier > immer, weil ich ja alle Prozesse selbst schreibe und mit mir kooperiere, > dann läuft das auch. Präemptiv ist das Gegenteil von kooperativ. Entweder kooperatives Multitasking - dann musst du auf deine Tasks aufpassen, sonst Deadlock - oder präemptives Multitasking - dann musst du mit Semaphoren/Mutexen richtig umgehen können, sonst schwer zu debuggende, seltene Datenkorruption. Wirklich einfach ist das nicht, wenn man es richtig machen will. Michael Appelt schrieb: > Was soll das KeyAvailable() ? So programmiert man das im Multitasking > nicht !!! Du kannst davon ausgehen, dass er das auch weiß. Dennoch ist es eine gute Lösung. Die nächstbessere Lösung sind dann Schlafmodi. > Die Funktion GetKey() macht ein WaitSignal(KEYAVAILABLE) und niemand > muss hier sinnlose Zeit mit leeren Abfragen vergeuden. Stimmt, das macht der Kernel schon für dich, um alle betroffenen Tasks nacheinander aufzuwecken. Da, wo Multitasking wirklich sinnvoll wird, gibt es nämlich Events, und an einem Event können durchaus mehrere Tasks interessiert sein. > Nochmal meinen Punkt dazu: wenn es zeitkritisch wird kann meine Methode > die falsche sein. Aber meine finde ich schöner und auch schneller, wenn > man sich ersteinmal einen Grundstock von hilfreichen Routinen aufgebaut > hat. Sicherlich, aber wenn jede dieser Routinen ein eigener Thread ist, dann bringt es dir ohne vernünftige Interthreadkommunikation genau nichts. Und wehe, du schlägst jetzt vor, globale Variablen dafür zu benutzen. ;-) Gruß, Svenska
Hallo, gehe mal davon aus, daß ich weiß, wie man Semaphoren, Messages, Locks, Spinlocks, EventFlags, EventFlagCluster usw. implementiert, weil ich das unter diversen Prozessoren (Z80, 8085 8088, 80286, 8051, AVR) gemacht habe. Du siehts auch, das ist eine Weile her. Dagegen gehe ich mal davon aus, daß Du noch nie ein Multitasking auf einem ATMEGA32 am Laufen hattest geschweige denn moderne Programmierung mit Threads unter Java kennst... Ganz klar, wenn es um Produktionshardware geht, dann zählen die Kosten, kleinerer Prozessor spart 3 Cents, und dann reicht es nicht für solche Spielereien. Aber Hobby ist halt auch Spielerei Gruß, Michael
> Dagegen gehe ich mal davon aus, daß Du noch nie ein Multitasking auf > einem ATMEGA32 am Laufen hattest geschweige denn moderne Programmierung > mit Threads unter Java kennst... Beides falsch.
Svenska schrieb: >> Dagegen gehe ich mal davon aus, daß Du noch nie ein Multitasking auf >> einem ATMEGA32 am Laufen hattest geschweige denn moderne Programmierung >> mit Threads unter Java kennst... > > Beides falsch. Respekt - vor allem deine ausführliche Begründung.
Ich habe auf AVRs schon mit Multitasking gearbeitet und auch schon Multithreaded in Java (konkret Android) programmiert. Und?
Jaja, ich habe schon diese Heldentat und jene Heldentat vollbracht und bin deshalb kompetenter als duhhhh... Ach, immer dieses sich brüsten im Gegenzug zu blöder Anmache a la "Du weißt ja nicht einmal, was IECHHH schon lange weiß". So. Dieses Luna hat also nun ein kleines RTOS eingebaut - und das wird von einigen gelobt, weil es da ist. Die eigentliche Frage ist "WOZU SOLL DIES WIRKLICH DIENEN?" Als Selbstzweck? Als Argument, daß Luna nun was Besseres ist? Als Geh-Hilfe für Programmierer, die nur von einer Warteschleife zur anderen stolpern können? Also, welchen echten Nutzen hat diese ominöse Erweiterung denn nun? Aber bitte nicht von Michael Appelt schrieb: > gehe mal davon aus, daß ich weiß, wie man.. sich in Foren mit Heldentaten brüstet und auf andere eher beleidigend wirkt, weil hinter großen Worten nix ist und der gute Michael mit völligem Unverständnis auf ne kleine, aber wirksame Programmsequenz glotzt. Um es nochmal mit dem Holzhammer zu sagen: Wer ereignisorientiert zu programmieren versteht, braucht in 99.9% aller Fälle kein RTOS - und wer es nicht kann, sollte ein bissel dazulernen und wem dies überflüssig erscheint, ist zu doof. W.S.
Das RTOS von Luna kenne ich nicht. Aber wer pauschal behauptet W.S. schrieb: > Um es nochmal mit dem Holzhammer zu sagen: > Wer ereignisorientiert zu programmieren versteht, braucht in 99.9% aller > Fälle kein RTOS - und wer es nicht kann, sollte ein bissel dazulernen > und wem dies überflüssig erscheint, ist zu doof. der hat meiner Meinung noch nie mit RTOS gearbeitet. Wenn man die Resourcen dazu hat, also nicht immer mit einem Auge auf RAM und usec schielen muss, dann kann der Einsatz von RTOS einem die Arbeit* schon sehr erleichtern. *) Ich gehe mal davon aus, dass hier von Projekten die Rede ist, bei denen etwas mehr als "Hurra, die LED blinkt!" verlangt wird.
@ W.S Dass Du auf alles einschlägst was nach Luna aussieht demonstrierst Du hier wieder trefflich. Der Grund für alle die es nicht wissen: er ist Moderator im BASCOM Forum. Da regiert er auch mit harter Hand und erlaubt nicht die leiseste Kritik am ollen BASCOM. Andere haben es längst begriffen: Bascom ist von gestern und Luna löst es ab. Da nutzt auch Deine unsinnige Argumentation nichts. Was meinst Du wovon die anderen RTOS Hersteller leben. Sichern nicht davon, dass wie Deiner Meinung nach die Anwender zu blöde sind zu programmieren. Aber ich denke die Mitleser haben sich längst ein Urteil über Deine Meinungen gebildet. Siehe hierzu auch genügend andere Threads.
Hahaha! BASCOM ist viel besser als dieses unsinnige Gewurschtel!! Außerdem brauchts auch nicht alle drei Wochen ein neues UPDATE für irgendwelchen Mist, das läuft halt! Und dieser Schnickschnack mit Multitasking braucht sowieso keiner, wozu also? Wegen Linux? Das geht SUPER in einer Windows-Box, außerdem ist die ganze Sprache viel zu kompliziert, da kann man ja gleich C nehmen!! ICH HASSE C!!!
>der hat meiner Meinung noch nie mit RTOS gearbeitet. Wenn man die >Resourcen dazu hat, also nicht immer mit einem Auge auf RAM und usec >schielen muss, dann kann der Einsatz von RTOS einem die Arbeit* schon >sehr erleichtern. So sehe ich das auch. Was der Bauer nicht kennt frisst er nicht;)
Darum schrieb ich ja auch: - "Wenn LunaAVR ein eingebautes, zuschaltbares RTOS hat, finde ich das gut." Und ja, ich hatte auch schon ein Keil RTX in den Fingern. Haken in der IDE setzen, Tasks hinschreiben, fertig - praktisch ist das schon. Aber das war auch auf einem Cortex... Dummerweise muss man auf dem AVR viel zu oft auf den RAM schielen. Für ein RTOS ist es schlichtweg eine schlecht geeignete Plattform.
>Dummerweise muss man auf dem AVR viel zu oft auf den RAM schielen. Für >ein RTOS ist es schlichtweg eine schlecht geeignete Plattform. Da hast du recht.
BASCOM MWS schrieb: > @ W.S > > Dass Du auf alles einschlägst was nach Luna aussieht demonstrierst Du > hier wieder trefflich... Also mal ne Klarstellung: 1. Ich dresche überhaupt nicht auf Luna ein, sondern frage nur, wozu solch eine Erweiterung denn dienen soll. 2. Mein Zorn richtet sich gegen Leute, die aufgrund ihrer beschränkten Programmierfähigkeiten ein RTOS als grandioses Wunder-Mittel proklamieren und glauben, alles was sie selbst nicht können, wird das RTOS ihnen schon richten und Leute, die ein RTOS skeptisch sehsn, seien doof. 3. Ich bin NICHT Moderator in jenem ominösen Forum und habe auch keinerlei Beziehung zu BASCOM. Du verwechselst da was. 4. Ja, ich bin fest davon überzeugt, daß die diversen Hersteller von RTOSsen zum großen Teil davon leben, daß ihre Klientel zu doof ist. Schau dich doch nur mal in diesem Forum um! Wieviele Leute kommen auf die abstrusesten Ideen - die sie dann nicht gebacken kriegen - bloß weil sie ihr eigentliches Problem mangels Intellekt nicht wirklich analysieren können. Ich weiß, daß es Einsatzgebiete für RTOS'se gibt, wo selbige sinnvoll sind, aber all die gewöhnlichen Mikrocontroller-Anwendungen, wie sie hier zur Debatte stehen, gehören nicht dazu. So. W.S.
W.S. schrieb: > 2. Mein Zorn richtet sich gegen Leute, die aufgrund ihrer beschränkten > Programmierfähigkeiten ein RTOS als grandioses Wunder-Mittel > proklamieren und glauben, alles was sie selbst nicht können, wird das > RTOS ihnen schon richten und Leute, die ein RTOS skeptisch sehsn, seien > doof. Und Du glaubst allen ernstes, jemand mit beschraenkten Programmierfähigkeiten waere dazu imstande, ein RTOS aufzusetzen und es zu bedienen? Du scheinst nicht nur noch nie RTOS eingesetzt zu haben; es scheint mir, du hast von RTOS nicht allzuviel Ahnung.
Mehmet Kendi schrieb: > Und Du glaubst allen ernstes Ich weiß es. Da ist ein Unterschied dazwischen. Schau dir mal die Beiträge weiter oben in diesem Thread an, dann wirst du es sehen. Deinen Einwurf hättest du dir sparen können. W.S.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.