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