mikrocontroller.net

Forum: Projekte & Code Hadie: neues, freies RTOS


Autor: Marc Feld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marc Feld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wolfgang Bauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

>entwerfe ich ein protables Echtzeitbetriebssystems
wo könnte ich nachlesen, wie so etwas gemacht wird.

Grüße
Wolfgang

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Winni Simon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Winnie,

hast Du schon XMK mit FreeRTOS (auf avrfreaks) verglichen? Würde mich
interessieren.
XMK scheint noch Alpha zu sein, oder?

Stefan

Autor: Winni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sebastian Schildt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marc Feld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Schmittchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marc Feld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Remigus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: Rolf F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit einem wenig mehr Doku hättet ihr nen Entwickler mehr, falls
interesse bestehen würde... :)

Gruß,
Patrick...

Autor: Marc Feld (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Patrick,
Interesse besteht und ich kann Dir Doku zukommen lassen. Schick mir
einfach ne Mail an meine Sourceforge Adresse.

Marc

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.