Hallo, im Rahmen meiner Diplomarbeit entwerfe ich ein protables Echtzeitbetriebssystems. Eine erste Implementierung der Kernfunktionalitäten ist bereits verfügbar. Diese aktuelle Version 0.1 läuft nur auf der Simulatorplattform (libc-linux); Portierungen für 8051, 68000, TriCore und C166 sind aber in Arbeit. Ich würde mich über Feedback freuen. Homepage: http://hadie.sf.net Download: http://sourceforge.net/project/showfiles.php?group_id=83983
RTOSse gibts ja eigentlich schon wie Sand am Meer und auch für kleine MCs (z.B. Salvo für den 8051). Was mich daher interessieren würde ist die Begründung, d.h. warum man noch ein weiteres RTOS hinzu fügen muß. Überhaupt wäre eine gründliche Analyse, was ein RTOS auf einem MC bringen kann und was nicht, sehr interessant. Am besten sollte man an einem konkreten Beispiel die Nachteile und Vorteile eines RTOS gegenüber einer klassischen Main-Loop mit Interrupts aufzeigen. Die Begründung einer gestellten Aufgabe gehört ja schließlich auch zu einer Diplomarbeit. Wenn Du also mal Deine Worte zu diesen Aspekt irgendwie zugänglich machen könntest, wäre das super. Aber auch an jedem anderen Kommentar oder Beispiel zum Sinn oder Unsinn von RTOSsen auf MCs bin ich brennend interessiert. Peter
Immer kürzere Entwicklungszyklen und die zunehmende Komplexität eingebetteter Systeme erschweren die Wiederverwendbarkeit und die Verifikation verwendeter Komponenten. Betrachtet man Implementierungen der Klasse dieser informationstechnischen Systeme, so finden sich wiederkehrende funktionale Aspekte, die sich auf die Dienste eines "Micro Kernels" abbilden lassen. Warum ein neues System ? Beim Entwurf des Kernels wird ein hoher Wert auf die Portabilität gelegt, so werden 8 bis 32 Bit Prozessoren unterstützt. Der plattformabhängige Programmteil ist minimal. Dadurch wird die Portierung auf neue MCs erleichtert. Das Treiberframework von Hadie ermöglich sowohl eine leichte Integration neuer Treiber, als auch deren Wiederverwendung. Der Programmcode unterliegt der GPL. Ok, es gibt viele Open Source Ansätze. Durch den Einsatz von Open Source erhoffen wir uns Vorteile in Bezug auf Stabilität. Ein Testen auf den Zielsystemen konnte noch nicht stattfinden, da diese Portierungen noch in Arbeit sind. Dennoch haben wir schon etwas feedback aus newsgroups erhalten. Marc --- Unter der Mailadresse aus meinem ersten Posting bin ich nicht mehr zu erreichen. Die habe ich gestern wegen Spam abgestellt.
Hallo,
>entwerfe ich ein protables Echtzeitbetriebssystems
wo könnte ich nachlesen, wie so etwas gemacht wird.
Grüße
Wolfgang
@Marc, Deine Antwort enthält nur Allgemeinplätze die sich fast alle RTOSse auf die Fahne schreiben aber beantwortet leider keine meiner Fragen :-( Wenn ich Deine Arbeit beurteilen müßte, würde ich darauf bestehen, daß Du mindestens einen Mitbewerber beim Namen nennst und konkrete Unterschiede (natürlich mehr Vorteile als Nachteile) herausarbeitest. Auch ein konkretes Anwendungsbeispiel könnte nicht schaden. Peter
Schon mal XMK angeschaut? (http://sourceforge.net/projects/xmk) Der Ansatz gefällt sehr gut. Weitere Portierungen wären hilfreicher als ein Neues (auch wenn es viel Spaß macht ein weiteres RTX von grund auf zu schreiben). XMK ist - winzig - portabel - offen Gruß Winni
Hi Winnie, hast Du schon XMK mit FreeRTOS (auf avrfreaks) verglichen? Würde mich interessieren. XMK scheint noch Alpha zu sein, oder? Stefan
Hallo, ich kenn den AVR kaum und FreeRTOS nicht. Was mir an XMK gefallen hat ist: 1) sehr klein 2) sehr modular 3) wirklich portierbar 4) Die Quellen sind gut dokumentiert Das könnte eine Basis für Micro-RTOSse für alle möglichen Controller werden. Stadium Alpha ist richtig. Winni
Portabe ist der code nicht, wenn er nur 8, 16, u. 32 Bitter unterstützt; die ARM2 u. ARM3-Prozessoren sind 24-Bitter. Und schließlich gibt es auch 64- und 128-Bit-Prozessoren. Dazu kommt noch, dass man z. B. beim ARM9 zwischen little u. big endian wechseln kann und es Multiprozessing inzwischen auch mit ARM-Prozessoren gibt. Dazu kommen noch Plattform- u. Compiler-Abhängigkeiten wie Stuffing u. Alignement, durch die es immer einen erheblichen portierungs-Aufwand gibt, selbst wenn man sich streng an ANSI-C + IEEE 754 + ISO 60559 hält, obwohl das schon einen erheblichen Aufwand erfordert, auch weil die Hardware nicht immer IEEE 754- u. ISO 60559-konform ist.
Also Leute! Ganz ruhig. Schaden wird so ein neues RTOS bestimmt nicht. Ist doch gut, wenn immer mal wieder einer kommt, und alles schöner, schneller und eleganter amchen will. Da es Opensource ist, kann man auf jeden Fall draus lernen. Ach so, noch was: Soblad MEIN Runtime System für AVR fertig ist, werde eich es bestimmt hier posten, und keiner kann mich aufhalten :-) MfG Sebastian
@Sebastian "Ach so, noch was: Soblad MEIN Runtime System für AVR fertig ist, werde eich es bestimmt hier posten, und keiner kann mich aufhalten :-)" Bin schon mächtig gespannt darauf. Aber bitte mit einer praxisnahen, realistischen Beispielanwendung, die die Vorteile eines RTOS so richtig herausstellt und die profane Mainloop mit Interrupts weitab geschlagen hinter sich läßt. Wäre ja sonst blöd, wenn man was entwickelt hätte, das keine Vorteile hat und das keiner braucht. Und an einem konkreten Beispiel kann man nunmal die Vorteile und Nachteile am besten verdeutlichen. Peter
Beispiel für Multitasking: stell Dir eine Maschinensteuerung vor, die einigermassen komplex und zeitkritisch ist. Die soll jetzt ein User-Interface, Display und so, dazubekommen. Stromsparen sollte auch angesagt sein, wenns nichts zu tun gibt, sollte der Sleep-Mode aktiviert werden. Mit Multitasking ganz einfach: Deine Maschinensteuerung werkelt in einem hochprioren Task, wenn sie auf Input oder Timer warten muss, dürfen die anderen Tasks dran. Dein Userinterface hat einen niedrig-prioren Task, alles was an Zeit abfällt, kriegt also der User. Das reicht dem immer noch locker. Das Userinterface ist so wunderbar einfach zu schreiben, weil Du keinerlei Unterbrechungen berücksichtigen musst, keine Zustände etc. zwischenspeichern. Da Dein MC in der Regel fixer als die meisten User (und Programmierer..) ist, wird zwischen den Useraktionen noch Zeit sein, der Multitasker wird in den Idle-Task schalten, in dem automatisch der Sleep ausgeführt wird. Projekt schon fast fertig, da kommt nochmal der Vertrieb. "es gibt da einen Kunden, der will da noch ein Gerät einschleifen. Alle Daten, die wir seriell empfangen, sollen nur ein bischen umgestellt werden und dann seriell weitergeschickt werden. Ist doch kein Problem, oder?" Mit Multitasking wirklich nicht. Einen Task dazwischengehängt, der die Konvertierung macht. Angst um das Timing der Maschinensteuerung musst Du nicht haben, die darf ja mit höherer Prio arbeiten. Fazit: Bei kleinen Projekten mag es wenig bringen. Aber je komplexer es wird, desto mehr Vorteile hat Multitasking. Meine Erfahrung ist: mit zunehmenden Teilaufgaben wird ein Multitasking-System linear komplexer, während es bei "normalen" Main-Projekt exponentiell schwieriger wird, weil alle Bereiche eng miteinander verwoben sind. Nachteilig ist, insbesondere bei kleinen MCs, der Speicherverbrauch für die mehrfachen Stacks. Bei den meisten Applikationen spielt dagegen (meiner Erfahrung nach) der Zeitaufwand fürs Taskswitching keine Rolle, Erfahrungswert ca. 1-2%. Gruß, Stefan
Aus welchem Werbeprospekt hast du das denn abgetippt?
Wenn mein Task zu jeder Zeit unterbrochen werden kann, dann muss ich
überlegen ob ich gerade zeitkritische Programmteile programmiere. Wenn
ja, dann muß ich die Unterbrechung verbieten...
Und mal schnell noch einen Task reinnehmen, der nix mit den anderen zu
tun hat, ist auch eher unüblich.
> Ist doch kein Problem, oder? Mit Multitasking wirklich nicht.
Solche pauschalen Aussagen kann ich nicht nachvollziehen.
Schmittchen.
Naja, wenn´s universell sein soll, muss man den Sheduler geeignet auswählen können, denn z. B. für Multimedia-Wiedergabe braucht man einen anderen als für 3D-Spiele. Dazu kommt noch das geeignete Dateisystem das je nach Einsatzgebiet komprimieren oder eine garantierte Datenrate oder eine ganz andere Anforderung erfüllen soll. Darüber gibt´s ja viele Lehrbücher.
@Schmittchen: >Aus welchem Werbeprospekt hast du das denn abgetippt? Hab ich mir selber aus den Fingern gesogen, wenn Du es gerne als Werbung verstanden wissen willst, dann am liebsten für eines der freien, FreeRTOS zum Beispiel. Oder noch besser: als Anreiz, Multitasking mal selber auszuprobieren. >Wenn mein Task zu jeder Zeit unterbrochen werden kann, dann muss ich >überlegen ob ich gerade zeitkritische Programmteile programmiere. >Wenn ja, dann muß ich die Unterbrechung verbieten... Der mit der höchsten Priorität kann nicht unterbrochen werden. Im Gegenteil, er wird sofort gestartet, sobald Arbeit für ihn anliegt. Wenn Du mehrere zeitkritische Sachen gleichzeitig machen musst, dann musst Du bei jedem Lösungsansatz etwas mehr Gehirnschmalz investieren ... >Und mal schnell noch einen Task reinnehmen, der nix mit den anderen >zu tun hat, ist auch eher unüblich. Es war NUR ein Beispiel. Natürlich haben die meisten Zusatzaufgaben mit dem Produkt zu tun. Aber mit Multitasking ist es fast immer einfacher, sie hinterher reinzufummeln. >> Ist doch kein Problem, oder? Mit Multitasking wirklich nicht. >Solche pauschalen Aussagen kann ich nicht nachvollziehen. Schon mal mit Multitasking gearbeitet? @Rolf: Multimedia-Wiedergabe, 3D-Spiele ... Sorry, nicht so die typischen MC-Anwendungen, die ich gemeint habe (und mit denen ich mich auskenne). Das ist doch eher was für "richtige" Betriebssysteme. Ich wollte eigendlich nur eine Lanze brechen für Multitaskingsysteme, die meiner Meinung nach bei komplexeren MC-Apllikationen die Arbeit wesentlich erleichtern. Stefan
Also ich finde das Beispiel auch nicht sehr passend, da es überhaupt keine Vorteile gegenüber Peters (der Standard-Vorgehensweise) bietet. Das ist genauso schnell so programmiert. Und auch die Hinzunahme des seriellen Tasks ist ja kein Problem, zumindest, wenn man einen vernünftigen Controller einsetzt, der mehrere Interruptlevel bietet (schliesst die AVRs aus). Das Debugging ist oftmals auch komplizierter. Meiner Meinung nach hat ein solches System zwei Vorteile: - Programmierer, die nicht viel mit Controllern gemacht haben, können damit schneller Ergebnisse erzielen, ebenso Einsteiger - Bei grossen Projekten mit mehreren Softwareentwicklern kann man viel besser die Teilaufgaben aufteilen und getrennt bearbeiten lassen, sowas geht sonst mit viel Reibungsverlusten einher
@Jörg: Na dann erklär doch mal, wie Du eine zeitkritische Maschinensteuerung, die parallel zum Bedienteil laufen soll, programmieren willst. Alle Ansätze, die ich kenne, ergeben ein ziemlich zerhacktes Programm. Der serielle Task war als BEISPIEL gedacht. Sowas kann man vielleicht noch als Interrupt machen. Lass es noch etwas komplizierter werden, und die Interrupt-Lösung wird plötzlich ziemlich ungemütlich. Die Vorteile sehe ich exakt auf der anderen Seite: für Neueinsteiger zu kompliziert, erst mit Erfahrung kann man die Vorteile richtig ausschöpfen. Als ich mein erstes Multitasking eingesetzt habe, das war MCX11 (von Tom Barrett) für den 68HC11, war das eine ziemliche Offenbarung. Viele Dinge, die ich vorher zwar lösbar, aber ziemlich umständlich fand, gingen plötzlich so einfach, und der Code sah richtig "sauber" aus. MeinPosting sollte eigendlich andere dazu animieren, das auch mal zu probieren - dank Leuten wie Marc geht das sogar völlig umsonst. Gruß, Stefan
Meinst Du mit Jörg mich? Der grösste Teil der Maschinensteuerungen, die auf MCs laufen, sind ohne solche Systme programmiert. Und die Programme sind das Gegenteil von zerhackt. Interruptlösungen werden auch nicht ungemütlich, wenn sie ordentlich priorisiert sind und vernünftig geschrieben. Wieso auch? Im Gegenteil, ohne den Overhead des RTOS bleibt sogar mehr Rechenleistung übrig. Wir hatten uns damals auch das MCX11 angesehen (weil wir mit mehreren Entwicklern parallel an den Projekten gearbeitet haben), das aber wieder verworfen, da es zu viel Performance gefressen hätte und zu wenig geboten hat, was wir nicht auch so schnell programmiert haben. Der einzige Vorteil war halt die einfachere Trennung der einzelnen Teilaufgaben, das hat sich aber für uns nicht gelohnt.
@Jim: sorry für den Namensdreher. Wenn Du eine Steuerung hast, die einigermassen zeitkritisch ist, musst Du bei allen "unwichtigen" Sachen Unterbrechungen einbauen, oder eben alles zeitkritsiche in den Interrupt verfrachten. Beispiel aus dem obigen Projekt: Ausgabe aufs Display, z.B. einer Graphik. Während der Ausgabe musst Du zwischenrein ständig schauen, ob die Steuerung Arbeit hat, und entsprechend die Steuerung ranlassen. Die Ausgabe einer simplen Graphik kann locker ein paar ms in Anspruch nehmen, das ist bei uns immer viel zu langsam gewesen. Also musst Du die Ausgabe wohl oder übel in kleine Happen teilen. Alternative ist, alles nur etwas zeitkritische in den IR. Ist zwar machbar, meiner Ansicht aber nicht der Sinn von IR´s. Zur Performance kann ich nur sagen, ich habe zwischen 1-2% gemessen. Wenn die nicht übrig sind, dann hat man ein ganz anderes Problem. Habt Ihr dann mal ein anderes Multitasking probiert? Oder irgendjemand anderes, der Multitasking hier so kritisch findet? Stefan
@Stefan: Also die Display-Ansteuerung haben wir ganz simpel über eine Queue abgewickelt. Da muss man nichts in irgendwelche Happen teilen. Für grosse Displays haben wir eh einen eigenen MC eingesetzt und über den UART oder CAN angesteuert. Bei 5-7stelligen Maschinenpreisen ist das eh viel billiger, als einen einzelnen MC bis zum Rand vollzustopfen. Was mit auffällt, ist, daß Du von "dem" IRQ sprichst. Ich rede hier aber von mehreren IRQ-Ebenen. Da kann man dann auch die Aufgaben entsprechend priorisieren. Das heißt, die wirklich zeitkritischen Teile in den IRQ mit der höchsten Priorität. Dazu braucht man nun wirklich kein RTOS.
Mehrere IR-Ebenen sind praktisch, keine Frage. @Jim: Hast Du schon jemals die andere Seite gesehen, nämlich die Programmierung mit Multitasking? Ich will ja nicht bestreiten, dass es auch ohne MT geht, ich habe selbst genügend Projekte sowohl mit als auch ohne gemacht. Und meine Erfahrung daraus, für jeden der es hören will: probiert es aus, es lohnt sich. Stefan
Ja, zur Zeit arbeite ich mit RT Linux. Wie schon geschrieben, der grosse Vorteil ist, daß man recht gut mit mehreren Entwicklern (zumeist) reibungslos ein Projekt durchführen kann, außerdem kann schnell bei Bedarf ein Entwickler aus der "reinen" Softwarefraktion dazugeholt werden, wenn der Termindruck mal groß wird... Ich habe mich ja nicht gegen RTOSs ausgesprochen, die lohnen sich aber halt nicht immer, besonders nicht bei den genannten Beispielen.
Oben wurde eben nach einer Beispielanwendung gefragt. Klar kann man mein Beispiel auch noch "normal" erledigen. Aber dafür ist es eben ein Beispiel, einfach genug, um es schnell zu beschreiben und für ein Forum noch lesbar zu halten. Echte Anwendungen werden schnell genug komplexer. Mit dem "lohnen" ist es so eine Sache. Es gibt mehrere freie Multitasking-Syteme, die "nur" das eigene Interesse kosten. Warum also nicht ausprobieren? Stefan
Hadie - Hardware abstracting device indepent environment Release 0.1.1 Website -------- http://hadie.sf.net Release Notes ------------- This intermediate release features Hadie running on real hardware ranging from a 8 bit processor (i80515) to 32 bit architectures (i386, 68k). Hadie at least starts on the TriCore processor and can be build using the C166 compiler. Various bugs in the kernel functions have been fixed and the unstable signal functions have been removed. Flag und semaphore handling has been added. Though semaphores are still named mutex, which is nonsense. Some API functions (shared memory) have not yet been implemented and currently the design of services on top of the Hadie API is evaluated. See services/ip4net for an example of running a uIP-based Webserver on top of Hadie. As this is the first release of Hadie running on real hardware, do not expect optimal performance - though the tests show that runs very stable.
Hallo zusammen. Mir scheint es dorch sehr komisch, dass hier der Einsatz von RTOS's hinterfragt wird. Ok für das obligate "Hello World" oder ein Blinklichtlein braucht es wohl keins. Aber sobald paralelle Prozesse ablaufen möchte ich ja den Code sehen, der das Handel übernimmt. Ehrlich, am schluss schreibt doch jeder sein eigenes Betriebssystem allerdings meist non preamtive. Und wenn er trotzdem ein preamtives schreibt, so kann er ja gleich ein vorhandenes nehmen. Ok. das war zwar Wind in den Segeln von Peter der ja auch hinterfragt, warum noch ein RTOS. Für die weitere Entwicklungen von RTOS's finde ich zwei Sachen wichtig: Ersten der "Geilheitsaspekt" der besagt, dass es ein super Gefühl ist, ein RTOS's zu schreiben, das funktioniert, billiger und in Sachen Qualität den Komerziellen in nichts nachsteht. Und zweitens, dass nur eine Entwicklung möglich ist, wenn verschiedene Ansätze verwendet werden. Manchmal ist es aber auch nötig, zuerst den Konkurenten zu kompieren um nachher das Ganze zu verbessern. Eine Idee noch für ein RTOS: Ein " Dead Lock Manager". Eine Lösung die wirklich gut ist ( ohne Timeout Geschichte ), habe ich bis heute noch nie gesehen. Schön wäre es, wenn mir jemand vom Gegenteil überzeugen könnte.
Also ich finde es macht wenig Sinn das Rad immer neu zu erfinden; man sollte möglichst vorhandenes nehmen oder ausbauen wie z. B. RTLinux. Sowas wie " Dead Lock Manager" gibt`s da längs und das ist inzwischen jahrelang von mehreren Fachleuten optimiert worden. Linux hat ja auch den Vorteil der guten Skalierbarkeit; das bringt z. B. auf einem dualprozessor-PC mehr Speed bei 3D-Spielen, selbst wenn einige Server auf demselben Rechner laufen ;-) Bei einem Betriebssystem muss man ja auch berücksichtigen, das auch ein auf einem MC lauffähiges Programm, dass den MC komplett steuert, ein Betriebssystem ist, also auch ein Hello-World-Programm das i. W. nur eine LED blinken läßt. Wenn man viel mehr will, beispielsweise Sicherheit, dass kein Stack-Overflow Probleme verursachen kann, dann braucht man schon zumind. MMU, DMA und einiges andere mehr wie z. B. mind. 64 kB Speicher.
"dann braucht man schon zumind. MMU, DMA und einiges andere mehr wie z. B. mind. 64 kB Speicher." Ein wahres Wort, um Multitasking richtig zu machen, d.h. auch langsame oder fest hängende Prozesse aus dem Speicher zu hauen und die anderen trotzdem zum Zuge kommen zu lassen, braucht es schon massig RAM und MIPS-Overhead und das ist aber bei den hier üblichen AVRs und 8051-er eben nicht der Fall. Und wenn ich also trotzdem darauf achten muß, daß alle Routinen kurz und Hängerfest sind, dann spare ich mir doch lieber den ganzen Schnickschack und bleibe bei der Main-Loop mit Interrupts. Wie gesagt, wenn ich was anderes lernen und benutzen soll, dann will ich doch auch echte Vorteile davon haben. Soweit ich das aber sehe, bringt ein RTOS auf 8051 / AVR höchstens dann was, wenn ich extrem viele, aber auch extrem schnarchlahme Prozesse habe. Peter
Zu dem Thema gibt es ja in der neuen c´t einen Artikel zum Multitasking auf dem MSP430F149, aber da wird ja auch betont, dass es u. a. versärkt und ständig das Damokles-Schwert des Stack Overflow gibt, weil das Multitasking mehr RAM benötigt. Wenn man auf einem MC schon für ein Block device wie MMC/SDC schon etw. mehr als die Hälfte des RAMs benötigt, macht es wenig Sinn sich über Multitasking mit einem Sheduler Gedanken zu machen. Und wenn man von 60 kB Flash nur noch 150 B frei hat, kriegt man da kaum einen Sheduler rein. Bei nur 128 B RAM und 2 kB Flash dürfte das auch schwer machbar sein. Um auch in solchen Situationen ein minimales Multitasking ohne Sheduler hinzubekommen bleibt da eigentlich nur eine Mainloop mit Flags als Semaphoren oder nested Interrupts. Weil die meisten Programmierer aber nicht einmal das machen, gibt's ja leider viel Code, der z. B. unendlich lange auf eine Tastatureingabe warten kann (u. damit fast alles andere wie serielle Kommunikation blockiert) anstatt von der ISR über Flags/Semaphore anzuzeigen dass es eine neue Eingabe gibt.
Mit einem wenig mehr Doku hättet ihr nen Entwickler mehr, falls interesse bestehen würde... :) Gruß, Patrick...
Hallo Patrick, Interesse besteht und ich kann Dir Doku zukommen lassen. Schick mir einfach ne Mail an meine Sourceforge Adresse. Marc
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.