Hallo, ich beschäftige mich zurzeit mit embedded Betriebssystemen. Ich versuche mir den Sinn und Zweck anhand eines selbstausgedachten Beispiels klar zu machen: Über den UART werden Daten empfangen, es wird die entsprechende Interrupt Routine ausgelöst. Dort werden die Daten in einen Puffer gespeichert und später in einer Protokoll Parser Routine ausgewertet. Das ganze Programm läuft erst mal rein Interrupt gesteuert, in der main loop wird nichts ausgeführt. Ggf. kommt noch einen Timer hinzu der auch irgendwas tut. Das war der klassische Ansatz für ein simples Programm. Jetzt der Weg mit einem OS: Ich generiere einen Main Task, der später die anderen Tasks überwacht. Der Main Task generiert weitere Tasks und initialisiert die Hardware. So kommt das große Fragezeichen: was passiert mit meinem Interrupt bei neuen Daten am UART? Polle ich den UART über einen Task? Oder baue ich über einen Interrupt einen Eventhandler der meiner Auswerteroutine Daten liefert? Die Routine wiederum einem Task geniert und der später wieder vom Main Task oder auch Scheduler platt gemacht wird. Für einen Timer kann ich mir einen eigenen Task gut vorstellen, da dort zyklisch etwas passieren soll. Bei azyklischen Dingen nun wieder eher nicht, wenn ich z.B. an einen Taster nehme. Dieser hängt an einem Interrupt fähigem Eingang. Wird der Taster gedrückt soll genau dann etwas passieren... Irgendwie erkenne ich den Vorteil für mich noch nicht.
Ich denke du redest jetzt über preemtives real-time OS. Dort wird in der Interruptroutine ein Eventflag gesetzt, wenn was los war.Ist der task(oder auch Funktion), der die Daten der Interruptroutine verarbeiten soll(und dem auch das Eventflag zugeordnet ist) von höherer Priorität als der task der gerade läuft, wird dieser unterbrochen, und die Daten der Interruptroutine im ausgeführten task verarbeitet, weiters wird das Eventflag gelöscht. D.h. In preemtiven OS kann der gerade ausgeführte task durch einen task höherer Priorität unterbrochen werden. Das erleichtert bei komplexen und vielschichtigen Aufgaben die Programmierung. Im Falle eines Tasters, kann man einen periodischen task z.B. alle 20ms aufrufen lassen und die Taste scannen und braucht dabei keinen eigenen Timer. Grundsätzlich geht's aber auch ohne RTOS, da muß man dann mehr mit SW-Interrupts und State-Maschinen arbeiten. Grüsse
Schau mal in die ersten Kapitel rein, dort ist das sehr gut erklärt: http://segger.com/admin/uploads/productDocs/UM01001_embOS_Generic.pdf
Naja das Thema artet schnell in einen Glaubenskrieg aus. Ich für mich möchte ein embedded OS nicht mehr missen. Programme werden überschaubarer und einfacher erweiterbar(finde ich). Ein simples Programm mit einem OS ist sicherlich nicht Sinn und Zweck bei einem OS. Erst bei grösseren Projekten bei denen parallel mehrere Schnittstellen bedient werden , Tasten eingelesen werden müssen, evtl. Grafik ausgegeben werden muss etc etc macht es Sinn ernsthaft über ein OS nachzudenken Das bei Beispiel a) in der Mainloop nix läuft bezweifel ich schonmal. Irgendwo müssen die Daten ja auch verarbeitet werden und je nach Umfang geht das nicht in der IRQ Routine. Diese muss ja möglichst schnell abgearbeitet&verlassen werden. Auf einem uC werden die Schnittstellen weiterhin per IRQ ausgewertet. In der IRQ Routine wird das Zeichen in einen Pufffer geschrieben, auf dessen Auswertung ein anderer Task wartet(ich gehe jetzt mal von Keil RTX aus) Dort gibt es dafür sogennante Message Boxen. Schreibe ich im IRQ in eine Message Box, so wird automatisch der auf die MessageBox wartende Task aufgerufen und kann die Zeichen auslesen und weiterverarbeiten. Das mit dem Pollen der UART in einem Task würde ich auf einem uC nicht so machen, auf PCs aber die blockierende Schnittstellenzugriffe kennen, könnte man das durchaus so machen. Ein Beispiel für einen Task wäre auch die Tastatureingabe. Normalerweise macht man das nicht mit IRQs, da man die Prellproblematik hat. Warum nicht lieber alle xx ms den Task starten und den aktuellen Tastenstatus einlesen und auswerten.
Also, aus meiner Sicht haben Betriebssysteme (auch auf nem µC) nur genau DANN einen Sinn, wenn sie Ressourcen verwalten und Anwendungen starten und per API bedienen können. Und eine Anwendung ist ein Programm, das völlig separat programmiert und übersetzt wird und sich auf das API des BS stützt. Das, was hier zumeist diskutiert wird, sind allenfalls Taskscheduler mit ein bissel Klimbim drumherum - aber eben keine Betriebssysteme, sondern allenfalls ein klitzekleiner Bruchteil von solchen. Nun, unser TO beschäftigt sich ja grad damit und will "Ich versuche mir den Sinn und Zweck anhand eines selbstausgedachten Beispiels klar zu machen" den tieferen Zweck finden. Da muß man wirklich recht lange suchen, bis man was findet. Nun ja, wenn man dem Link von "Gast" folgt, landet man bei Segger - und die wollen Lizenzen verkaufen. Das ist zumindest für mich ein Argument. A. B. schrieb: > Ich für mich möchte ein embedded OS nicht mehr missen. O ha, dann schreib doch mal, was du damit tatsächlich anstellst. Meine Geräte machen auch Multitasking, aber ohne irgendeine Art RTOS. Sowas geht und es ist wesentlich übersichtlicher als ein RTOS. Man muß sich bloß das stupide prozedurale Programmieren nach PAP o.ä. abgewöhnen und sein Zeug ereignisgesteuert aufziehen, also nichtblockierend programmieren lernen. Man muß ja auch bedenken, daß in einem typischen µC die Programmteile, die quasi als unterste Betriebssystem-Ebene gelten, also alles was direkt die verschiedenen peripheren Cores bedient, den größten Anteil am Gesamtprojekt haben. Das wären aus PC-Sicht quasi Gerätetreiber, und die laufen in ihren wichtigsten Teilen komplett als Interrupts und haben in einem Scheduler nix zu suchen. W.S.
Ach du nun wieder. Erzählst du gleich wieder das IDEs scheisse sind und vi das einzig Wahre? Der Rest ist Begriffsklauberei...er wird ein embedded OS wohl nicht mit Windows verwechseln. Klar stellt ein OS auf einem uC nicht viel mehr Bereit als Schudling Funktionen, paar Timing Funktionen und rudimentäre Speicherverwaltung...du baust dir das von Hand nach, andere sparen sich die Mühe(bzw. haben nicht das Wissen) und benutzen ein fertiges System. Ich weiss nicht was an etwas selbstgestricktem übersichtlicher sein soll, als stattdessen ein embedded OS zu verwenden. Vermurksen kann ich beides... "Und eine Anwendung ist ein Programm, das völlig separat programmiert und übersetzt wird und sich auf das API des BS stützt." Wie soll das auf einem uC funktionieren?
PS: Software die über lange Zeit gepflegt wird, wächst, zu Beginn noch nicht alle Anforderungen bekannt sind etc. lässt sich mit einem kleinen OS viel einfacher umsetzen, modularer aufbauen, erweitern, und hilft Abhängigkeiten zu vermeiden so das Codeänderung x nicht an Stelle y unbeabsichtigte Effekte auslöst.
Ich ergänze: Wie soll das auf einem uC sinnvoll funktionieren? Du tauscht ja nicht regelmässig deine Programme auf einem uC aus so das eine totale Trennung überhaupt keinen Sinn macht, da grössere Abstraktion auch grössere Komplexität bei der Umsetzung mit sich bringt und du ja trotz allem immer noch sehr Hardwarenah programmierst
A. B. schrieb: > Wie soll das auf einem uC funktionieren? Siehe Lernbetty hier in der Codesammlung. Offenbar kannst auch du dort noch was dazulernen. Nebenbei ist deine Bemerkung über den vi eine böswillige Unterstellung, also bleibe sachlich. Und über IDE oder nicht wurde hier garnicht diskutiert, also bleib beim Thema. Und nochwas: eine Firmware ereignisgesteuert aufzubauen, ist eben kein Nachbauen von RTOS-Funktionalität, sondern schlichtweg was anderes. A. B. schrieb: > PS: Software die über lange Zeit gepflegt wird, wächst... ..und deshalb brauchst du ein RTOS dafür? Nun gut, mag ja sein, daß deine Entwicklungen was völlig anderes sind als meine. Also schreibe mal, für was für ein Projekt so ein RTOS wirklich notwendig ist. Mir fällt im Moment nämlich kein Projekt ein, wo sowas wirkich nötig wäre oder ne echte Systemvereinfachung brächte. A. B. schrieb: > Ich ergänze:... Ja, eben. Die Anwendungen, wo man auf einem µC ein BS braucht, sind wenige gegenüber dem Standardfall, wo man nur eine funktionierende Firmware braucht. Aber ich hab in einigen meiner Geräte sowas ähnliches drin, nämlich dort, wo die Kunden sich selbst ne neue Firmware installieren können. Dort werkelt im Hintergrund ein residentes Eigenbau-Mini-OS und die vom Kunden ladbare ("updatebare") Firmware ist ne Applikation, die sich eben auf das API des Mini-BS stützt. Schließlich muß so ein Gerät ja auch noch am Leben bleiben, wenn dem Kunden beim Update was schief gelaufen ist - und dafür braucht's das kleine OS im Hintergrund, was natürlich unabhängig von der konkreten Applikation und deren Revisionen sein muß. Bei der Lernbetty hatte mich auch mal jemand gefragt, wozu denn die Auftrennung zwischen BettyBase und den BettyApps gut sein soll. Eben dazu, daß ein jedes separat gepflegt werden kann. Aber mit nem beim Linken einer einzigen Firmware mit eingebundenen RTOS (wie es deinen Vorstellungen enspricht) hat es diese Trennung nicht - und deshalb ist die Nützlichkeit so eines RTOS doch sehr fraglich. W.S.
Das mit der IDE habe ich nur eingeworfen, weil wir da schonmal vor langer Zeit "aneinandergeraten" sind und du der vi(und Konsorten) Verfechter warst. Ich zitiere da mal aus http://www.mikrocontroller.net/attachment/160723/Die_Lernbetty.pdf "Mir ist das Nichtverwenden irgendeiner IDE ein echtes Anliegen" So böswillig bin ich doch gar nicht ;) Das was du mit dem Mini-OS im Hintergrund bezeichnest würde ich jetzt als Bootloader bezeichnen. Update kommt, Firmware wird in einen Speicherbereich geflasht, geprüft und wenn alles geklappt hat wird auf die neue Startadresse geswitcht oder im Fehlerfall läuft eben die alte Firmware weiter...oder reden wir von etwas vollkommen anderem? Und um das mal klarzustellen: weder behaupte ich das ich von dir nix lernen kann noch Bezeichne ich meine Einstellung als einzig richtig, aber ich kann diesem dogmatischen "RTOS = unötig" nix abgewinnen. Zumal ich auch nicht sehe, wo ein OS der ereignisgesteuerten Programmierung im Wege steht? Gerade das lässt sich doch damit sehr einfach umsetzen, indem Threads darauf warten das sie durch ein Ereignis aktiviert werden. "Meine Geräte machen auch Multitasking, aber ohne irgendeine Art RTOS" Im Endeffekt bastelst du doch das gleiche, was ein RTOS als fertiges Framework bietet, zumindest wenn ich mir das oben verlinkte pdf anschaue(ich habe es bisher nur grob überflogen aber werde es mir mal genauer zu Gemüte führen!) Aber evtl. habe ich begriffen wo der Hase im Pfeffer liegt... Dein System unterbricht keine Tasks(ausser durch Hardwareinterrupts wo dann natürlich in die IRQ Routinen gesprungen wird) sondern jedes Event ruft einen Task auf, der komplett abgearbeitet wird. Ein preemptives switchen nach Ablauf einer Zeitscheibe oder durch aktivierung eines höher priorisierten Tasks (auch wenn der Task noch nicht abgearbeitet ist) inkl. sichern aller Register und was dazugehört und herstellen des nächsten Taskkontexts machst du nicht. Ich gebe zu das benötige ich auch nicht, aber das bekommt man bei einem OS Framework ja quasi als Dreingabe dazu. Hab ich damit jetzt ein wenig verstanden worums dir geht oder reden wir immer noch aneinander vorbei?
:
Bearbeitet durch User
W.S. schrieb: > Nun, unser TO beschäftigt sich ja grad damit und will "Ich versuche mir > den Sinn und Zweck anhand eines selbstausgedachten Beispiels klar zu > machen" den tieferen Zweck finden. Da muß man wirklich recht lange > suchen, bis man was findet. Nun ja, wenn man dem Link von "Gast" folgt, > landet man bei Segger - und die wollen Lizenzen verkaufen. Das ist > zumindest für mich ein Argument. Oh ja, eine Firma verkauft ihre Software, das ist natürlich böse ;-). So ein Beispiel ist gar nicht so schwer sich vorzustellen, bei einem Embedded OS geht es nämlich for allem um das "R" beim RTOS, also Realtime. Eine RTOS wie embOS stellt die Möglichkeit zur Verfügung bestimmte Aktionen in einer definierten Zeit auszuführen. Das geht natürlich auch, wenn man alles in einer Interrupt Routine direkt ausführt, aber das kann man bei komplexeren Applikation nicht mehr machen. Nehmen wir doch zum Beispiel einen MP3 Player, da haben wir eine GUI, ein Dateisystem, einen USB Stack und die eigentlich Applikation. Mit einem RTOS kann ich jetzt der GUI Task die höchste Priorität geben, damit ist sicher gestellt, das das Display immer sofort aktualisiert wird auch wenn vielleicht ein Lesezugriff auf das Filesystem mal länger dauert. Sicher bekommt man das vielleicht auch ohne RTOS hin...aber mit deutlich mehr Aufwand bzw. irgendwann ist man dann wieder bei der Lösung eines RTOS angekommen. Ein anderes Beispiel...machen wir ein bisschen TCP/IP Kommunikation. Durch einen Interrupt bekommst du mit das neue Daten in den Empfangsbuffern angekommen sind. Ohne RTOS würde man jetzt entweder in der Interrupt Routine die Daten auslesen oder sich ein Flag setzen und dies in seiner Mainschleife machen. Beides eher supoptimal, weil ich damit das Timing meiner restlichen Applikation beeinfluße. Mit RTOS sende ich einfach aus der Interrupt Routine ein Event an die Task. Bis dahin hat die Task geschlafen und keine Rechenzeit verbraucht. Erst jetzt wacht sie auf und die liest die Buffer aus. Noch ein Beispiel? Stromsparen wird immer interessanter. Wann schaltest du ohne RTOS deine CPU in einen Power Save Modus? Genau, eher gar nicht, weil die Main Schleife immer läuft. Mit RTOS weiß der Scheduler das keine Task ausführungsbereit ist und kann eine Idle() Funktion aufrufen, welche den Power Save Modus aktiviert. Ganz allgemein kann man sagen, das heute die Applikation auf einem Mikrocontroller/Mikroprozessor immer komplexer werden weil die CPUs leistungsfähiger sind. Wenn also diverse Stacks parallel laufen und die Applikation komplexer ist, wird heutzutage kaum einer mehr ohne RTOS arbeiten. Ganz nebenbei, so ein RTOS bringt auch einiges an Funktionalität mit, die man nicht unbedingt selber programmieren möchte, wie z.B. MMU oder MPU. Aber natürlich gibt es auch immer noch genug Appliaktionen wo so ein RTOS Overkill ist, da möchte ich nicht wiedersprechen ;-).
@ W.S.: Ist zwar offtopic, aber würde mich doch interessieren: So wie ich das verstehe hast du bei der Betty zwei voneinander entkoppelte Applikationen. Einmal die Bettybase, ein Minimalsystem mit einer API, und einmal die eigentliche Applikation. Wie schaffst du es dass die Applikation auf API-Funktionen zugreifen kann? Wenn die Applikation kompiliert und gelinkt wird sind der Toolchain doch die Adressen der API-Funktionen gänzlich unbekannt...
Sowas kann man über eine Funktionstabelle machen, die Applikation müsste dann nur wissen, wo diese Funktionstabelle steht. Die könnte ja auf eine fixe Adresse gelinkt sein.
Karl schrieb: > Wie schaffst du es dass die Applikation auf API-Funktionen zugreifen > kann? Na eben über das API. Ist doch ganz logisch, oder? Das API besteht aus einer Sammlung von SVC's, die in einer Headerdatei definiert sind. Ist doch ganz easy, warum versteht ihr das bloß nicht und kommt auf solche Ideen wie einer Sprungleiste usw? Guest schrieb: > Sowas kann man über eine Funktionstabelle machen, die Applikation müsste > dann nur wissen, wo diese Funktionstabelle steht Eben NIEEEEECHT!!! so. Nun gut. Ich räume ein, daß Leute, die bislang nur mit dem GCC zu tun hatten, einiges an Funktionalität eines ARM schlichtweg nie gesehen haben. Ist allerdings keine ARM-Spezialität, sondern findet sich auch bei anderen 32Bit µC wie z.B. FR von Fujitsu. Also mal en datail: ein SVC (SuperVisor-Call) ist ein Software-Interrupt, der eine Nummer beherbergt, bei ARM im Thumb modus 0..255. Bei Arm im ARM-Modus mehr, aber da sowas ja universell sein soll, beschränkt man sich lieber auf 0..255. Nun kann der Compiler anstelle einee Funktionsaufrufes da eben einen SVC generieren und die Funktion - sofern sie vom BS unterstützt wird - wird dann vom und im BS ausgeführt. So ein SVC ist recht platzsparend, man kann das am Reassemblee vom Code sehen, den der Compiler (vom ADS) erzeugt. Leider kann der GCC all so etwas nicht, weswegen man den SVC emulieren muß, also in Assembler nachbilden. Siehe GCC-Versionen der Apps in der Lernbetty. Der Knackpunkt ist in jedem Falle, daß die Applikation keinerlei Kenntnis haben muß über den Ort der aufgerufenen API-Funktion innerhalb des BS. Beide sind also völlig unabhängig voneinander entwickelbar und pflegbar. Also API-Funktion x geht dann quasi so: SWI x (param_1..param_n) ohne daß die Adresse der zuständigen Funktion bekannt ist. Isses nun ein bissel klarer? A. B. schrieb: > Das mit der IDE habe ich nur eingeworfen, weil wir da schonmal vor > langer Zeit "aneinandergeraten" sind und du der vi(und Konsorten) > Verfechter warst. Du scheinst sehr selektiv zu lesen. Ich hab den vi niemals vefochten, im Gegenteil, mir war der vi zu allen Zeiten ein elendigster Graus, weil ich eben kein Admi bin und deshalb auch nicht in die Verlegenheit komme, über ne stinkige DFÜ-Verbindung fernzueditieren. Aber von dem, was ich zur Lernbetty geschrieben habe, bin ich nach wie vor überzeugt und das kann man in den folgenden Sätzen zusammenfassen: - Einen µC kennenzulernen bedarf zunächst des Lesens seiner Doku und die ist heutzutage umfänglich und nicht einfach zu verinnerlichen. - Obendrein bedarf es zum selbständigen Benutzen der Programmiertools, daß man in der Lage ist, selbige auch richtig aufrufen zu können. Wer das kann, der schafft es auch, seine Quellen zu übersetzen und in das target zu verfrachten. - Alle IDE's haben von den zuvor genannten Dingen völlig abweichende Befindlichkeiten, weil sie eine Art Software-System aufbauen, das mit dem konkreten µC und mit den benutzten Tools nichts zu tun hat, konkret ist das ne Projektverwaltung, sogenannte Workplaces und so. Das ist Draufgesetztes mit eigener Logik (die von IDE zu IDE unterschiedlich ist). - Eigentlich reicht's einem, die µC-Doku durchzukauen und sich die Kommandozeilenparameter der Tools richtig herauszusuchen, da muß man sich nicht noch obendrein mit den Haken und Ösen einer IDE herumschlagen wollen. Wenn man dies als erstes macht, bleibt das Eigentliche zunächst auf der Strecke, aber das rächt sich irgendwann bitter. Kann ja sein, daß alles von den Erfindern der IDE so gut vorgekaut ist, daß man auf der Oberfläche tanzend zu einem brauchbaren Ergebnis kommt, aber seine Zielhardware und seine eigentlichen Tools lernt man dadurch nicht kennen. Guest schrieb: > Oh ja, eine Firma verkauft ihre Software, das ist natürlich böse ;-). Rede keinen Unsinn und schreib keine bösartigen Unerstellungen. Zumindest ICH stufe das nicht als böse ein. A. B. schrieb: > Das was du mit dem Mini-OS im Hintergrund bezeichnest würde ich jetzt > als Bootloader bezeichnen. Naja, es ist schon ein Stück mehr, denn es stellt für diverse Dinge sowas wie die HAL dar, hat ne eigene Oberfläche (für die belange der Fertigung) usw. Aber wenn du das als Bootlader bezeichnen willst, dann tu's einfach. A. B. schrieb: > aber ich kann diesem dogmatischen "RTOS = unötig" nix abgewinnen Ich bin wirklich nicht dogmatisch, aber ich bevorzuge es, praktisch zu denken und da kommt mir immer wieder die Frage hoch, _WOZU?_ und die hat mir bisher noch keiner so recht beantworten können. Allenfalls finden manche ein RTOS schick und wolle es genau deshalb haben. Bei dem Beispiel vom Netzwerk (TCP/IP von 'Guest') kommt mir in den Sinn, daß ein angekommenes Datenpaket natürlich irgendwann mal abgearbeitet werden muß - aber ob man das direkt im Interrupt oder beim Abarbeiten der Event-Queue oder durch Anmelden eines Bearbeitungs-Tasks tut, ist eigentlich egal, denn die Rechenzeit dafür braucht es in jedem Falle und selbst das beste RTOS kann keine Rechenzeit erschaffen, sondern es verbraucht einen Teil derselben. A. B. schrieb: > Hab ich damit jetzt ein wenig verstanden worums dir geht oder reden wir > immer noch aneinander vorbei? Ich denk mal, wir reden nicht aneinander vorbei. So Leute, genug für diesen Abend. Manchmal kommt mir in den Sinn, daß man diese Forum wirklich nur nach ner Flasche Rotwein ertragen kann, aber davon bin ich z.Z noch ne halbe Flasche entfernt. W.S. (..und am Ähnd bähbt nur drrr Wäähn -Elfriede Jelinek)
W.S. schrieb: > - Alle IDE's haben von den zuvor genannten Dingen völlig abweichende > Befindlichkeiten, weil sie eine Art Software-System aufbauen, das mit > dem konkreten µC und mit den benutzten Tools nichts zu tun hat, konkret > ist das ne Projektverwaltung, sogenannte Workplaces und so. Das ist > Draufgesetztes mit eigener Logik (die von IDE zu IDE unterschiedlich > ist). Das ist der "Arduino-Effekt" und genau deshalb mag ich den nicht, weil man keine Ahnung hat, was man nun eigentlich selbst gemacht hat und was einem vom magischen Framework geschenkt wurde. Endet dann darin, dass man nur Aufsteckmodule kauft, mit fertigen Libs ansteuert und am Ende trotzdem nicht weiss, warum und wie's funktioniert.
hmmm...ok, ich für meinen Teil verstehe W.S. jetzt schon und stimme auch zu. Ich kenne die Mikrocontroller nicht bis ins letzte Detail und lasse mir viele der Detailfragen von der IDE bzw. den dahinter verborgenen Tools abnehmen. Klar gibt man dadurch einen Teil der Kontrolle ab und verlässt sich darauf, das die IDE Entwickler ihre Hausaufgaben gemacht haben.
Ich kenne den Effekt von Eclipse als IDE ... das ist so ein Molloch für sich, es dauert Monate bis man auseinanderdividiert hat, was zu Java, was zu Build Scripts / Build Process gehört und was alles "Eclipse Magic" ist. Und man hat auch öfter mal seltsame Effekte, weil natürlich auch Eclipse Bugs hat, manchmal sucht man erstmal Stunden woanders. Eclipse ist das Musterbeispiel von einer absolut überdimensionalen IDE, die für sich schon große Komplexität und Woodoo einbringt. Möchte es nicht schlecht reden, es arbeitet sich super damit - bei einer streng typisierten Programmiersprache wie Java bekommt man enorm viel Tipp-/Les-/Sucharbeit abgenommen, weil es ständig mitcompiliert und sofort alle entstehenden Compile-Fehler anzeigt und den Context des Quelltexts kennt und so autokomplettieren kann. Aber es ist nichts für einen Java Einsteiger, der wird von allen erforderlichen Projekteinstellungen und möglichen Fehler damit wahnsinnig.
Kann auch nicht verstehen was ein RTOS bei einfachen bis mittelgroßen Embedded Projekten zu suchen hätte. OK es machts übersichtlich und gliedert hübsch die Aufgaben, das aber nur zum Preis von Platz, Rechenzeit und gesteigerter Komplexität. Dagegen lässt sich das Allermeiste meiner Erfahrung nach als reines Interrupt-System aufziehen- ganz ohne erwähnenswerte Mainloop (in der im Prinzip nur geschlafen wird). Klar braucht das Grips, aber nur DAS und nix anderes ist die eleganteste Lösung! Codiert am besten noch in ASM- und siehe da, schon langt der profane 8-Bitter wieder für die meisten Programmieraufgaben! Aber gut, in Zeiten komplexer, imposanter 32Bit-Hardware (ARM) darf natürlich auch die Software nicht zurückstehen. Komplex ist ja so sexy und macht was her.
Moby schrieb: > ist die eleganteste Lösung! Und noch besser ist natürlich wenn man seine Aufgaben ganz auf Hardware verlagern kann- Stichwort DMA und Event-System (sollte jetzt keine Werbung für die Xmegas sein :)
W.S. schrieb: > Na eben über das API. Ist doch ganz logisch, oder? Das API besteht aus > einer Sammlung von SVC's, die in einer Headerdatei definiert sind. Ok, klar, das kann man natürlich auch machen, erinnert einen so ein bisschen an die alten DOS Zeiten, wie war das? INT21? ;-) W.S. schrieb: > Ich bin wirklich nicht dogmatisch, aber ich bevorzuge es, praktisch zu > denken und da kommt mir immer wieder die Frage hoch, _WOZU?_ und die hat > mir bisher noch keiner so recht beantworten können. Die Frage habe ich in meinem letzten Beitrag beantwortet. Wovon glaubst du eigentlich leben Firmen wie Segger, ThreadX, Micrium, usw. wenn keiner ein RTOS einsetzt ;-). Und das machen die Entwickler sicher nicht nur aus Bequemlichkeit oder weil es schick ist. W.S. schrieb: > Bei dem > Beispiel vom Netzwerk (TCP/IP von 'Guest') kommt mir in den Sinn, daß > ein angekommenes Datenpaket natürlich irgendwann mal abgearbeitet werden > muß - aber ob man das direkt im Interrupt oder beim Abarbeiten der > Event-Queue oder durch Anmelden eines Bearbeitungs-Tasks tut, ist > eigentlich egal, ... Natürlich macht es einen Unterschied! Nämlich gerade den Unterschied, wie ich Aufgaben priorisieren kann. Ohne RTOS möchtest du deine Verarbeitung komplett in der Interrupt Routine machen. Wenn es nicht gerade ein nestable Interrupt ist erzeugst du dadurch z.B. riesige Latenzzeiten für andere Interrupts. Mit RTOS läuft die Interrupt Routine nur sehr kurz, die eigentliche Verarbeitung wird in einer Task erledigt. Diese Task kann aber problemlos von höher priorisierten Tasks, also z.B. einer GUI Task, oder Interrupts unterbrochen werden. Ich muss mir also über diese ganzen Timing Geschichten weniger Gedanken machen, das erledigt das RTOS für mich. Leider bist du auch nicht auf die anderen Beispiele und Aspekte eingegangen. Wie gesagt, keiner zwingt dich dazu ein RTOS einzusetzen, aber zu sagen, das das alles Blödsinn ist, der kann auch genauso gut auf dem PC in Assembler programmieren, wer braucht da schon ein Windows, kann man doch alles selber machen, oder? > denn die Rechenzeit dafür braucht es in jedem Falle und > selbst das beste RTOS kann keine Rechenzeit erschaffen, sondern es > verbraucht einen Teil derselben. Das ist leider der weit verbreite Irrtum das ein RTOS viel Rechenzeit verbraucht. Dem ist nicht so. Man muss sich nur überlegen, was es heißt, das man mit einem RTOS arbeitet. Das ist nicht wie mit Windows, wo noch zig Sachen im Hintergrund laufen, sondern eine Funktion läuft ohne RTOS genauso wie wenn sie in einer Task läuft. Die einzige Rechenzeit wird für den Taskwechsel und vielleicht noch für den Systemtick verbraucht, aber das ist natürlich hoch optimiert. Bei z.B. embOS ist das eine CPU Auslastung von 1-2%.
Moby schrieb: > Codiert am besten noch in ASM- > und siehe da, schon langt der profane 8-Bitter wieder für die meisten > Programmieraufgaben! Das RTOS ist zu komplex aber wir fangen wieder an, alle in Assembler zu programmieren. Das machts dann übersichtlicher... Aber gut...die Diskussion trete ich jetzt nicht los. Im Hobbybereich oder dort wo es wirklich auf Stückzahlen ankommt kann man ja aus Spass oder Geldgründen aufs letzte Byte optimieren. Aber sonst ist Platz wohl heutzutage bei den Preisen und Kapazitäten kein ernsthaftes Problem mehr. Und der ein oder andere sollte aufwachen...in der Geschäftswelt zählt nicht immer die eleganteste Lösung sondern meist die Kosteneffizienteste. Das mag nicht immer gut sein, aber den Endkunden interessiert die genialste Lösung schlichtweg nicht wenn er darauf doppelt so lange warten muss.(vereinfacht gesagt) Und wenn man hier schon gegen ARMs mopert, dann sollte man doch bitte nicht im gleichen Atmenzug XMEGAS in den Topf werfen. Nominal mag das zwar ein 8biter sein, aber das ganze wurde ja so dermassen aufgebohrt und aufgeblasen, das sich die XMEGAS bzgl. der Komplexität auch nicht hinter ARM uCs verstecken brauchen.
A. B. schrieb i > zwar ein 8biter sein, aber das ganze wurde ja so dermassen aufgebohrt > und aufgeblasen, das sich die XMEGAS bzgl. der Komplexität auch nicht > hinter ARM uCs verstecken brauchen. A. B. schrieb: > Und wenn man hier schon gegen ARMs mopert, dann sollte man doch bitte > nicht im gleichen Atmenzug XMEGAS in den Topf werfen. Nominal mag das > zwar ein 8biter sein, aber das ganze wurde ja so dermassen aufgebohrt > und aufgeblasen, das sich die XMEGAS bzgl. der Komplexität auch nicht > hinter ARM uCs verstecken brauchen. Na die beiden trennen immer noch Welten. Von der Prozessor Hardware angefangen über den Instruktionssatz bis hin zur Größenordnung/Vielfalt der Programmierumgebungen. Und zwar nicht zum Vorteil für ARM- wenn es um "möglichst einfach" geht.
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.