www.mikrocontroller.net

Forum: Compiler & IDEs Code zu funktionsblock zusammenfassen


Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fällt jemand eine Möglichkeit ein, dem Compiler dazu zu bringen einen 
Codeteil in einen Funktionsblock zu packen und mit call hineinzuspringen 
ohne das dafür ein eindeutiges Symbol festgelegt ist ?

Es geht um die implementierung des Systemaufrufes fork() das ganze 
schaut z.b. so aus:

pid = fork();

.... alles was hier drin steht wird in einem extra prozess ausgeführt.

exit(0);

Das Hauptproblem ist nun nach dem starten des threads hinter die Exit 
funktion zu springen damit der hauptthread weiter ausgeführt wird.

Ich wollte das eigentlich in eine Funktion kapseln ala

#define fork void test(void) { thread starten; return;
#define exit thread stoppen; }

nur müssen damit natürlich eindeutige namen her, was nicht geht solang 
ich den aufruf nicht nur ein mal erlauben will.

nuch ne Möglichekit die mir einfallen würde ist ne eindeutige konstante 
am exit abzulegen und den code bei fork zu durchsuchen bis man auf die 
erste konstante trifft und dann dahinter zu springen, aber das ist 
natürlich reichlich unsauber und ich würde es gern vermeiden.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sowas geht in C nur als furchtbarer Hack.

Mit Assembler ist es machbar, denn da kann man auch innerhalb einer 
Funktion ein Label definieren und von außen zugänglich machen.

Eine andere Möglichkeit wäre, exit etwas cleverer zu implementieren: 
Wenn exit in einem fork lauft, kehrt sie einfach zurück, ohne den Prozeß 
zu beenden. Ob das in deiner Umgebung möglich ist, weiß ich natürlich 
nicht, denn du hast dich dazu nicht geäußert.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sowas geht in C nur als furchtbarer Hack.

Im Moment wäre mir alles recht, da ich gar keine Lösung habe.

>Mit Assembler ist es machbar, denn da kann man auch innerhalb einer
>Funktion ein Label definieren und von außen zugänglich machen.

Das Hauptproblem ist ja das quasi alle Labels die selben bezeichner 
hätten und damit ist doch das wieder gestorben oder ? Ich hätte gar 
nichts gegen inline Assembler.

>Eine andere Möglichkeit wäre, exit etwas cleverer zu implementieren:
>Wenn exit in einem fork lauft, kehrt sie einfach zurück, ohne den Prozeß
>zu beenden. Ob das in deiner Umgebung möglich ist, weiß ich natürlich
>nicht, denn du hast dich dazu nicht geäußert.

Die Umgebung besteht aus avr-gcc und freertos

ich muss also aus fork() ... exit()

xTaskCreate(neuefunktion,STACK_SIZE,...) machen.

das define fork()
könnte also xTaskCreate mit einem Zeiger auf den Bereich nach sich 
selbst aufrufen (geht wahrscheinlich eh nur mit inline assembler da 
sonst wieder n label definiert werden muss), und müsste dann hinter das 
nächste exit statement springen und genau das ist das Problem. Ich kann 
dafür natürlich labels definieren aber halt nur ein mal.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir scheint, du verstehst unter fork etas anderes, als das bei *nix 
übliche Modell:

fork dupliziert dort den laufenden Prozeß. Das Resultat sind zwei 
getrennte Prozesse mit gemeinsamer Vergangenheit und Handles auf die vor 
dem fork offenen Dateien. Die Kopie kann erkennen, daß sie die Kopie 
ist. Jeder der beiden Prozesse führt fortan sein Eigenleben und 
terminiert ganz normal.

Wenn ich richtig verstehe, was du beschreibst, machst du garkein echtes 
fork, sondern startest innerhalb deines Prozesses einen neuen Thread. 
Das ist was völlig anderes.

Ein Thread läuft innerhalb des Prozesses auf einem eigenen Stack und 
wird durch eine Funktion implementiert. Ein Thread-Scheduler - bei rtos 
ein Systemdienst - vergibt Rechenzeit an die verschiedenen Threads und 
sorgt für den Kontextwechsel.

Wenn diese Funktion terminiert, wird der Thread beendet, nicht der 
Prozeß. Die Thread-Funktion darf nicht die Prozess-Terminierungsfunktion 
des Systems aufrufen! (Aber evtl. eine Systemfunktion, die den Thread 
terminiert.)

Lies einfach die Dokumentationen nochmal nach - ich schätze, daß sich 
das Problem mit dem Verständnis, was eigentlich passiert, ganz einfach 
in Luft auflöst.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will auch nicht 100%ig kompatibel zu einem Unix sein das ist in der 
Größenordnung auch gar nicht möglich. die exit Funktion kann auch das 
Hauptprogramm nicht beenden wohl aber den Thread. Ich versuche quasi 
etwas Prozess ähnliches über Threads zu implementieren.
Der Vorteil, der ganzen Geschichte ist das man etwas gewohnter 
programmieren kann (10k extra speicher vorrausgesetzt für lcd,i2c und 
seriellem treiber) und seine software auch z.b. mal auf nem linux testen 
kann.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Ulrich wrote:
> Ich will auch nicht 100%ig kompatibel zu einem Unix sein das ist in der
> Größenordnung auch gar nicht möglich.

Das wollte ich auch nicht anregen. Mein Punkt war, daß du wohldefinierte 
Begriffe ohne weitere Ausführungen einfach anders gebrauchst - sowas 
kann nur Konfusion schaffen.

> die exit Funktion kann auch das
> Hauptprogramm nicht beenden wohl aber den Thread.

Dann verstehe ich offen gesagt dein Problem nicht.

> Ich versuche quasi
> etwas Prozess ähnliches über Threads zu implementieren.

Das ist für einen µC eine Schuhnummer zu groß - Rtos bietet sowas aus 
gutem Grund nicht an.

> Der Vorteil, der ganzen Geschichte ist das man etwas gewohnter
> programmieren kann (10k extra speicher vorrausgesetzt für lcd,i2c und
> seriellem treiber) und seine software auch z.b. mal auf nem linux testen
> kann.

Das halte ich für nicht erwiesen. Allein die Notwendigkeit, übelste 
Hacks einzusetzen, oder Systemfunktionen umdefinieren zu müssen, spricht 
dagegen.

Wenn du Rtos benutzt, ist es schlauer, sich an dessen Systemkonventionen 
zu halten, als ihm irgendwelche - bestenfalls - halbgaren eigenen 
Konzepte überzubraten.

Die Rtos-Entwickler sind Experten für Echtzeitbetriebssysteme und 
arbeiten sicher schon einige Jahre länger auf den Sektor, als du.

Autor: rtosleser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ähem:
http://www.freertos.org/croutine.html
wäre wohl einfacher als irgendwelche "Vergewaltigungen" ;-)
Oder sehe ich da was falsch ?
Du willst doch innerhalb eines Tasks einen Untertask erstellen ?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Vorteil, der ganzen Geschichte ist das man etwas gewohnter
> programmieren kann (10k extra speicher vorrausgesetzt für lcd,i2c und
> seriellem treiber) und seine software auch z.b. mal auf nem linux
> testen kann.

Das wird so aber kaum funktionieren. Nach einem fork arbeiten zwei 
Prozesse weiter, die zwar erst einmal denselben Speicherinhalt haben, 
aber wenn nun einer der Prozesse z.B. in eine Variable schreibt, wirkt 
sich diese Änderung nicht auf den anderen Prozess aus, da er auf einem 
eigenen Adressraum arbeitet. Und genau da liegt auch der wesentliche 
Unterschied zu Threads. Die arbeiten mit einem gemeinsamen Adressraum.
Da kannst du lieber eine pthreads-artige API auf das RTOS aufsetzen. So 
kannst du es dann auch unter Linux testen.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tut es ja in meinem fall auch nicht , da ich gar nicht auf die lokalen 
variablen des parentprozesses zugreifen kann. Ist aber ein guter einwand 
wenn man das mit inline assembler machen würde würde der compiler 
nämlich noch denken er kann auf die variablen der hauptfunktion 
zugreifen und damit den stack versaun.

>Da kannst du lieber eine pthreads-artige API auf das RTOS aufsetzen. So
>kannst du es dann auch unter Linux testen.

das hatte ich eh vor, ich hätte nur gern beide varianten implementiert 
aber das fork rückt in immer größere ferne.

>Du willst doch innerhalb eines Tasks einen Untertask erstellen ?

ja aber eben fork kompatibel und nicht irgendwie, deswegen sind 
co-routines keine lösung

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... würde der compiler nämlich noch denken er kann auf die variablen der
> hauptfunktion zugreifen und damit den stack versaun.

Wie kommst du denn dadrauf?

Der Compiler weiß garnicht, was ein Thread ist. Es ist ausschließlich 
Sache des Betriebsystems, den Thread-Stack zu initialisieren - für den 
Compiler ist der nichts weiter, als ein zusammenhängender 
Speicherbereich.

Auch 'denken' Compiler nicht - das ist nämlich der Job des 
Programmierers. Compiler haben nur Regeln anzuwenden, die der 
Programmierer

   1. genau kennen muß und
   2. geschickt einsetzen muß, damit am Ende das herauskommt, was er
      geplant hatte.

Außerdem muß der Programmierer noch die Regeln kennen, die vom 
Betriebsystem - so eines vorhanden ist - und von der Hardware vorgegeben 
werden.

Mir scheint, du solltest dich wirklich erstmal ausfühlich mit den 
Gegebenheiten auseinandersetzen, ehe du anfängst, das System 
umzumodeln...

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wie kommst du denn dadrauf?

Soweit ich weiss werden lokale variablen auf dem Stack abgelegt oder ?
Wenn man jetzt fork mit inline assembler implementiert und zwischen fork 
und exit also im thread versucht auf ne variable die z.b. im main vor 
dem fork statement steht zuzugreiftn, compiliert der compiler das 
einwandfrei da aus seiner sicht aus der main auf die variable 
zugrgriffen wurde. Lieg ich da falsch ?

>Der Compiler weiß garnicht, was ein Thread ist. Es ist ausschließlich
>Sache des Betriebsystems, den Thread-Stack zu initialisieren - für den
>Compiler ist der nichts weiter, als ein zusammenhängender
>Speicherbereich.

Davon war gar keine rede natürlich initialisiert das BS den Stack.

>Auch 'denken' Compiler nicht - das ist nämlich der Job des
>Programmierers.

entschuldige bitte das ich bei der codeerzeugung von "denken" gesprochen 
habe indirekt hat sich ja mal jemand etwas dabei gedacht. Allerdings 
gleitest du hier leicht ab find ich. Ohne genau zu wissen was ich 
gemeint habe und nochmal nachzufragen beschuldigst du mich unwissen zu 
sein, rührt nicht gerade von weit gedacht her oder ?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Soweit ich weiss werden lokale variablen auf dem Stack abgelegt oder ?

Ja.

> Wenn man jetzt fork mit inline assembler implementiert und zwischen
> fork und exit also im thread versucht auf ne variable die z.b. im main
> vor dem fork statement steht zuzugreiftn, compiliert der compiler das
> einwandfrei da aus seiner sicht aus der main auf die variable
> zugrgriffen wurde. Lieg ich da falsch ?

Und wie erreichst du jetzt, daß der neue Thread seine eigene Inkarnation 
der Variable hat, die an derselben Adresse steht, wie die im 
Vaterthread, aber trotzdem unabhängig davon ist?

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gar nicht, wie schon gesagt es soll keine 1:1 kopie eines unix werden 
man soll es nur so benutzen können. Man könnte in dem fall auch noch den 
Stack kopieren dann hätte man das erreicht nur wäre das auch quatsch da 
man so ganz schnell den sram mit stack voll hat.

Zudem hab ich immer noch keine lösung überhaupt den vaterprozess 
weiterziführen (hinter exit zu springen). Das word wohl auf der Strecke 
bleiben und eher ne pthread konforme implementierung werden.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Ulrich wrote:
> Zudem hab ich immer noch keine lösung überhaupt den vaterprozess
> weiterziführen (hinter exit zu springen). Das word wohl auf der Strecke
> bleiben und eher ne pthread konforme implementierung werden.

Ach da liegt dein Denkfehler...

Wieso soll denn der Thread nach Terminieren der Thread-Funktion 
weiterlaufen? Da ist doch nichts mehr, was er tun könnte, außer ins 
digitale Nirvana zu trudeln und hoffentlich nichts anderes mitzureißen.

Das ist ungefähr so, als sollte main nach dem return noch irgendwas 
anderes machen, was aber leider nirgends spezifiziert ist...

Wenn das Betriebsystem keine autonomen Prozesse zuläßt, dann kannst du 
ihm auch mit solchen Tricksereien keine beibiegen.

Wenn du unbedingt auf RTos die Illusion von Multiprocessing haben 
willst, dann muß du dir einen eigenen Process-Scheduler schreiben, an 
den deine übrigen Anwendungen Kommandos schicken wie "Starte die 
Funktion auf Adresse XY mit den Parametern p1, p2, p3".

Der Scheduler wirft dann die Funktion in einem eigenen Thread an und 
wenn die Thread-Funktion terminiert, dann wird von RTos - wie gehabt - 
der Thread vernichtet.

Das ist allerdings wirklich nur eine Illusion, weil RTos diese 
Funktionalität für Threads bereits mitbringt.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gar nicht, wie schon gesagt es soll keine 1:1 kopie eines unix werden
> man soll es nur so benutzen können.

Genau das kann man aber nicht. Da liegt ja das Problem. Ich sehe nicht, 
wie du das so hinbasteln willst, daß mehr als ein eher akademisches 
Trivialprogramm damit ohne große Umbbauarbeiten sowohl auf dem PC als 
auch auf deinem µC läuft.

> Man könnte in dem fall auch noch den Stack kopieren dann hätte man das
> erreicht nur wäre das auch quatsch da man so ganz schnell den sram mit
> stack voll hat.

Bei Multitasking brauchst du in der Regel sowieso für jeden Task einen 
eigenen Stack. Aber auch dann wird's nicht richtig funktionieren, sobald 
man mal über einen Zeiger auf die Stackvariable zugreift, denn der paßt 
sich beim Kopieren nicht automatisch an.

> Das word wohl auf der Strecke bleiben und eher ne pthread konforme
> implementierung werden.

Ich denke, das ist noch am ehesten sinnvoll.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wieso soll denn der Thread nach Terminieren der Thread-Funktion
>weiterlaufen? Da ist doch nichts mehr, was er tun könnte, außer ins
>digitale Nirvana zu trudeln und hoffentlich nichts anderes mitzureißen.
>Das ist ungefähr so, als sollte main nach dem return noch irgendwas
>anderes machen, was aber leider nirgends spezifiziert ist...

Das hab ich doch nie gesagt.
Also nochmal:

Hauptfunktion läuft bis sie auf fork trifft. ->
fork erstellt einen thread der thread beginnt hinter dem fork statement
zu laufen ->
fork springt hinter das nächste exit statement im hauptprogramm <<<<
das ist mein problem woher soll ich bitte wissen wo exakt das nächste
exit statement ist ??
danach läuft das hauptprogramm normal weiter

   der thread läuft bis er auf das exit statement trifft und beendet 
sich
   dann

>Wenn das Betriebsystem keine autonomen Prozesse zuläßt, dann kannst du
>ihm auch mit solchen Tricksereien keine beibiegen.

Entschuldige, das stimmt nicht. Selbst Perl implementiert im Windows 
prozesse als threads. Und ich will ja keine volle implementierung 
machen.

>Der Scheduler wirft dann die Funktion in einem eigenen Thread an und
>wenn die Thread-Funktion terminiert, dann wird von RTos - wie gehabt -
>der Thread vernichtet.

und was soll an meiner implementierung soweit ich sie beschrieben habe 
anders sein ?

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bei Multitasking brauchst du in der Regel sowieso für jeden Task einen
>eigenen Stack. Aber auch dann wird's nicht richtig funktionieren, sobald
>man mal über einen Zeiger auf die Stackvariable zugreift, denn der paßt
>sich beim Kopieren nicht automatisch an.

Natürlich braucht man den nur hab ich nicht vorgesehn den Stack des 
Hauptprogramms zu kopieren. Dann müsste man den Stack der childs immer 
mindestens so groß machen wie den vom hauptprogramm, was schlichtweg 
verschwendung ist auf nem 8 bitter.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Entschuldige, das stimmt nicht. Selbst Perl implementiert im Windows
> prozesse als threads. Und ich will ja keine volle implementierung
> machen.

Threads und Prozesse sind zwei verschiedene Dinge:

Threads laufen im Adressraum eines Prozesses, während Prozesse einen 
eigenen Adressraum haben.

Es ist natürlich denkbar, daß ein Interpreter wie Perl intern einen 
geforkten Prozeß als Thread repräsentiert - das heißt aber noch lange 
nicht, daß der Tochter-Prozeß in den Adressraum des Vaterprozesses 
greifen kann.

Und den ganzen Zirkus machst du auf einem 8-Bit µC? Ist das die 
Hightechvariante der alten scholastischen Streitfrage:

   "Wieviele Engel haben auf einer Nadelspitze platz?"

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es ist natürlich denkbar, daß ein Interpreter wie Perl intern einen
>geforkten Prozeß als Thread repräsentiert - das heißt aber noch lange
>nicht, daß der Tochter-Prozeß in den Adressraum des Vaterprozesses
>greifen kann.

Ich weiss nicht woraus du das immer alles herinterpretierst, das hab ich 
doch nie gesagt. und das kann ein thread im übrigen auch nicht.

>Und den ganzen Zirkus machst du auf einem 8-Bit µC? Ist das die
>Hightechvariante der alten scholastischen Streitfrage:
>
>   "Wieviele Engel haben auf einer Nadelspitze platz?"

Ich find es echt schlimm das man sich hier wenn man ne frage stellt 
immer dafür rechtfertigen muss was man wie machen will und warum der 
himmel blau ist.

die 8 bitter bekommen immer mehr flash, und meisst setzt man auch schon 
typen ein mit unmengen flash allein schon weil man ios oder 
schnittstellen braucht.
aktuell brauch ich für das gesamte os mit lcd und ps/2 treiber 10k dafür 
kann man arbeiten wie in nem "richtigen" os und muss sich keinen kopf 
über lcd ansteuerung oder i2c oder was auch immer machen. und wenn man 
mal nen treiber schreiben muss muss man sich halt nur um dien reinen io 
zugriff gedanken machen. also mir persönlich ist das die 10k flash 
allemal wert, zumal ich gerad das problem hab auf 2 unterschiedlichen 
hardwareplattformen das selbe machen zu müssen aus dieser not heraus ist 
die idee ja überhaupt erst geboren. und ich denke das könnte auch für 
andere interessant sein ...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Es ist natürlich denkbar, daß ein Interpreter wie Perl intern einen
>>geforkten Prozeß als Thread repräsentiert - das heißt aber noch lange
>>nicht, daß der Tochter-Prozeß in den Adressraum des Vaterprozesses
>>greifen kann.
>
>Ich weiss nicht woraus du das immer alles herinterpretierst, das hab ich
>doch nie gesagt. und das kann ein thread im übrigen auch nicht.

Doch, kann er. Genau das ist der Unterschied zwischen Threads und 
Prozessen. Alle Threads benutzen einen gemeinsamen Adressraum, was 
natürlich impliziert, daß der eine auf den Adressraum des anderen 
zugreifen kann. Bei Prozessen ist das nicht der Fall. Sie haben 
getrennte Adressräume. Bei z.B. folgender Funktion
void test(int* p)
{
    switch (fork())
    {
        case -1:
           // error
           break;
        case 0:
            *p = 5;
            break;
        default:
            *p = 3;
    }
}

wird im Kindprozess das, worauf p zeigt, nachher den Wert 5 haben, 
während es im Vaterprozess den Wert 3 hat. Wie soll fork das innerhalb 
eines einzelnen Prozesses erreichen?

> Ich find es echt schlimm das man sich hier wenn man ne frage stellt
> immer dafür rechtfertigen muss was man wie machen will und warum der
> himmel blau ist.

Wir versuchen nur, dir klarzumachen, wie unsinnig die Idee eines fork() 
innerhalb eines einzelnen Prozesses ist. Du scheinst das aber nicht zu 
verstehen, da du immer noch daran festhälst. Egal wie du es drehst und 
wendest: Dein fork wird nachher auch nicht annähernd so funktionieren, 
wie du es von einem Unix gewöhnt bist. Und auch exit wird nicht auf 
magische Weise erkennen können, welchen der "Prozesse" es beenden soll. 
Das muß ja nicht unbedingt der sein, der zuletzt erzeugt wurde.
Also ist es zu deinem Linux-PC eh nicht kompatibel, und damit ist die 
einzige Daseinsberechtigung nicht existent.

> zumal ich gerad das problem hab auf 2 unterschiedlichen
> hardwareplattformen das selbe machen zu müssen

Das bedeutet noch nicht, daß man deshalb ein Unix inklusive der 
Features, die auf einem kleinen µC keinen Sinn machen, nachbilden muß. 
Du wirst ja vermutlich auch keinen X-Server für das LCD bauen wollen.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wir versuchen nur, dir klarzumachen, wie unsinnig die Idee eines fork()
>innerhalb eines einzelnen Prozesses ist.

wie ich schon mehrfach erwähnte will ich damit nicht unbedingt große 
unix programme auf den 8 bitter portieren können sondern eher die damit 
geschriebenen routinen auch auf nem unix testen können.

>Und auch exit wird nicht auf
>magische Weise erkennen können, welchen der "Prozesse" es beenden soll.

das ist schon eine etwas stärkere einschränkung, da geb ich dir recht 
aber genau darum gehts ja vielleicht hat dazu ja jemand eine idee wie 
das doch realisierbar wäre.

ich hab das mit dem fork schon verworfen und werd nur versuchen eine 
pthread kompatible unit beizusteuern.

>Du wirst ja vermutlich auch keinen X-Server für das LCD bauen wollen.

nein, wobei etwas svgalib ähnliches für glcds ganz sinvoll wäre. die 
lcds werden über /dev/tty angesprochen genau wie verschiedene 
eingabegeräte

Autor: Hugo Mildenberger (hmld)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ganz versteht man nicht, warum es unbedingt das undurchsichtige fork 
sein muß, wenn es nur um die Bereitstellung einer komfortablen 
Entwicklungs- bzw. Testumgebung geht. Gegeneinander isolierte Prozesse 
gibt es unter RTOS nicht und Schutzfunktionen, wie sie ein protected 
mode bereitstellt, lassen sich ohne eine MMU nicht per Software 
implementieren.

Wenn RTOS die Funktion xTaskCreate(neuefunktion,STACK_SIZE,...) 
bereitstellt, dann ist das doch die direkte Entsprechung zu 
pthread_create
unter Linux. Threads beenden sich hier wie die synonymen Tasks dort, 
wenn sie auf eine return Instruktion laufen (daneben gibt es noch eine 
Reihe weiterer Möglichkeiten, pthread_exit() anstatt exit() usw.).

Wozu also fork?

Das einzige, was man zunächst braucht, ist eine Zwischenschicht aus 
(inline) Funktionen oder #defines zur Adaptation der Aufruf-Eigenheiten. 
Man kann Tasks bzw. Threads Parameter übergeben, etwa zur Verwendung als 
lokaler Speicherbereich, oder damit sie wissen, wer sie sind und was sie 
tun sollen.

Problematisch an Thread-Implementierungen auf kleinen µCs ist die 
Stacktiefe, wenn der Prozessorstack per Hardware-Vorgabe auf einen 
bestimmten (und immer zu kleinen) Speicherbereich festgelegt ist.

In diesem Fall wird man einen evtl. benötigten Stack für Variablen 
selbst verwalten (was fehlerträchtig ist und u.U. sehr langsam sein 
kann) und außerdem die Aufrufhierarchie sehr flach halten -- was zu 
uneleganten und außerdem oft unübersichtlichen Programmen führt.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hugo Mildenberger wrote:
> So ganz versteht man nicht, warum es unbedingt das undurchsichtige fork
> sein muß, wenn es nur um die Bereitstellung einer komfortablen
> Entwicklungs- bzw. Testumgebung geht.

Mir scheint, das versteht Christian selbst nicht... Hätte er die Zeit, 
die er in diese unsinnige Idee gesteckt hat, ins Projekt investiert, 
wäre er mit Sicherheit weiter gekommen.

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.